Smaller Delivery Units, Wider Management Spans

A short manifesto for making the engineering organisation follow the work.

This manifesto brings together three arguments developed in longer essays: AI is changing what engineers need from managers, the product development team need not remain the smallest unit of delivery, and engineering judgement matters more as implementation becomes abundant. The essays contain the evidence and qualifications. This is the operating model they imply.

AI helps engineers cross technical boundaries and deliver end-to-end changes with fewer compulsory handoffs. Our position is that a bounded engineering outcome should be carried by the smallest unit able to deliver it safely, sometimes one engineer, while responsibility for operating and changing the result remains collective. Management spans can widen only where this delivery model and its supporting systems remove routine coordination from the manager.

AI does not manufacture engineering judgement. It expands the implementation surface over which existing judgement can act. Scope must still follow demonstrated judgement, risk and available support. Routing unfamiliar work through managers, permanent teams or assigned specialists can create avoidable delay and teach engineers to wait for help they do not need. The objective is safe, direct action with support when needed.

1. AI extends reach, not judgement

AI can produce substantial implementations and plausible design options. The engineer must decide what belongs in the system, identify unsafe assumptions, test the design against evidence and answer for what reaches production.

Recognise senior engineers for the architecture and consequential decisions that keep systems coherent, not for code volume or line management responsibility. Technical judgement should carry status, pay and authority without requiring reports. The engineer carrying the outcome decides within agreed boundaries; Principal Engineers and specialists challenge consequential choices rather than approve every step.

Scope should follow demonstrated judgement. A less experienced engineer may carry a small, reversible change; a senior engineer may carry work across several systems with greater architectural or operational consequence. Either may be a delivery unit of one. The breadth, consequence and support differ; the standard of accountability does not.

2. Delivery units can become smaller

The stable Product, Design and Engineering community has often been both the boundary of ownership and the default unit of delivery. The boundaries need not remain identical.

The product bet remains shared. Product leads prioritisation and evidence of customer value; Engineering leads delivery and operability. Design and other disciplines contribute where the outcome requires them. The idea may originate anywhere, and participation should follow uncertainty and consequence, not a fixed staffing pattern.

One engineer or a temporary pairing may carry a bounded engineering outcome from agreed intent to production. The community retains operational responsibility and long-term stewardship. An outcome is complete only when it operates safely and another qualified engineer can understand, change and support it.

This applies chiefly to product development. Platforms, site reliability and systems requiring continuous ownership still need stable stewardship teams, even where individuals carry bounded changes.

3. Management spans can widen

Delivery-unit size and management span answer different questions. A manager can support more engineers when ordinary delivery no longer depends on them allocating work, resolving routine dependencies or supplying all technical guidance.

Ask what must come from the line manager. Performance, reward, promotion, fairness, development, conflict and private support require clear employment accountability. Principal Engineers and code-owning communities can provide technical direction, Product can provide product direction, engineers can coordinate delivery, and peers can mentor and give feedback. These contributions inform people decisions without creating shadow managers. The manager protects organisational health and handles exceptions rather than routing routine work.

Managers remain technically active, but delivery must not depend on their individual output. Spans widen only after routine coordination and normal delivery commitments leave the role. Adding reports to an unchanged job is overload.

One manager for every six engineers is not a rule to replace with another fixed ratio. The right span follows the work that remains uniquely managerial and the attention people need. It can widen only while engineers act within agreed boundaries without routine managerial permission, managers notice who needs attention and private access remains easy. When those conditions fail, remove work from the manager or narrow the span.

What the model requires

Remove routine dependencies

• Work in public unless there is a reason it cannot. Put intended outcomes, work in progress, questions, decisions and reasoning in shared internal channels and repositories, not private messages or one-to-one meetings. This invites contribution while change is cheap and makes knowledge reusable. Keep personal, sensitive and protected matters private.
• Make routine delivery self-service. Platforms, documentation, fast tests, observability and deployment paths should let engineers investigate, change, release and diagnose systems without seeking permission or favours. Fast feedback lets engineers test small, reversible decisions instead of escalating them in advance.
• Make inner sourcing the default. Let engineers contribute across codebase boundaries through documented standards, clear shared ownership and agreed service levels for review and, where the standards are met, acceptance. Ownership should follow demonstrated knowledge, and no repository should depend on one person. Code owners protect coherence and operability; sufficient review capacity must prevent ownership becoming a new queue.

Preserve coherence and control

• Coordinate across outcomes without recreating the squad. Product leadership limits simultaneous bets and preserves a coherent customer experience. Technical leaders and code-owning communities expose adjacent changes and protect consistent behaviour across systems. When outcomes collide, the people involved coordinate directly; possible future interaction does not justify a permanent delivery unit.
• Automate routine controls and concentrate human judgement. Tooling should enforce syntax, style, conventions and repeatable security checks on every merge request. Code review remains mandatory, but human reviewers should focus on correctness, architecture, behaviour, operability, customer impact and risks that tools cannot settle. A Principal Engineer should challenge cross-cutting architectural choices; consequential or hard-to-reverse risks require independent specialist review. Engineers remain accountable for AI-assisted work.
• Keep shared expertise accessible, not centralised. Principal Engineers, Security and other specialists should publish reusable reasoning and encode repeatable decisions into platforms and standards. They intervene when their judgement is needed, not as universal gates or hidden queues.

Sustain capability and management support

• Develop capability deliberately. Pairing, sponsorship, progressively larger outcomes and expert support must build judgement and remain fairly available. A unit of one must not mean learning alone.
• Use attention according to need. Coaching and feedback continue through the work, with reliable private access to the manager. Formal career and performance conversations remain at least quarterly, staggered through the year rather than compressed into organisation-wide windows. They do not replace continuing contact.

The organisational consequence

The organisation chart should follow the work. Use the smallest unit that can safely carry a bounded engineering outcome, given the judgement demonstrated, the risk involved and the support available, while leaving responsibility for operating and changing the result with the product community. Where that delivery model, together with strong platforms, visible work, automated controls and accessible expertise, removes routine coordination from the manager, management spans can widen.

Wider spans may mean fewer dedicated line-management roles. That is a consequence, not the objective. This changes the number and nature of those roles and frees capacity for engineering and other valuable work. The objective is autonomy proportionate to demonstrated judgement and risk, with support available when needed, not its withdrawal.

This is not a new universal structure or another sacred ratio. Begin with the work. Reduce the handoffs it no longer needs, preserve the support and challenge it still does, and let the organisation chart record the result.