Software Teams: Autonomous or Tightly-Aligned?
(Written jointly by Ian Cackett & Sasha Bilton)
A key consideration when managing multiple software teams is how much freedom and responsibility to allow each team over their technology choices, architecture and approach, versus insisting that they agree and align their decisions with other teams in the organisation.
Most organisations tend to take an extreme view and sit at either end of the spectrum, having either fully-autonomous “squads” or heavily mandating alignment, commonalities and shared decisions.
Short-to-Medium Term: Results-Oriented
In the short-to-medium term, autonomous teams certainly appear to be more innovative and effective: They are hampered less by the need to make decisions with other teams (other than for integrations / APIs / product touchpoints) and the inevitable dependencies those bring. They can pick approaches, technologies, frameworks and architecture that play to their experience and strengths. They get results that everyone can see and are able to wholly support their work in production. Most developers enjoy their ability to influence in autonomous teams, making hiring and retention easier.
Conversely, in the short-to-medium term, aligned teams seem to spend more time reaching agreement on commonalities, the “best” languages, frameworks, shared architecture; perhaps to the detriment of delivering product features and other visible results. Even when they have agreed the “best” set of choices for now, those may be limiting to certain teams and hamper progress and innovation there. Aligned teams often divide the underpinning work amongst themselves, which can create blockers when team priorities differ.
So it would seem, looking at results in the short-to-medium term, that the clear choice is to give teams full autonomy over their approach, technology selection and architecture. This is particularly the case if the work they are doing is neatly divided, with well-defined interfaces, APIs or hand-off points between them, and with people who rarely move between teams.
Longer-Term: Synergistic Debt
In the longer-term, there can be a lost opportunity for synergy between autonomous squads; opportunities to introduce common structure or shared solutions. Having many solutions to the same problem spells wasted effort, less focus on the quality of each implementation and an increased likelihood of bugs creeping in.
In itself, lost synergy can be seen largely as a cost/efficiency worry, but it also has a wider impact:
Some product opportunities may be much harder to pursue if they cut across the work of multiple autonomous teams and require the inter-team alignment that seemed so costly and undesirable earlier to be retrofitted… perhaps at a much greater cost now due to the need for rework and migration.
Some might say that once a product has been around for the medium-to-long term, and is presumably proven and successful to some extent, then these are comparatively nice problems to get the chance to solve, so shouldn’t we just wait for them to arise before tackling them? But just like technical debt, synergistic debt often has to be at least partly repaid at some point and costs more to resolve the longer it is left untackled. So is a purely autonomous approach costing us longer-term?
How To Balance The Two?
Autonomy certainly brings speedier results, encourages innovation and takes advantage of individual team strengths. But alignment and synergy can keep a growing software product, and its developers, leaner and more nimble in the medium-to-long term, therefore more able to respond to future directions and challenges as an overall product.
As with technical debt, seeing a decision not to align teams as actual debt, which may need to be repaid at some point, means teams acknowledge its presence and can choose if or when to repay it. Alignment should be balanced with autonomy; more heavily for some topics and more lightly for others.
Align Later: Perhaps initially, autonomy can speed discovery of the “best” choices for some aspects. The results, in some squads, will speak for themselves. Then alignment can be sought over the longer-term, bringing other squads slowly towards the more effective approach. Once proven to be optimal, there may be more willingness to align on an approach.
Align on Key Topics: Alternatively, alignment can be sought up-front on key pieces of architecture, common code, a smaller set of languages (one for web, one for machine learning, etc). These are the choices that are costlier to change in future. Alignment on lesser topics can still be considered and retrofitted when good approaches appear in one squad or another.
Complete Alignment Isn’t The Goal: Keeping architecture lightweight and loosely-coupled means teams can also be loosely-coupled. Often the cost of improving alignment beyond a certain point is just as high as not being aligned at all. There is clearly a sweet spot somewhere in between.
Experimentation is Good: It is worth remembering that it’s ok to be wrong, perhaps to discover that another team has found a better approach than yours. The alignment process is all about learning from those discoveries and validating different approaches.
So what seems to matter most for software teams is that they actively seek a degree of balance between autonomy and alignment, rather than choosing either extreme or allowing one to occur by default. We need to be aware of synergistic debt and that it may need to be repaid longer-term, without letting it ruin the clear benefits of autonomy.
