As AI changes how we deliver software, organisations are moving towards leaner technology structures with higher management ratios.
AI makes producing software easier, but teams still need to choose the right work, test assumptions, maintain context and make the right decisions. Teams can now implement more ideas, but leaders cannot automatically evaluate ideas faster with the same dedication, so they still need to decide which ideas deserve attention, whether evidence supports further investment, and which assumptions impact several teams.
Without that judgement, the business will simply transform poor decisions into software faster.
As an example, Atlassian’s 2027 State of Product report found that 80% of teams are shipping faster with AI without customers receiving value sooner, while 69% said decision-making had not accelerated at the same pace.
Scaling judgement with implementation
Organisations still need leaders who can make the right calls themselves, develop EMs, and help Product and Engineering turn greater implementation capacity into better outcomes. What changes is how they allocate their capacity.
As the agentic SDLC evolves towards software factories, agents will take care of more implementation decisions, leaving EMs to focus more on intent, boundaries, risk and accountability, while they also coach their team of product-minded engineers. Engineering middle managers need to put more emphasis on coaching EMs through those decisions and identifying cross-team patterns. For that coaching to be effective, they must stay close enough to the technology and understand how the needs of EMs and engineering teams are changing.
Engineering middle managers need to focus on establishing ownership, authority and technical context so that teams can make those decisions independently while maintaining alignment across the area. This is critical because, with implementation becoming easier, teams can make more decisions in the same period. Each decision may be reasonable on its own but can create duplicate capabilities or incompatible technical direction.
Scaling judgement cannot happen through escalating more decisions to middle managers, because then they would become the next bottleneck. They need to give EMs enough context and authority by clarifying responsibilities and decision boundaries, intervening only on high-level cross-team decisions, like resolving structural dependencies the EMs cannot remove themselves. To help smooth the transition to extra autonomy, they will need to coach EMs to own the cross-team implications of their decisions, rather than saving them from every poor decision.
When engineering middle managers fail to create these conditions, the work moves somewhere else in the system.
Staff+ engineers will also feel the impact of over-stretching engineering middle managers: when EMs are overwhelmed and executives are far from the detail, Staff+ engineers could inherit informal management responsibilities, reducing their capacity for critical responsibilities like horizon scanning and setting architectural direction. This comes at the worst time possible, because when AI is generating considerably more software than before, we would have our best technical people plugging organisational gaps instead of focusing on architecture, system design and ensuring organisational decisions are based on technical reality.
Connecting implementation with commercial value
As expectations evolve, the accountability between Product and Engineering stays clear even as their work overlaps more: Product owns why an outcome matters and whether it creates value, Engineering owns how to deliver it well and the trade-offs required to do so, and both agree if the combined case justifies the investment. Engineering middle managers must not absorb Product’s work or simply process a larger roadmap, focusing instead on working together to handle the increased velocity of decisions. When validated ideas are not ready for the available engineering capacity, Product and Engineering can agree to redirect some of that time to discovery, evaluation, or improving the existing product.
The impact goes beyond Technology: if the product teams produce more output than Sales, Marketing and Customer Success can process, the Product-Engineering partnership cannot simply consider what teams can produce; they also need to ensure the wider organisation can sell and support it, and customers can adopt it. If Sales haven’t finished learning how to pitch the latest feature releases, they might be unable to pay attention to the next round of releases, with the same happening to Customer Success when trying to support customers. Faster implementation needs to be aligned with the capacity of the rest of the company in order to create value.
Reshaping the layer around work complexity
As the constraints change, some organisations may need fewer middle managers and broader spans, but the shape of the organisation needs to follow the complexity of the work, not the other way around.
Engineering middle managers working at the right altitude can lead a wider area if cognitive load is manageable, cross-team coupling is low and the EMs are mature. However, changing the structure without a detailed plan could move decisions to the wrong level, with weak assumptions, poor prioritisation and fragmented decisions accumulating long before they become visible in the teams’ outcomes.
AI exposes inefficient structures, leaders working at the wrong altitude, and new needs as the bottlenecks change. The companies that evolve engineering middle management around the complex decisions required for the work will be the ones transforming the increased implementation capacity into commercial value.