Every leader who has tried to give an engineering team more freedom has met the same surprise. Autonomy handed to an overloaded team does not feel like liberation. It feels like being told to swim while holding the anchor. The instinct that follows is usually wrong: tighten control, add oversight, count commits. The better move is to ask why the team was drowning in the first place.
Autonomy has a ceiling, and the ceiling is cognitive load
Matthew Skelton and Manuel Pais (2019) make cognitive load the center of organizational design rather than an afterthought. A team can only own a slice of work end to end if the amount it must hold in its head stays within human limits. When a team grows or its remit sprawls, load rises and autonomy quietly degrades, because no group can make good independent decisions about systems it cannot fully understand. Their answer is structural. A platform team exists to lower the cognitive load of the teams it serves, packaging infrastructure as a self-service interface so that stream-aligned teams can move without waiting on handoffs. Autonomy, in this view, is manufactured downstream of a platform, not declared in a town hall.
The empirical literature on self-managing teams says the same thing in a colder register. Reviewing the field, Magpili and Pazos (2018) find that self-managing teams are not an automatic gain. Their performance depends on input factors nested at the individual, team, and organizational levels, and the literature is inconsistent precisely because those inputs are often missing. Maria Doblinger (2022), synthesizing 84 studies, adds the individual layer: self-management only lifts performance when members have the competencies, self-leadership and interpersonal skill above all, to navigate a system without a boss. Remove the manager without installing the platform and the competencies, and you have not freed the team. You have orphaned it.
Capability beats policing
The reflex to respond to autonomy with oversight also gets the causation backwards. The multi-year research program behind Accelerate, drawing on the State of DevOps data, identified specific organizational capabilities that drive higher software delivery performance, arguing against the belief that delivery teams cannot be a source of advantage (Forsgren, Humble and Kim, 2018). The lever is capability, the technical and organizational practices a platform makes routine, not a manager watching the queue. The 2024 State of DevOps report from DORA adds that unstable organizational priorities depress productivity and raise burnout even under good leadership and good documentation, and that internal developer platforms improve productivity (DORA, 2024). The honest caveat, which the report's own framing invites, is that this is survey evidence, correlational rather than proof of cause. It should be read as a strong, consistent signal, not a physical law.
Measure the work, or your alignment becomes surveillance
Once autonomy is real, the next failure is measurement. The reflex is to count activity: commits, pull requests, story points. Forsgren and colleagues (2021), in the SPACE framework, explain why this backfires. Developer productivity is multidimensional, spanning satisfaction, performance, activity, communication, and efficiency, and it cannot be captured by any single metric. Optimize the count and the team optimizes the count, not the value. Satisfaction and flow, the SPACE authors argue, are not soft byproducts of productivity. They are dimensions of it. Measure on one axis and you convert alignment into a stopwatch, which is what presence-based management becomes once the desk is remote.
The practical read
Before you debate how much freedom to grant, do the unglamorous work that decides whether freedom will function. Draw the cognitive load each team carries. Build or buy the platform that takes the incidental load off their plate (Skelton and Pais, 2019). Invest in the capabilities that actually drive delivery (Forsgren, Humble and Kim, 2018), and check that teams have the competencies self-management demands (Doblinger, 2022). Then measure across dimensions, not by a single number, so that alignment reads as clarity rather than a stopwatch (Forsgren et al., 2021). Autonomy is not a gift you present to a team. It is a load-bearing capacity you engineer for them, and it fails silently when the platform underneath is missing.
Sources
- Skelton and Pais (2019). Team Topologies. Establishes cognitive load as a design constraint and platform teams as the mechanism that makes stream-aligned autonomy sustainable. https://teamtopologies.com/book
- Magpili and Pazos (2018). Self-Managing Team Performance: A Systematic Review of Multilevel Input Factors. Shows self-managing teams are not an automatic gain; results hinge on individual, team, and organizational inputs. https://doi.org/10.1177/1046496417710500
- Doblinger (2022). Individual Competencies for Self-Managing Team Performance. A review of 84 studies finding self-management lifts performance only when members hold the right competencies. https://doi.org/10.1177/10464964211041114
- Forsgren, Humble and Kim (2018). Accelerate: The Science of Lean Software and DevOps. Multi-year research identifying the capabilities that drive software delivery performance. https://itrevolution.com/product/accelerate/
- Forsgren, Storey, Maddila, Zimmermann, Houck and Butler (2021). The SPACE of Developer Productivity. Argues productivity is multidimensional and cannot be reduced to a single activity metric. https://www.microsoft.com/en-us/research/publication/the-space-of-developer-productivity-theres-more-to-it-than-you-think/
- DORA (2024). Accelerate State of DevOps Report. Survey evidence that unstable priorities raise burnout and that internal platforms lift productivity; correlational, not causal. https://dora.dev/research/2024/dora-report/