Squads (AKA the spotify model) are a great thing. I’m a big believer in empowered teams and that’s a great way to get there. However, many companies struggle in implementing such a model, or even simply in deciding to make the transition, because the implications are so heavy: the entire R&D organization needs to restructure in squads, and not all pieces fall into place nicely. While the rest of the company is still trying to figure out how to make squads work but without too much risk on their side, R&D needs to go all in before they got a chance to see if they like it or if it works for them. It’s a giant leap of faith that many R&D managers are reluctant to take.

The good news is that the squad model doesn’t require any formal re-org in R&D at all. In fact, assuming your R&D is structured in the classic layers of a backend team, a frontend team, a mobile team, etc., there is an important role to this structure even in the spotify model (it’s called Chapters in the formal one, although many companies call it Guilds. More on the importance of it later). Not only a formal re-org (that is, moving people to report to squad leads instead of classic team leads) is not needed, I claim that you shouldn’t do this formal re-org at all, and you can add quads on top of this structure. I have worked this way in the past, and here are the benefits that I see.

Start Small

If you are not already working in squads, it is likely that some of the leaders in the company (mostly product and R&D leaders) haven’t worked this way in the past or worked this way and it didn’t work well for them. This is true simply because if all the relevant leaders worked with squads and loved it, they probably would have pushed or at least agreed already to work this way. So whether the reason is that they never worked this way, or that they did and didn’t like it, they would be hesitant to go in that direction. When you don’t need to make changes to the formal R&D structure, it is easy to start small: you can form a single squad on top of the existing structure. There would be people from every relevant team assigned to this squad, they would have a specific mission, and would be led by a product person (as a task force, not as a manager in the HR meaning). 

Such a pilot will most likely face little to no resistance since there is almost nothing to lose from trying. You can bound this pilot by time, so that it has a beginning and an end, and at the end of it everyone goes back to their core teams just like it was before. Companies I’ve talked to who started like that were very pleased with the outcomes – both in terms of clarity, the achievements themselves, and in the developers saying that they highly prefer working this way, so moving on to implementing it in additional areas was a no brainer.

Move Fast Without Breaking Things

Splitting a single product into different squads isn’t easy. You can see the challenge, regardless of squads, when you need to split the responsibilities of a single product between different product managers. Whichever split you come up with, it’s never 100% independent of other teams, and even if you get to 99% independence, there is one area that is bound to be shared across many teams: the code and specifically the core and infrastructure.

A legitimate concern in moving to squads that are constructed of developers from different technical areas in the system (backend, frontend, etc.) is how to make sure these areas remain intact. If multiple squads touch the backend, how can you make sure one squad doesn’t break things for the other? There are mechanisms that help to ensure that, like thorough automated testing, but they are not bulletproof. Eventually, organizations have two options: the first one is to let everyone touch any piece of code that they need and deal with the consequences as they arise. This is Facebook’s model, hence their original motto ‘move fast and break things’. If you think it’s just a mindset that they want you to follow, but don’t really mean that you can break things, think again. When any developer can touch anything things do break, and at some point, this wasn’t good enough even for Facebook (who changed their motto accordingly). 

The second method is to have each module owned by a single team with a team lead or an architect who makes sure the development of one feature doesn’t end up ruining another. When you implement squads while maintaining the classic R&D structure, this important function remains and your code and architecture still have owners. Here is how it works in practice: the backend team members (for example) are assigned to squads, but are still experts on the backend side. They are not just “developers who happen to work on the backend”. They know it in and out. They also know which areas of the backend they are less familiar with, and are responsible to bring the work back to the backend team for discussion whenever relevant, and for architecture design and review when they are working on non-trivial changes. The backend team lead functions here as the architect of their domain, and since they are managing the team they actually have the power to lead this and make sure this system-wide thinking happens on a regular basis.

Slower than the alternative? For sure. However, unless you are willing to break things, this is your only real option in terms of speed. Even companies who do work in squads as a formal org structure, need to put time and effort into letting these Chapters (or Guilds) work as they should. I’ve heard of up to 20% of the time of a developer to be assigned to Chapter review and alignment. So either way, you have to invest this time and see a reduced pace as a result. However, this reduced pace is still much faster than the pace you would get without squads. 

Gain Meta-Agility

Moving people between teams is not something you want to do every day. A person’s relationship with their manager is one of the most important things for people in their work. People join companies for managers and leave companies because of them, and adjusting to a new manager is not always trivial. Furthermore, some of the things the managers own, like performance reviews and professional development, require that the manager sees the employee over a long period of time and not just as part of a specific project.

Leaving the formal R&D structure as is, gives you a lot of flexibility in moving people between squads since the impact is smaller. This, in turn, allows you to do two things: one is to set up squads for short periods of time without overthinking it. If you have an immediate problem that you need to solve, say onboard new customers with less manual effort on your side, you can set up a dedicated squad that will handle this. Of course, to make things fully automated can take time, but note the problem statement: we want to onboard costumes with significantly less manual effort, not without any at all. As with everything else, 80% of the value can be gained in 20% of the time, so such a squad can work on hacks and quick wins, solving the major bottlenecks in the onboarding process, and then finish its work. This squad doesn’t necessarily live forever or for the long term. I’ve seen great results delivered in 6 weeks for example.

This brings me to the other point: the assignment of people to squads can reflect and match your desired investment in each. Every now and then – periodically or when the need arises – you can re-assign people from one squad to another if the latter needs more resources for now. If the squads are the formal R&D structure it is much harder to do so: I’ve seen people who are “temporarily assigned” to another team, since they wouldn’t want to report to the manager of the other team, or since the R&D manager didn’t want to make an HR change for a change that might be for a limited amount of time. It works, but it’s a workaround that you don’t want to use often. When squads are disconnected from the formal R&D structure, this is almost a no-brainer and you can make such decisions on a regular basis.

At the end of the day, this gives you what I call meta-agility because it’s agility not only in the sense that the teams are independent and are able to move fast but also in how fast you can shift your priorities and adjust resources at a higher level.

Avoid an All or Nothing Approach

Last but not least, when squads become your formal R&D structure, some things are left homeless. Infrastructure work, scale, or technical debt to name a few. You can find a way to fit them into existing squads (for example let the first squad that is blocked by scale in a certain area handle it), but it’s not optimal, and will always feel an artificial constraint added to the model simply to maintain the pure squads model.

When squads are not the formal R&D structure, not everyone has to be assigned to squads at any given time. It’s ok to have people working directly with the relevant team lead on solving cross-squad or deep technical problems. It will usually be done for a limited amount of time so that the people doing that are not left outside of the squads who make a business impact, and again allows the actual resource allocation to reflect what you really want, and not what the model forces you to do. If you wanted for some time now to start working in squads and couldn’t get the org to agree, I highly recommend moving forward with squads on top of the classic R&D structure. As you can see, I highly recommend maintaining that structure even if no one objects to squads. It keeps a good balance and allows to move fast in complex products as well as simple ones.