AI Changed Our Team Structure More Than Our Technology Stack
When Implementation Gets Cheap, Coordination Overhead Dominates Earlier
The economics of team structure changed
When a small number of engineers can rapidly move from idea to working implementation, coordination overhead begins to dominate much earlier than before.
Rapid implementation became almost too engaging
The feedback loop between idea and working software became so short that teams could easily continue expanding implementation long after the original problem had been solved.
Our definition of "done" had to change
Previously, completion meant a feature was implemented and deployed. As implementation accelerated, what mattered was whether the capability had actually been adopted by users.
What We Noticed
Historically, many software organisations evolved around the assumption that implementation itself was expensive. Team structures often reflected that reality: larger delivery groups, specialist roles, handoffs between functions, dedicated implementation phases, broad coordination during delivery.
AI-assisted development changes the economics of that process quite significantly.
One of the more interesting behavioural changes was how engaging rapid implementation became for engineers. The feedback loop between idea and working software became so short that teams could easily continue expanding implementation long after the original problem had been solved.
That energy is valuable. It creates experimentation and momentum that would previously have been difficult to achieve. At the same time, without intentional constraints, it became increasingly easy for teams to continuously move onto the next capability before earlier work had fully matured.
The Shift to Smaller Streams
This eventually pushed us toward a different team structure.
We gradually moved toward smaller ownership streams, typically involving two or three engineers working together on a clearly defined area of responsibility. Importantly, these streams were not treated as isolated implementation teams. They became responsible for the full lifecycle of the work, including refinement, operational feedback, adoption, and iteration after release.
Over time, this significantly changed our definition of done.
Previously, it was relatively easy for completion to mean that a feature had been implemented and deployed successfully. As implementation accelerated, that definition became less useful. What mattered increasingly was whether the capability had actually been adopted successfully by users and whether it improved the broader product experience.
This shifted more time and attention toward:
- Adoption — did anyone actually use it?
- Refinement — does it work well enough?
- Operational learning — what did we discover in production?
- Improving existing capabilities — before starting something new
- Reducing friction for users — the last mile matters most
Maintaining Product Cohesion
One of the risks of moving toward smaller and more autonomous streams was fragmentation of the broader product experience. Independent teams could move quickly, but they could also unintentionally drift apart.
We found that reducing implementation coordination did not remove the need for strong product cohesion. If anything, it made coherent product direction significantly more important.
In practice, this led us toward a structure where execution became more decentralised while product direction became more intentional.
Architectural decision records became significantly more important. Key engineers remained involved in reviewing architectural direction across streams, even when they were no longer deeply involved in reviewing implementation details themselves.
The Larger Shift
This feels like one of the larger organisational shifts emerging from AI-assisted development.
Historically, implementation itself often felt like progress. Once implementation becomes dramatically cheaper and faster, however, progress increasingly comes from:
- Validated adoption
- Operational understanding
- Refinement
- Product clarity
- Learning from real usage
The organisations that benefit most from AI-assisted development are unlikely to be the ones producing the highest volume of change. They are more likely to be the organisations that most effectively connect implementation to outcomes while maintaining shared understanding as systems continue evolving quickly.
