Minimum Viable Bureaucracy

A field guide: an adaptable operating handbook for a technology organisation in a volatile, uncertain, complex, and ambiguous world.

Simplicity is seductive, but reality is rarely that kind. Past success can blind you to future failure, and treating Complexity as if it’s Simple doesn’t make it disappear. It just makes the collapse more sudden when Chaos finally breaks in.

How to Use This Handbook

This is one concrete way to run a product organisation built around adaptiveness, written in the form of a shared current state rather than a proposal. Everyone in and around product R&D is its audience.

This handbook is the operational companion to Come Prepared to Die: An Engineering Leader’s Field Guide to the Leadership Paradigms AI Is Exposing. Come Prepared to Die argues that an organisation must rebuild itself around adaptiveness before a leaner, more nimble competitor does it first. This handbook is one concrete way to do that, and it has worked well for me in my last three engagements. Two caveats: a) this was written for a context that is possibly similar but not identical to your context and b) implementing this org design without shifting your own leadership paradigms will be hard.

The handbook is written in the voice of an organisation that has already adopted it: “we,” “our,” a shared current state rather than a proposal. Everyone in and around the product R&D organisation is its audience. If you build, manage, or depend on the products, the rules that govern your daily work are short, and “What This Asks of You” below points you straight to them. If you are deciding whether to adopt this design, read the Executive Summary, then go straight to “Adopting This Handbook” at the end.

This is a minimum viable bureaucracy: the smallest set of deliberate organisational design choices that let our teams deliver effectively. It is deliberately not a maturity model to ascend or a framework to install. It is a starting point that expects to be changed, with the change mechanisms (retrospectives at every level) built in.

Throughout, I name Shortcut as our work-management tool because a handbook that says “your tracking tool of choice” forces every reader to translate every rule. The ideas and discipline translate readily to Jira, Linear, Azure DevOps, or other tools; the screenshots will not. Worked demonstrations of the reports this handbook references are available upon request, most organisations will need to build their own as I am aware of no public tooling that provides them. Let me know if you’d like help.

Executive Summary

This handbook describes our minimum viable organisational design: the smallest set of deliberate choices across Strategy, Structure, Processes, Rewards, and People that enables our teams to deliver effectively. We design the organisational system; the system shapes behaviour; behaviour becomes culture and performance.

• Mandate: Continuously improve a deliberate organisation design that tames Complexity, fuels collaboration across sites and time zones, and enables rapid innovation.
• Key principles: Embrace Complexity science, favour adaptiveness over short-term “efficiency,” build psychological safety for learning, design Structure to influence Culture, and strip out overhead that brings no value to end users.
• Intended audience: Everyone in our product-technology organisation, plus the stakeholders who want to understand how we function.
• What to do next: Skim the headings, read the italicised passages, then dive into the bullet points and appendices as your role demands.
• Decision requested: Ratify this handbook as our operating baseline. The CTO and CEO jointly own adoption; the first step is the 60-day demand-gate installation described in “Adopting This Handbook”; success is visible in three numbers within a quarter: Planned % at 80 or better, team queues under 8 weeks, WIP per Builder under 1.0.

How to Read This

There is a fractal way to read this handbook. It is designed to help you grasp the core ideas efficiently.

• Skim the table of contents for a quick overview.
• Read only the italicised text in each section for a rapid understanding of key concepts.
• When you want more detail, explore the indented bullet points and normally formatted paragraphs as needed.

Links, footnotes, and appendices offer deeper exploration. They are not mandatory, but they carry the “why” behind the design, and the why is what makes the rules adaptable rather than brittle.

A note on capitalised terms: certain common nouns (Stories, Epics, Structure, Processes) are capitalised intentionally throughout. They have precise meanings here; Appendix D defines them.

Builder Quick Start

A new Builder needs three things on day one, and none of them should require reading 90 pages to find. Here is the map:

• What do I do at my daily huddle? See “Daily Huddle” in Part 3. Walk the board starting with the work closest to done, state your intent when you pick up work, and spend two minutes on the Quality Report.
• What makes a good Story, and when is it done? See “Stories,” “Definition of Ready,” and “Definition of Done” in Part 3.
• Who do I ask when I’m stuck? Ask the Builder next to you first. Then see “Who to Ask” at the end of Part 3.

Everything else in this handbook explains why those answers are what they are. Read the rest when you’re ready; the huddle, the Story, and the ask will carry you through your first weeks.

What This Asks of You

Six roles, three rules each. If you read nothing else, read your row.

Every rule in this table is explained, with its why, in the parts that follow.

The Five Organisational Design Levers

This handbook is organised around five interdependent design choices that shape behaviour. Those behaviours, repeated over time, become our performance and culture. Most performance problems (Deming put it at 85 to 95%) have systemic causes, owned by leadership, rather than individual ones.

The five design levers, in the order presented in this handbook, are:

• Strategy (Part 1): Why we designed it this way: vision, optimising goal, design principles
• Structure (Part 2): How we’re organised: Value Streams, Capabilities, Teams, Roles
• Processes (Part 3): How we work day-to-day: Events, Backlogs, Stories, Quality
• Rewards (Part 4): What we measure, celebrate, and incentivise
• People (Part 5): How we develop, lead, and support our people

Almost every Agile transformation of the past twenty-five years has failed relative to what its framers intended when they wrote the Agile Manifesto. I say that from twenty-plus years in this work and a decade of comparing notes with other coaches. I have led transformations I am proud of, and others I called meaningful change at the time and now read more soberly; none has fully met my aspirations. The pattern behind the shortfall is consistent: they touch only Processes and leave Strategy, Structure, Rewards, and People as they were. When the five levers are not aligned, they work at cross-purposes and the change stalls. That is why we address all five at once, and why leadership engagement matters (see Part 1).

We lead with Strategy because every rule in Parts 2 through 5 traces back to it. A rule whose rationale you can appreciate is a rule you can adapt rather than blindly cargo-cult. Builders who want the daily mechanics first should jump straight to Part 3 and circle back.

Change the org design, change the behaviours; change the behaviours, change the results.

Read the field guide

Six parts. Start anywhere, but if the organisation is new to this, read Strategy first, then jump to Process, where most of the day-to-day rules live.

Adopting This Handbook

Fork this handbook, ratify it in public, and install the demand gates first: in most adopting organisations, the binding constraint is that nothing says no to incoming demand. Expect partial adoption to be the failure mode, and expect to need help from someone who has done this before.

The five parts you have just read are one organisation’s answer, generalised. They are not the only answer, and several of the specific thresholds (WIP bands, backlog limits, DoD items) encode a context that is not yours. That is why the ratification step matters more than any individual rule.

Fork this. Replace the placeholder department and product names with your own. Strike the sections that do not fit your context, argue about the ones that almost fit, and then adopt what survives as your organisation’s shared current state. An operating model that people rent never survives contact with the first hard quarter; the Org Topologies authors put it plainly: people have to own, not rent, their change (Krivitsky, Larman & Flemm, Org Topologies Primer, 2025). Ratification is how renting becomes owning.

Where to start: the constraint. In most organisations that reach for this handbook, the binding constraint is that demand enters the system ungated. Nothing says no, so everything is started, and queues do the damage Part 3 describes. The first 60 days should therefore install the demand gates: the two delivery lanes, the priority hierarchy, the displacement rule, and team WIP limits, with instrumentation that makes queues and WIP visible. The CTO and CEO jointly own this step, and it cannot succeed without the CEO: WIP limits hold only until the first executive escalation, and if the CEO will not respect the gate, no one below them will either. Success is measurable within a quarter: Planned % at 80 or better, team queues under 8 weeks (each backlog level carries its own limit; see Backlog Health in Part 3), WIP per Builder under 1.0.

A note on instrumentation: the Delivery Intelligence and Quality Reports referenced throughout are the author’s tooling, built against Shortcut. Adopting organisations get them by working with the author, which in the short term also means using Shortcut; on a different work-management tool you will need equivalent instrumentation (queue length, Planned %, WIP, backflow, cycle time) built before the gates have eyes. Gates without instrumentation are promises without measurement, and they erode the same way. The queue-length gate in particular is arithmetic, not aspiration: Backlog divided by Plannable Velocity (Planned work only), with the velocity’s variability taken into account at the 85th percentile. Most organisations cannot produce that number on day one, and closing the measurement gap is the real first step. It is also why almost every organisation that makes this work gets help from someone who has done it before: the failure patterns (gates that erode, metrics that get gamed, retrospectives that go through the motions) are far easier to catch when someone on the team has watched them happen elsewhere.

A suggested adoption sequence:

1. Leadership first. The executive team reads Part 1 and decides whether they genuinely hold the Optimising Goal. If adaptiveness is not what you will optimise for, stop; the rest of the handbook optimises for it. The CEO’s buy-in to WIP limits is the specific test: if that is not on offer, the rest is theatre.
2. Fork and rename. Substitute your departments, roles, tools, and channels. Delete what does not apply. Rewrite the vision.
3. Ratify in public. Present the forked handbook to everyone bound by it, take challenges seriously, amend, and then adopt it as the shared current state with a named steward.
4. Run the change mechanisms. The Team, Value Stream, and Department Retrospectives are the handbook’s immune system. From the first fortnight, they are where the handbook gets improved, and every change ships to everyone at once.
5. Expect drift, and read it as data. Routine workarounds signal process misfit, not bad actors. When practice and handbook diverge, one of them is wrong, and it is frequently the handbook.

The failure mode to expect is partial adoption. Many leaders take their existing strategy, rewards, structure, and people as fixed and attempt to implement just the process. Most learn rather quickly that the new process doesn’t work unless you change the rest of the organisation. Unable or unwilling to do so (that’s hard work that requires serious C-level involvement) they instead revert the process back to the old ways of working while retaining the new terminology (“water-Scrum-fall” or “hybrid Agile” anyone?) and declare “mission accomplished.” (Credit to Craig Larman for this framing.) I hope your team will be able to transcend this increasingly deadly trap and I am happy to help, reach out at https://hi.chrisgagne.com.

This handbook is also the next adjacent possible for many organisations rather than the full expression of its own ideas. Taken to their conclusion, these principles look more like LeSS (Large-Scale Scrum): one Product Backlog, feature teams, and far less coordination machinery than even this handbook carries. If your organisation is ready to make that jump today, make it; Larman and Vodde’s Large-Scale Scrum: More with LeSS is an excellent start. Most organisations cannot ratify that step from a standing start, and a decent intermediate that leadership genuinely adopts beats an ideal that dies before it ever lived. Treat this handbook as a waypoint on the Delivery-to-Adaptive path (see Appendix A), with the retrospectives at every level as the mechanism that keeps you moving toward the fuller expression.

May the bureaucracy you keep be the bureaucracy that earns its keep.