Designing how work flows

Process exists to serve delivery, and never the reverse. Version 1.0 framed this competency as choosing the lightest process that works. Version 3.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 is now part of how code is written, reviewed and shipped. These belong together as one object for two reasons. They fail in the same way, through structure adopted because it is standard when it solves no named problem, and through tooling that is imposed on a team without being designed for it. And the diagnostic question is the same for all of them: what problem is this solving, and is it still solving it? The competency matters because process is easy to add and hard to remove, because developer experience is where a large share of an organisation's engineering capacity is quietly 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 falls while everyone is busy, the standard applied to the inside of teams while the boundaries between them stay chaotic, and the planning cycle whose output is already stale.

1. Choose the minimum structure that solves the actual problem. Use enough structure to coordinate and to create predictability, and stop before it becomes ceremony. The bias is towards less, and structure grows 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 gets pruned. Adopting, adapting and dropping practices are all routine.
3. Standardise where teams meet; leave the inside to the team. Interfaces, a consistent floor for what "done" means where work crosses a boundary, and a shared language for reporting are the proper subjects of standards. Tools, ceremonies and style inside a team belong to the team.
4. Throughput problems are usually flow problems. A team that is busy and ships nothing is suffering from fragmentation, interruption and too much in flight. The fix lies in the flow of work, and asking the people for more effort will not supply it.
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. Investment in it is investment 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 when the honest answer is that it is not helping.

This unit covers more contested ground than most, because the evidence on AI assistance is recent and mixed. The unit says so and does not pick 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) holds that teams have limited cognitive load, that the shape of a team and its modes of interaction with other teams should be designed around that limit, and that a platform team exists to reduce the load on the teams that ship product. What this unit takes from it is the design stance. How work flows is something to be designed, and the platform is part of that design, not infrastructure that happens to exist.

Aligned autonomy practice

This is the organising principle for deciding what to standardise across teams. Direction, priorities and boundary standards are set centrally, and methods are left to the 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 that team. It has no single author. Organisations converge on this position after trying both extremes. Its limit is that the line between "where teams meet" and "team internals" is itself a judgment. That line is redrawn when a boundary fails, and a difference between two teams' internal practices is no reason to move it.

Developer experience practice

The framework in Abi Noda, Margaret-Anne Storey, Nicole Forsgren and Michaela Greiler, DevEx: What Actually Drives Productivity (2023) distils its authors' earlier research, one of whom, Nicole Forsgren, had led the DORA programme. It identifies three dimensions that drive productivity as engineers experience it (feedback loops, cognitive load and flow state) and argues that all three can be measured and improved. The paper proposes the framework and reports no new empirical study of its own. In practice this means investment in developer experience can be measured by the friction it removes, and the amount of tooling installed is the wrong measure.

Goodhart's law practice

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

AI-assisted developer productivity contested

There are two kinds of evidence, and so far they do not agree. In the controlled experiment reported in Sida Peng, Eirini Kalliamvakou, Peter Cihon and Mert Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot (2023), developers completed a defined task substantially faster with an AI coding assistant. In the randomised trial reported 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), experienced developers working in their own mature repositories were slower with AI tools than without them, while believing they were faster. The studies measured different things, one a well-specified task and the other real work in a complex codebase. The honest position for a manager has three parts: the effect depends heavily on the work, the codebase and the engineer; self-reports of speed-up are unreliable; and the effect has to be measured under the team's own conditions. Two things are not contested. The tools change what review has to establish, which is the subject of TJ-3 Code review and quality standards, and they bring risks that need governance, covered in TJ-5 AI-assisted engineering.

The operating cadence practice

This is a practice with no formal name, and at executive scope the unit treats it as the organisation's process: the rhythm of planning, review and escalation through which the organisation senses what is happening and responds. A sound cadence is light and rolling against stable priorities. It includes a review of the portfolio based on evidence, has explicit escalation paths with known triggers, and reserves time for correction. Its failure is planning theatre, where weeks of ceremony produce a plan that is stale within a month. The principle behind it is that at scale, responsiveness improves execution and more detailed central planning does not.

The ritual audit

Twice a year the team lists every recurring meeting and practice it runs, with the problem each one solves. Anything that has no current problem to solve is dropped for a month, and if nobody notices, it stays dropped. The exercise is cheap, and it usually shows that a third of the calendar was ceremony.

The flow review

When throughput drops, the manager looks at the flow before looking at the people. How many things are in progress? How many are blocked, and on what? How much of each engineer's week goes on interruptions? The result is a change to the flow, such as a work-in-progress limit, a fixed interruption rota, or a batch of blocked work cleared in one go. It is not a request for more effort.

Standards at the seams

A group of teams keeps a short written list of what is standard because work crosses boundaries (interface conventions, the floor for "done", the reporting vocabulary), together with an explicit statement that everything else belongs to each team. The list is reviewed when a boundary fails. Differences between one team's internals and another's do not trigger a review.

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 it removes and reported the same way.

Introducing AI assistance deliberately

When AI tooling arrives, the team decides three things in writing: what review must now establish for generated code, who owns a change whatever produced it, and how the effect will be measured in the team's own conditions. Adoption is not the measure, and neither is the number of licences in use. The measure is whether the team can now do something it could not do before, at a quality it can defend.

At team scope the object is the team's own process and tools, which the manager adopts, adapts and prunes directly. At organisational scope the object becomes the balance of consistency and autonomy across teams (what is standard because work crosses boundaries, and what is left inside them), along with 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 does the executing and does not execute personally. How Judgment Scales sets out the pattern, and SV-6 Organisational design and leading change covers the structure the flow runs through.

• Adopts a practice to solve a named problem and prunes it when it stops earning its cost. team
• Adapts frameworks to the team instead of following them dogmatically. team
• Reads a throughput drop as a flow problem (interruptions, fragmentation, too much in flight) and changes the flow instead of 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, and not by 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 instead of 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 instead of 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. With too little structure a growing team loses predictability, and with too much it loses the time the structure was supposed to protect. The judgment lies in scaling structure to the situation, and in being willing to take out what was added once the situation changes.

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

Investment versus delivery. Developer-experience work competes with features for the same people, and its return comes later and is harder to see. The judgment is in measuring the friction so that the return becomes visible, and in protecting the investment against the urgency of any one quarter.

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

Planning versus responsiveness. A detailed plan is reassuring and goes stale within a month. A rolling cadence is harder to communicate and stays true. At scale the evidence favours responsiveness, and the friction comes mostly from stakeholders who want the comfort of the detailed plan.

A head of engineering inherits an organisation where quarterly planning takes up three weeks of every quarter. Each team writes a detailed plan, the plans are reconciled over a series of long meetings, and the result is a document that leadership approves with some ceremony. Within a month it is stale, because priorities shift, dependencies slip and nobody has time to re-plan. Teams have learned to plan defensively. Stakeholders treat the document as a contract and engineers treat it as fiction. The chief executive likes the document and has asked for the next cycle to be more thorough.

The temptation is to comply and polish the ceremony with a better template, a planning tool or a longer horizon. That only makes the theatre more expensive. The diagnosis is that the cadence is upside down: a large central planning effort set against unstable priorities, with no time reserved for correction. At this scale, more detailed central planning does not improve execution, and responsiveness does.

The head of engineering replaces the cycle instead of refining it. At portfolio level, priorities are set in a short review with the executive team, based on evidence, and held stable for the quarter. Teams plan against those priorities in rolling six-week horizons, which takes a day where it used to take three weeks, and they re-plan when something material changes. A monthly review examines evidence (what was meant to be true by now, and whether it is) 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 limits each team runs whatever process it finds works.

The head of engineering meets the chief executive's concern head on and in the chief executive's own terms. What the chief executive wants is confidence that the organisation knows what it is doing. The head of engineering shows that the old document delivered the feeling of that confidence without the substance, and that the new cadence will give a true picture every month in place of a false one every quarter. They commit to reporting delivered outcomes against the stable priorities, and say plainly that the first quarter will look less tidy.

The head of engineering does not take on the coordination personally. With the old cycle gone, the temptation is to become the person who knows everything. The design has directors owning execution within the cadence, while the head of engineering runs the system and leaves the programmes to them.

• 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 over 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. Process is easy to add and hard to remove, so the bias is towards less.
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, and how much of each week goes on interruptions. The fix is a change to the flow, such as a work-in-progress limit, an interruption rota, or blocked work cleared in a batch. More effort is not the fix.
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, and a shared reporting language. That is where one team's variation becomes another team's incident. Inside a team, tools, ceremonies and style belong to the team, 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. Licences used, adoption rates and self-reported speed are the wrong measures, and the evidence shows self-reported speed 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 of experienced developers in their own repositories found a slowdown the developers did not perceive. The effect depends on the work, the codebase and the engineer, self-reports are unreliable, and the effect has to 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

   The plan is stale before it is finished, and the ceremony uses up 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 clear of blockers, 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 of feedback loops, cognitive load and 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.