Development teams have a fondness for trying new models… for better or for worse. I’m not a fan of the current excitement around the squad model.
What is it
Spotify is the purest example, but the model owes a deal to Stanley McChrystal’s Team of Teams, as well as a bit of LeSS. The basic idea is that teams are tightly aligned to their team mates, but loosely coupled to their projects. Teams will then shift to where work is needed, motivated to do the right thing by their shared purpose and awareness of shared strategic goals. Add a sprinkle of LeSS or tribes alignment for legibility, and you’ve got a model for change from “machine-like” structures to “organism-like” ones.
Why is it attractive
“Work expands so as to fill the time available for its completion” – Parkinson’s Law. Consequently there is no actively growing development team that feels they have enough resources to do everything they want. Of course, not all development teams are actively growing, and so some teams may have less pressure on this axis. Nevertheless there are lots of teams that can’t allocate sufficient resources to the things they want to get done.
When you can’t allocate resources to everything you want to do, you’ve naturally got some projects that aren’t getting done. Maybe there are products that need working on, or maybe you have features that can’t be completed or bugs that can’t be fixed. Maybe they’re process requirements like content production, quality assurance, documentation or tech debt reduction. Whatever it is, it’s something painful. If it isn’t painful, it wouldn’t matter, but it’s a safe bet there’s enough pain to justify considering a big change.
Here are your options.
- Option 0: do nothing. You may continue to do without the missing projects, but obviously that’s really painful and no one is excited by it. Something must be done, right?
- Option 1: incrementalism. You can also try to get the project done with your existing team. You announce that Everyone’s responsible for the project, or you encourage weekend warrior efforts. Or maybe you defer work on all the other projects, with varying degrees of formality.
- Option 2: radical change. You increase resources so you can resolve the problem. There’s lots of tools in that box, but none of them are very cheap. More hiring, consultants, acquisitions, or try to talk your user and partner community into doing it. Nothing in this list is guaranteed or fast.
The squad model makes it look like your organization is rationally choosing Option 1. It’s not really robbing Peter to pay Paul, there are text books and TED Talks. Kidding aside, there are some legitimate benefits to the model.
The genuinely positive aspects
- It reduces the effect of Conway’s Law. Teams are no longer as focused on their product, they’re more focused on their role in the company’s success.
- It allows for high team cohesion within the squad by encouraging cultural bonds, presuming that the company’s culture is sufficiently supportive.
- A nice corollary of that: it doesn’t tie a development team to the market failures of the product they work on. It can suck to see a development team beaten down over failures they can’t control. In a squad model, the team can be judged on something other than eventual product market fit, and may move on to another project.
The mildly pernicious aspect
That movement between projects may sound familiar to anyone who’s ever worked in a professional services shop. Pro services team members go to where the jobs are, and they don’t work on many things that don’t have revenue attached. Bench work and research projects are sometimes an option, but not too much of either. In an enterprise software company, this model leads to a terrible challenge: products have been sold, but there’s no steady maintenance work being done on them. At best, a product is returned to when its lack of maintenance becomes a problem, but at worst the product simply rots.
Software is sold as if it were wine, but in practice it ages like fish. Without attention, it starts producing problems. A company may choose to say that nothing is wrong with this. Aside from one’s ability to sleep at night, this may not work out so well. If the product was sold to customers, there’s likely to be a contract requiring maintenance. One can argue this is less of an issue with products that are offered as free supporting material to a commercial product or service, but practically speaking there’s not a lot of difference.
The nasty failure modes
All of that is just a model allowing morality and economics to play out with Parkinson’s Law, though, and there’s nothing specific to the squad model in it. Squad model is simply a mechanism, potentially allowing pernicious behavior but not forcing it. Here are the ways that I think this model can actively fail the software development organization.
- Product managers and executives are shielded from their responsibility to kill product that isn’t working. A poorly performing product isn’t EOLed, it’s just deprived of any development time. “We aren’t putting Old Yeller down, we’re just not feeding him and waiting for Nature to take its course.” Killing a product that isn’t selling is one of the harder tasks in product management, and a team that doesn’t really have to is going to find a way to avoid it. Squad model keeps false hope alive for bad products. Surely it would succeed if it just got some resources? And surely those resources are just around the corner, at the next planning cycle. And so the zombie product shuffles along.
- Engineers can’t focus on long term improvements or tech debt reduction. Of course everyone complains about this when they don’t do squad model, but the squad model actively makes this situation worse by adding churn costs. At best, developers are coming and going in squad sized chunks but a continual skeleton crew is always on deck. At worst, the product lays fallow between development cycles. For each introduction of people, the cycle of course looks like this:
- Spend a sprint or two spinning up to understand the subject matter domain, product design, existing codebase, and plan of attack
- Bandaid the immediate problem the squad was brought in for, ore or less well
- Spend a sprint or two patching the worst bugs and documenting your work before you move on to something else.
- This isn’t enterprise software any more, it’s professional services. Why’s that bad? Because enterprise software businesses are exponential money makers, but professional services businesses are linear money makers. It’s an oversimplification of course, but based on the observation that services are inherently customized to the client while products are generalized. In the squad model, the projects that the customers buy are now the clients, but the developers are still moving to where the dollars are today instead of skating to the future puck.
- It doesn’t take long for leadership to spot these failure modes, so it also doesn’t take long for correctives to be applied in order to smooth out churn and allow for maintenance. The result is that engineering is split into haves and have-nots. Some squads will be put onto those long-term work items that suffer from shifting resources. Maybe it’s called a Sustaining team (probably lower status), or maybe it’s a Platform team (probably high status), but the effect is the same: parts of the world have to keep working as they did before the re-organization and those engineers are now on an island. Is this expressed as a pendulum swing back towards the prior organization, or as a bold stride towards a new future that simply looks a little familiar? Regardless, the development organization now has another source of cognitive dissonance to discuss.
At best, it’s not worse
As we often say in the business, “it’s software, you can do anything with sufficient time and money.” None of what I’ve described is necessarily fatal to a development organization, and indeed some might welcome a splash of internal cognitive dissonance to distract from their external issues. But in my opinion the model isn’t great at meeting its stated goal, which means it’s not a useful way to allocate resources in my opinion. Ostrom’s Law states that “A resource arrangement that works in practice can work in theory”, but I strongly suspect that’s exactly what we’re seeing here. The massive productivity made possible by enterprise software development allows for a wide variety of otherwise non-productive resource arrangements to maintain effectiveness, regardless of their actual merits or efficiency at producing more quality software.
From Jon Obelenus, Silos are Bad, Handoffs Fail, Async Is Hard