Designing how work flows

Process exists to serve delivery, not the reverse, and v1.0 framed this competency as choosing the lightest process that works. v3.0 widens it to designing the flow of work as a whole: the ceremonies and cadences a team runs, the developer platform and tooling it works through, and the AI assistance that has become part of how code is written, reviewed and shipped. These are one object because they fail the same way — structure adopted because it is standard rather than because it solves a named problem, tooling that happens to a team rather than being designed for it — and because the diagnostic question is the same for all of them: what problem is this solving, and is it still solving it? It matters because adding process is easy and removing it is hard, because developer experience is where a large share of an organisation's engineering capacity is silently spent or saved, and because AI assistance changes review, testing and ownership whether or not anyone has decided how. The examinations test it through the zombie ceremony, the velocity that drops while everyone is busy, the standard applied to team internals while boundaries stay chaotic, and the planning cycle that produces a stale plan.

1. Choose the minimum structure that solves the actual problem. Enough to coordinate and create predictability; not so much that it becomes ceremony. The bias runs light, and structure scales with the situation, not with fashion.
2. Every ritual answers the question: what problem is this solving now? A practice that no longer earns its cost is pruned. Adopting, adapting and dropping are all ordinary.
3. Standardise where teams meet; leave the inside to the team. Interfaces, a consistent floor for what "done" means where work crosses a boundary, shared reporting language — these are standards. Tools, ceremonies and style inside a team are the team's.
4. Throughput problems are usually flow problems. A team that is busy and ships nothing has fragmentation, interruption and too much in flight; the fix is the flow of work, not more effort from the people.
5. Developer experience is capacity. The friction between an engineer and a shipped change — build times, environments, review latency, tooling — is a cost paid on every change. Investing in it is investing in throughput, measured by what teams can now do.
6. AI assistance is designed into the workflow, or it happens to it. What it changes about review, testing and ownership is decided explicitly; its effect is measured honestly, including where the honest answer is that it is not helping.

This unit has more contested ground than most, because the evidence on AI assistance is recent and mixed, and the unit says so rather than picking the convenient studies.

Team topologies and cognitive load practice

The framework in Matthew Skelton and Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow (2019): teams have a limited cognitive load, the shape of a team and its interaction modes with other teams should be designed around that limit, and a platform team exists to reduce the load on the teams that ship product. For this unit its value is the design stance: how work flows is a thing to be designed, and the platform is part of the design rather than infrastructure that happens to exist.

Aligned autonomy practice

The organising principle for what to standardise across teams: direction, priorities and boundary standards set centrally; methods left to teams. Standardise where teams meet — interfaces, the floor for "done" where work crosses a boundary, the vocabulary of status — and leave tools, ceremonies and style inside a team to the team. It has no single author; it is the position that organisations converge on after trying both extremes, and its limit is that the line between "where teams meet" and "team internals" is itself a judgment, redrawn when a boundary fails rather than when one team's internals differ from another's.

Developer experience research

The framework in Abi Noda, Margaret-Anne Storey, Nicole Forsgren and Michaela Greiler, DevEx: What Actually Drives Productivity (2023), from researchers who had previously run the DORA programme, identifying three dimensions that drive productivity as engineers experience it — feedback loops, cognitive load, and flow state — and arguing that they are measurable and improvable. Its evidence base is survey research across many organisations, and its practical consequence is that developer-experience investment can be measured by the friction it removes rather than by the tooling it installs.

Goodhart's law practice

The observation, in the form given by Marilyn Strathern, 'Improving Ratings': Audit in the British University System (1997), that when a measure becomes a target it ceases to be a good measure. For this unit it is the reason healthy velocity numbers can coexist with flat outcomes: the metric is measuring activity, and the cadence built on it is optimising the wrong thing. The general treatment of metrics is SV-5 Engineering metrics and measurement.

AI-assisted developer productivity contested

Two kinds of evidence that do not yet agree. The controlled experiment in Sida Peng, Eirini Kalliamvakou, Peter Cihon and Mert Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot (2023) found developers completed a defined task substantially faster with an AI coding assistant. The randomised trial in Joel Becker, Nate Rush, Elizabeth Barnes and David Rein (METR), Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (2025) found experienced developers working in their own mature repositories were slower with AI tools than without, while believing they were faster. The studies measured different things — a well-specified task against real work in a complex codebase — and the honest position for a manager is that the effect depends heavily on the work, the codebase and the engineer, that self-reports of speed-up are unreliable, and that the effect has to be measured in the team's own conditions. What is not contested is that the tools change what review must establish, which is TJ-3 Code review and quality standards, and introduce risks that need governance, which is TJ-5 AI-assisted engineering.

The operating cadence practice

Not a named model but the executive-scope practice this unit treats as the organisation's process: the rhythm of planning, review and escalation through which it senses and responds. A sound cadence is light and rolling against stable priorities, includes an evidence-based review of the portfolio, has explicit escalation paths with known triggers, and reserves time for correction. Its failure is planning theatre — weeks of ceremony for a plan that is stale within a month — and its principle is that at scale responsiveness improves execution and more detailed central planning does not.

The ritual audit

Twice a year, each recurring meeting and practice the team runs is listed with the problem it solves. Anything without a current problem is dropped for a month; if nobody notices, it stays dropped. The exercise is cheap and its usual result is that a third of the calendar was ceremony.

The flow review

When throughput drops, the manager looks at the flow before the people: how many things are in progress, how many are blocked and on what, how much of each engineer's week is interruption. The output is a change to the flow — a work-in-progress limit, a fixed interruption rota, a batch of blocked work unblocked at once — rather than a request for more effort.

Standards at the seams

For a group of teams, a short written list of what is standard because work crosses boundaries — interface conventions, the floor for "done", the reporting vocabulary — and an explicit statement that everything else is the team's own. The list is reviewed when a boundary fails, not when a team's internals differ from another's.

Measuring developer experience

At a fixed cadence, the friction between an engineer and a shipped change is measured in the engineers' own terms: build and test times, environment setup, review latency, and a short survey on feedback loops, cognitive load and flow. Investment is prioritised by the friction removed, and reported the same way.

Introducing AI assistance deliberately

When AI tooling is introduced, the team decides three things in writing: what review must now establish for generated code, who owns a change regardless of what produced it, and how the effect will be measured in the team's own conditions. Adoption is not the measure; licences used is not the measure. Whether the team can now do something it could not, at a quality it can defend, is.

At team scope the object is the team's own process and tools, and the manager adopts, adapts and prunes directly. At organisational scope the object becomes consistency and autonomy across teams — what is standard because work crosses boundaries and what is left inside them — and the developer platform as a department-scale investment measured by what teams can now do. At executive scope the object is the organisation's operating system: the cadence of planning, review and escalation, the standards at organisational boundaries, and the investment in developer experience and AI-assisted work as strategic bets; the executive designs the system that executes rather than executing personally. The pattern is in How Judgment Scales; the structure the flow runs through is SV-6 Organisational design and leading change.

• Adopts a practice to solve a named problem and prunes it when it stops earning its cost. team
• Adapts frameworks to the team rather than following them dogmatically. team
• Reads a throughput drop as a flow problem — interruptions, fragmentation, too much in flight — and changes the flow rather than pushing the people. team
• Introduces AI tooling with explicit decisions about review, ownership and measurement. team
• Failure mode — heavyweight frameworks adopted because they are standard. team
• Failure mode — zombie ceremonies. team
• Failure mode — equating more process with more rigour. team
• Failure mode — big-company process on a tiny team. team
• Failure mode — an AI rollout measured by adoption, or by self-reported speed.
• Standardises where teams meet — interfaces, a floor for "done" at the seams, shared reporting language — and leaves team internals alone. org
• Judges cross-team rituals by the risks they surface, not the attendance they command. org
• Invests in developer experience at department scale, measured by friction removed. org
• Governs AI-assisted work across teams proportionately, and reads where it is eroding understanding rather than adding leverage. org
• Failure mode — standardising team internals while boundaries stay chaotic. org
• Failure mode — meeting inflation as the answer to every coordination failure. org
• Failure mode — a definition of done nobody enforces at the seams where it matters. org
• Runs a light, rolling planning cadence against stable priorities, with evidence-based portfolio review and explicit escalation triggers. exec
• Sets direction, priorities and boundary standards centrally and leaves methods to teams. exec
• Measures delivered outcomes, and recognises a dashboard of healthy activity over flat outcomes as measuring motion. exec
• Decides the organisation's investment in developer experience and AI-assisted work as a strategic bet and reports its effect honestly. exec
• Builds the system that executes rather than executing personally, and holds directors accountable for execution. exec
• Failure mode — planning theatre: weeks of ceremony for a stale artifact. exec
• Failure mode — centralising methods instead of direction. exec
• Failure mode — the executive as the organisation's most senior programme manager. exec

Structure versus lightness. Too little structure and a growing team loses predictability; too much and it loses the time the structure was meant to protect. The judgment is in scaling structure with the situation and in the willingness to remove what was added when the situation changes.

Consistency versus autonomy. Every standard imposed on a team's internals costs the team something and buys the organisation something; most such standards buy less than they cost. The line at the boundary is the resolution, and it is redrawn only when a boundary fails.

Investment versus delivery. Developer-experience work competes with features for the same people and shows its return later and less visibly. The judgment is in measuring the friction so that the return is visible, and in holding the investment against a quarter's urgency.

Adoption versus understanding. AI assistance can raise output while lowering the team's understanding of its own systems, and the second effect is slower to show than the first. The resolution is to design the review and ownership rules before the adoption, and to measure understanding as well as throughput.

Planning versus responsiveness. A detailed plan reassures and is stale within a month; a rolling cadence is harder to communicate and stays true. At scale the evidence favours responsiveness, and the tension is mostly with the stakeholders who want the reassurance of the detailed plan.

A head of engineering inherits an organisation whose quarterly planning consumes three weeks of every quarter. Every team produces a detailed plan, the plans are reconciled in a series of long meetings, and the result is a document that leadership approves with some ceremony and that is stale within a month, because priorities shift, dependencies slip, and nobody has time to re-plan. Teams have learned to plan defensively; the document is treated as a contract by stakeholders and as fiction by engineers. The chief executive, who likes the document, has asked for the next cycle to be more thorough.

The pull is to comply and improve the ceremony: a better template, a planning tool, a longer horizon. That makes the theatre more expensive. The diagnosis is that the cadence is inverted — a large central planning effort against unstable priorities, with no time reserved for correction — and at this scale more detailed central planning does not improve execution; responsiveness does.

The head of engineering replaces the cycle rather than refining it. Priorities are set and held stable for the quarter at the portfolio level, in a short, evidence-based review with the executive team. Teams plan in rolling six-week horizons against those priorities, in a day rather than three weeks, and re-plan when something material changes. A monthly review examines evidence — what was meant to be true by now, and is it — and has explicit triggers for escalation. Standards are set at the seams: how teams state dependencies, what "committed" means, and the vocabulary of status. Inside those, each team runs whatever process it finds works.

The chief executive's concern is addressed directly, in their terms. They want confidence that the organisation knows what it is doing; the head of engineering shows them that the old document delivered the feeling of that and not the fact, and that the new cadence will give them a true picture monthly instead of a false one quarterly. They commit to reporting delivered outcomes against the stable priorities, and they say plainly that the first quarter will look less tidy.

What the head of engineering does not do is take on the coordination personally. The temptation, with the old cycle gone, is to be the person who knows everything; the design is that directors own execution within the cadence, and the head of engineering runs the system, not the programmes.

• DE-1 Prioritisation under constraint — the stable priorities the cadence plans against, and work-in-progress limits as flow.
• DE-2 Estimation, planning, and honest commitments — batch size and predictability; what "committed" means at the seams.
• TJ-3 Code review and quality standards — what review must establish for AI-generated code, and the quality floor at boundaries.
• TJ-5 AI-assisted engineering — the governance and risk of AI-assisted engineering.
• SV-5 Engineering metrics and measurement — measuring outcomes rather than motion; Goodhart's law in full.
• SV-6 Organisational design and leading change — the team boundaries and platform structure the flow runs through.

1. What question should be asked of any ritual?
   Answer

   What problem is this solving, and is it still solving it? A practice with no current answer is pruned; adding process is easy and removing it is hard, so the bias runs light.
2. Velocity has dropped for three sprints; engineers say they are busy but nothing ships. What do you look at first?
   Answer

   The flow, not the people: how much is in progress, what is blocked, how much of each week is interruption. The fix is a change to the flow — a work-in-progress limit, an interruption rota, blocked work cleared in a batch — not more effort.
3. What belongs in an organisation-wide standard and what should stay team-local, and why is the boundary the answer? org
   Answer

   Standards belong where teams meet — interfaces, a consistent floor for "done" where work crosses a boundary, shared reporting language — because that is where one team's variation becomes another team's incident. Inside a team, tools, ceremonies and style are the team's own, because standardising them costs more than it buys.
4. How should a department-wide rollout of AI tooling be measured? org
   Answer

   By what teams can now do, at a quality they can defend, in their own conditions — not by licences used, adoption rates or self-reported speed, which the evidence shows is unreliable.
5. What do the two kinds of evidence on AI-assisted productivity say, and what is the honest management position?
   Answer

   A controlled experiment on a defined task found a large speed-up; a randomised trial on experienced developers in their own repositories found a slowdown they did not perceive. The effect depends on the work, the codebase and the engineer, self-reports are unreliable, and it must be measured in the team's own conditions.
6. Why does more detailed central planning fail at scale, and what should an operating cadence optimise for instead? exec
   Answer

   Because the plan is stale before it is finished and the ceremony consumes the capacity it was meant to direct. The cadence should optimise for responsiveness: stable priorities, rolling short-horizon plans, evidence-based review, explicit escalation triggers, and time reserved for correction.
7. What has an executive who personally drives the most critical programme stopped doing? exec
   Answer

   Running the system that runs everything else. Their role is to set direction, keep the environment unblocked, and hold directors accountable for execution.

• Matthew Skelton and Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow (2019) — team shapes, interaction modes, cognitive load, the platform team.
• Abi Noda, Margaret-Anne Storey, Nicole Forsgren and Michaela Greiler, DevEx: What Actually Drives Productivity (2023) — the developer-experience framework: feedback loops, cognitive load, flow state.
• Marilyn Strathern, 'Improving Ratings': Audit in the British University System (1997) — the standard phrasing of Goodhart's law.
• Sida Peng, Eirini Kalliamvakou, Peter Cihon and Mert Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot (2023) — the controlled experiment on AI-assisted task completion.
• Joel Becker, Nate Rush, Elizabeth Barnes and David Rein (METR), Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (2025) — the randomised trial on experienced developers' productivity with AI tools.