Managing the System That Does the Work

AI Native Operating Model · Part 6 of 7

Ask a manager in a software delivery organisation how they spent last week. They probably spent hours checking progress, resolving dependencies, following up on blockers, adjusting priorities and preparing updates for senior leadership.

Coordination takes up so much management time because information is scattered across teams and systems. Someone has to gather it, work out what needs attention and communicate it to everyone involved. Organisations have built elaborate processes and management structures around that responsibility.

AI agents are changing how this coordination happens. When progress is recorded automatically, dependencies can be checked directly and the state of delivery is visible, managers have less reason to spend their days collecting and relaying information. Agents do not need managerial abilities to make this possible. The information simply needs to be available in a form that people and machines can act on.

As coordination becomes less demanding, managers can concentrate on decisions that require human judgment: setting direction, defining acceptable risks, determining where autonomy should end and developing the people who will eventually take responsibility for those decisions.

These have always been management responsibilities, but they have competed with the daily demands of delivery. Organisations now need to reconsider how management works when coordination no longer occupies most of the role.

What managers actually spend their week on#

Management has traditionally involved both coordinating delivery and making decisions about its direction.

Assigning tasks, tracking progress, resolving scheduling conflicts and preparing status reports help teams work together when information is spread across an organisation. These activities are necessary in conventional delivery environments, but they contribute indirectly to the outcomes teams are trying to achieve.

Managers also decide which trade-offs are acceptable, when to change direction, how to allocate scarce expertise and when an agent should escalate rather than proceed. They establish the delegation boundary, determine risk tolerance and help people develop the judgment required for greater responsibility.

Traditional management systems focus heavily on the coordination responsibilities. Progress tracking, reporting structures and recurring meetings are designed to keep delivery organised.

AI native management changes the balance. Managers still need visibility into delivery, but their contribution increasingly depends on the quality of their decisions and the conditions they establish for people and agents.

Existing management tools provide considerably more support for tracking tasks than for managing judgment, autonomy and long-term capability development.

Why coordination is the first thing to go#

A control room that makes delivery state directly accessible reduces the need for managers to collect that information manually.

If every mission has a recorded state, supporting evidence and a list of unresolved decisions, progress can be inspected without asking each team for an update. Agents can receive briefs and execute within defined boundaries, while routine task allocation can follow established routing rules.

Dependencies can also be expressed as conditions that a workflow checks automatically. Instead of repeatedly asking whether another team has completed something, the process can respond when the necessary condition is met.

This requires reliable information and clearly defined rules rather than sophisticated managerial intelligence.

Coordination has been expensive because people cannot continuously observe everything happening around them. Making delivery state accessible to both humans and machines removes some of the work previously required to maintain that visibility.

Managers remain responsible for decisions about priorities, acceptable risk and the limits of autonomy.

Part 5 examined why human approval needs more than a button asking someone to accept an agent's result. The same principle applies at management level. As routine coordination becomes automated, managers need better ways to understand where judgment is required and exercise it without becoming a bottleneck.

Why managing the system matters more than managing tasks#

W. Edwards Deming argued that organisational performance depends heavily on the conditions in which people work.

In Out of the Crisis, he attributed the overwhelming share of performance variation to the system rather than individual workers, describing the split as "94% belongs to the system (responsibility of management), 6% special".¹

His argument challenged the tendency to respond to poor performance by putting greater pressure on individuals when the causes often lie in processes, constraints and organisational design.

The same principle applies to agent-driven delivery.

An agent's behaviour depends on its context, available tools, permissions, validation mechanisms and escalation rules. These conditions are established by the organisation. When agents repeatedly encounter the same problems, changing individual prompts may accomplish less than improving the environment in which they operate.

Management therefore becomes increasingly concerned with designing and improving the system that translates organisational intent into outcomes.

That includes deciding which work can safely be delegated, which constraints must be enforced and where people need to retain authority.

Which three jobs were bundled into one#

The traditional manager role contains three responsibilities that operate over different time horizons and require different skills.

Mission leadership is accountable for an outcome. It determines what the team should achieve, which trade-offs are acceptable and when priorities or direction need to change.

People leadership focuses on coaching, feedback, capability development, career progression and wellbeing. Its responsibility extends beyond any particular mission, especially when developing professional judgment takes years.

System management concerns the infrastructure and processes through which people and agents deliver outcomes. It includes workflow design, delegation rules, validation, platform capabilities and reducing system debt.

The difficulty with assigning all three to one manager is that immediate delivery pressure tends to dominate. Deadlines receive attention now, while capability development and operating-system improvements can be postponed.

Separating these responsibilities could allow organisations to manage them more deliberately, but it also creates questions about accountability.

If mission leaders want faster execution, people leaders need time for development and system managers want stronger safeguards, someone must have the authority to resolve the disagreement.

What Spotify's split actually failed at#

Spotify attempted a similar separation between work direction and people management.

Its widely discussed model assigned product owners responsibility for squad priorities, while chapter leads supported engineers within their professional specialisms. The approach influenced organisational design well beyond Spotify.

However, the public description was never fully implemented as presented.

Joakim Sundén, an agile coach at Spotify from 2011 to 2017, later explained that "Even at the time we wrote it, we weren't doing it." He described the model as "part ambition, part approximation".²

His account identified an accountability problem. Without a single engineering manager responsible for the engineers in a squad, product managers sometimes had to negotiate disagreements directly with individual engineers. Chapter leads supported professional development but lacked clear delivery accountability.

As Sundén put it: "They don't have really any accountability for the delivery."

The experience illustrates the risk of separating responsibilities without establishing who can resolve conflicts between them.

Hybrid organisations face a comparable challenge when mission leadership, people development and system management become distinct functions. Decision rights must be explicit before reporting lines change.

Spotify's experience remains a practitioner account rather than controlled evidence about organisational effectiveness. It identifies a credible failure mode, but does not establish whether separating these roles is generally better or worse.

Why cadence stops paying for itself#

Scrum and similar delivery frameworks establish regular planning and review cycles to help people coordinate their work.

The Scrum Guide describes sprints as "fixed length events of one month or less to create consistency".³ That consistency helps teams plan, manage dependencies and review outcomes at predictable intervals.

Agent-driven delivery changes the value of some of those routines.

Agents can execute continuously, while exceptions and decisions arise whenever the workflow reaches them. A fortnightly planning cycle can introduce delays if work is waiting for a decision that could be made immediately.

For a hybrid team, flow-based processes may therefore be a better starting point. Limiting work in progress, making queues visible and starting new work when capacity becomes available allow teams to respond to changing conditions without relying entirely on scheduled ceremonies.

The Kanban Guide describes how limiting work in progress "should create a pull system" in which available capacity determines when new work begins.⁴

The evidence comparing these approaches is limited. A 2022 systematic literature review examined 38 empirical sources covering Scrum, Kanban and hybrid models, with only two using experimental methods. It found a general advantage for Kanban, but recommended combining approaches according to context rather than replacing one with another.⁵

The argument for flow in agent-driven delivery is therefore primarily architectural.

When machines can execute continuously but human decisions remain constrained by available attention, the process needs to expose queues and manage work in progress.

Little's Law is often cited in support of these practices, but the causal argument comes more directly from queueing theory and Donald Reinertsen's work on how capacity utilisation affects waiting time and queue size.⁶

What a board would have to show to model the constraint#

Traditional delivery boards show task progress: what has started, what is blocked and what has been completed.

In agent-driven delivery, that view can overlook where work is actually waiting.

An agent may finish an implementation in minutes, but the result can remain unresolved until someone reviews its evidence, makes an architectural decision or approves a consequential change.

A hybrid delivery board should therefore represent judgment as work in progress.

Relevant information includes the autonomy level assigned to a mission, its delegation boundary, the validation evidence available, unresolved decisions and the people accountable for them. Waiting time in the decision queue, exception rates and system debt can reveal constraints that conventional task tracking misses.

A workflow might move through intent, readiness, delegation, execution, validation, judgment and completion. The exact stages will vary, but the board should make clear why work cannot advance.

Without that visibility, teams may invest in faster agents while completed work continues to wait for human decisions.

The throughput police pattern describes this problem: concentrating on visible output while neglecting the conditions that determine whether it becomes valuable.

How teams are being arranged around machine capacity#

Team Topologies provides a starting point for considering how organisations might structure work around agents.

At QCon London in March 2026, Matthew Skelton discussed applying its principles to agentic systems, including bounded authority, cognitive load and teams responsible for long-lived services.⁷

He also questioned why organisations might give an agent broad write access across internal data stores when they would hesitate to grant comparable permissions to a person.

These ideas have not yet been established as a validated organisational framework for agent-driven delivery. However, several patterns are emerging:

Mission teams retain stable human accountability for outcomes while drawing on machine capacity as needed.
Agent platforms provide shared tools, context, environments, permissions and validation.
Autonomy enabling teams improve the conditions for safe delegation by strengthening validation and reducing system debt.
Specialist judgment services provide scarce expertise in security, architecture, legal and domain decisions across multiple missions.
Enterprise steering resolves priorities and decision conflicts extending beyond individual teams.

These arrangements will depend on the type of work and the maturity of each organisation's agent infrastructure.

The organising principle is stable human accountability supported by flexible machine capacity. A mission still needs identifiable people responsible for its direction and consequences, even when the number of agents contributing to it changes.

This requires more thought than simply giving existing teams additional AI tools. It changes how organisations allocate execution capacity, expertise and responsibility.

How people used to acquire judgment#

As agents take over implementation tasks, organisations face a problem that cannot be solved simply by increasing automation: how will people develop the expertise needed to supervise work they have never performed themselves?

Software engineers have traditionally learned through repeated exposure to practical problems. They discover the consequences of poor database design, experience the difficulty of maintaining earlier decisions and gradually recognise which technical risks deserve attention.

That experience develops judgment alongside technical ability.

Lisanne Bainbridge examined a similar problem in her 1983 paper Ironies of Automation. She observed that physical skills "deteriorate when they are not used" and warned that "a formerly experienced operator who has been monitoring an automated process may now be an inexperienced one".⁸

She also argued that efficient retrieval of knowledge depends on frequent use and feedback, concluding that highly automated systems "may need the greatest investment in human operator training".

The problem is especially difficult for people entering software engineering today.

Experienced engineers can draw on years of implementation work. Junior engineers whose responsibilities increasingly involve reviewing and directing agents may have fewer opportunities to build comparable experience.

Software developers only, not all occupations. Each line is one age band measured against its own headcount in November 2022, the month ChatGPT was released. Developers aged 22 to 25 are down 19%; every band from 31 upwards has grown, and 41 to 49 has grown most. Note that this is a fall against their own starting point, which is a different measure from the 19% shortfall against less-exposed occupations cited later in this piece. The series is descriptive: it records what happened to headcount, not what caused it. Source: Stanford Digital Economy Lab, Canaries in the Coal Mine?, software developers in ADP payroll records, monthly to September 2026.

Kahneman and Klein's 2009 paper provides a framework for understanding the risk. They agreed that reliable intuitive expertise requires a sufficiently regular environment and "the individual's opportunity to learn the regularities of that environment".⁹

They also cautioned that "subjective experience is not a reliable indicator of judgment accuracy".

Someone may become confident supervising an automated process without developing the expertise required to recognise when it is going wrong.

This creates risks of skill atrophy, AI deskilling and automation complacency, especially when routine successes provide few opportunities to encounter difficult cases.

The deliberate-practice literature also warrants caution. A 2014 meta-analysis found that deliberate practice explained under 1% of performance variance in professions.¹⁰ Repetition alone does not guarantee expertise; the quality of the environment and feedback matters.

What aviation and surgery already found out#

Aviation has dealt with the consequences of increasing automation for decades.

In 2013, an FAA-convened working group identified concerns about pilots' manual flying capabilities, including recovery from unusual attitudes, transitions from automated control and the "definition, development, and retention of such skills".¹¹

The NTSB investigation of Asiana Airlines flight 214 raised related concerns. The airline emphasised automation during routine operations, and the NTSB concluded that additional manual flying experience would likely have helped the pilot recognise declining airspeed and respond appropriately.¹²

Healthcare has documented difficulties with maintaining practical expertise during training.

A 2013 survey of 91 fellowship programme directors found that only 33.7% believed incoming fellows could operate unsupervised for thirty minutes of a major procedure. Another 30% felt they could not independently perform a laparoscopic cholecystectomy.¹³

The causes remain contested, including the possible effects of duty-hour restrictions. Nevertheless, both industries show why changes in how people acquire experience deserve attention, particularly when they remain responsible for exceptional situations.

There may also be early labour-market implications.

Stanford's Canaries in the Coal Mine?, updated in August 2026 using ADP payroll data, found employment among workers aged 22 to 25 in AI-exposed occupations approximately 19% below the level implied by employment trends among similarly aged workers in less-exposed occupations.¹⁴

The difference appeared primarily through reduced hiring rather than increased separations. The authors emphasised that the findings are descriptive and do not establish that AI caused the change.

The figure represents a relative gap against a comparison group, not a 19% reduction in total employment.

Even with that qualification, reduced entry-level hiring raises a longer-term concern: organisations may need experienced professionals in the future while offering fewer opportunities for people to acquire the experience those roles require.

What might replace the apprenticeship#

The traditional apprenticeship model allowed people to develop expertise through progressively more demanding work, supported by feedback from experienced colleagues.

As agents absorb more routine implementation, organisations need deliberate ways to preserve those learning opportunities.

Several approaches deserve testing.

Shadow decisions allow junior engineers to assess a problem, record their proposed decision and compare it with the eventual outcome. They practise judgment without carrying full responsibility for the consequences.

Graduated decision rights expand authority as people demonstrate an ability to evaluate evidence, recognise uncertainty and make reliable decisions.

Exposure to exceptions gives engineers opportunities to investigate difficult failures and unfamiliar situations, where deeper understanding is often developed.

Post-decision reviews help teams examine the assumptions and reasoning behind decisions rather than judging them solely by whether the outcome was successful.

Human-machine comparisons can reveal differences in assumptions, reasoning and risk assessment when people and agents address the same problem.

Organisations may also need to preserve some hands-on implementation work for its developmental value, even when an agent could complete it faster.

None of these approaches has been established as a general solution to the automation paradox. Their value needs to be evaluated through improvements in judgment, rather than simply counting participation.

The goal is to ensure that people retain sufficient technical understanding and practical experience to assess the systems they supervise.

That is central to the seniority shift. If an organisation cannot explain how its next generation of senior engineers will acquire judgment, its operating model has an unresolved capability problem.

The consequences may remain hidden for years because today's experienced engineers can continue relying on knowledge acquired before agent-driven delivery became widespread.

What the flattening evidence actually says#

Organisations are already experimenting with fewer management layers, but the relationship between AI adoption and flatter hierarchies needs careful interpretation.

Ewens and Giroud's Corporate Hierarchy, dated September 2026, analysed 18.1 million workers' résumés across 3,454 US public firms between 2015 and 2024.¹⁵

The researchers found that "firms flatten their hierarchies following the adoption of AI technologies".

This establishes a relationship between AI adoption and organisational structure, but individual restructuring decisions can have several causes.

In September 2024, Amazon instructed its organisations to increase the ratio of individual contributors to managers by at least 15% by the end of the first quarter of 2025.¹⁶

Amazon described the objective as reducing bureaucracy, removing unnecessary management layers and improving speed. AI was not part of the stated rationale.

A flatter organisation may result from automation, cost reduction, improved processes or a deliberate effort to simplify decision-making. These reasons can overlap, but they should not be treated as interchangeable.

Agents may eventually reduce the need for some coordination roles and management layers. The available evidence does not yet establish how widely this will happen or which responsibilities will move elsewhere.

Organisations considering restructuring should begin with the responsibilities they need performed and the decisions that require accountability, rather than assuming that adopting AI automatically makes a management layer unnecessary.

What to change first#

Organisations can begin adapting management to agent-driven delivery without immediately reorganising their teams.

First, separate coordination from accountability.

Identify the recurring decisions managers make, distinguish those that can be governed through rules from those requiring judgment, and establish clear authority for consequential choices. This should include how conflicts between delivery priorities, capability development and system safeguards are resolved.

Spotify's experience shows why those boundaries need to be explicit before responsibilities are divided across different roles.

Second, make decisions waiting for human attention visible in the delivery process.

Record who is responsible, what evidence is available and how long each decision has been waiting. Teams can then determine whether progress is constrained by execution, validation or human judgment.

Third, examine how future senior engineers are developing their expertise.

Identify the people who will be expected to make consequential technical decisions over the next five years. Consider the problems they encounter, the feedback they receive and the opportunities they have to develop an understanding of the systems they will eventually oversee.

If their work increasingly involves supervising agents, their learning and development need to reflect that change.

As coordination becomes more automated, management will depend increasingly on the quality of the operating environment, the decisions people make and the expertise the organisation continues to develop.

The final article in this series examines how to improve a system in which human learning and machine execution operate at different speeds, and what organisations should measure as they do so.

Sources and further reading#

W. Edwards Deming, Out of the Crisis, MIT Press. The frequently quoted line about a bad system beating a good person every time is from an attendee's notes of a 1993 seminar and is not in his published work. ↩
Jeremiah Lee, "Failed #SquadGoals". Quotations are from Joakim Sundén, an agile coach at Spotify from 2011 to 2017. Practitioner account, not a study. ↩
Ken Schwaber and Jeff Sutherland, The Scrum Guide, 2020. ↩
The Kanban Guide. ↩
Necmettin Ozkan, Tugba Gurgen Erdogan, Sevval Bal and Mehmet Sahin Gok, "Scrum, Kanban or a Mix of Both? A Systematic Literature Review", FedCSIS 2022. 38 empirical sources, of which two used an experimental method. ↩
Donald Reinertsen, The Principles of Product Development Flow, pp. 59 and 75. ↩
Matthew Skelton, QCon London, March 2026; reported by InfoQ, 31 March 2026. A conference talk, not a publication. ↩
Lisanne Bainbridge, "Ironies of Automation", Automatica, volume 19, issue 6, 1983, pages 775-779. No stable open-access copy; the paper is available through Elsevier. ↩
Daniel Kahneman and Gary Klein, "Conditions for Intuitive Expertise: A Failure to Disagree", American Psychologist, 2009. ↩
Brooke Macnamara, David Hambrick and Frederick Oswald, "Deliberate Practice and Performance", Psychological Science, 2014. ↩
Flight Deck Automation Working Group, Operational Use of Flight Path Management Systems, FAA, 2013. ↩
National Transportation Safety Board, accident report on Asiana Airlines flight 214, 2014. ↩
Samer Mattar and colleagues, "General surgery residency inadequately prepares trainees for fellowship: results of a survey of fellowship program directors", Annals of Surgery, September 2013. 91 of 145 programme directors responded. Duty-hour limits are a competing explanation for the finding. ↩
Erik Brynjolfsson, Bharat Chandar and Ruyu Chen, Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence, Stanford Digital Economy Lab, August 2026. The authors state the findings are descriptive rather than causal. ↩
Michael Ewens and Xavier Giroud, Corporate Hierarchy, September 2026. ↩
Andy Jassy, message to Amazon employees, 16 September 2024. ↩

Background: Peter Naur, "Programming as Theory Building", Microprocessing and Microprogramming, 1985, on why a program's theory cannot be revived from its documentation.

Previously in the series: Human in the Loop Is Not a Design

Next in the series: Optimising the Hybrid Flow

Can you say how your next seniors will learn judgment? We run operating-model assessments to identify where coordination can be automated, where human decisions remain essential, and how organisations can develop the judgment they will depend on as agent-driven delivery grows. info@re-cinq.com