Most people have seen this before.
A transformation programme begins. Workshops are booked. People cover walls in sticky notes and map how the organisation should operate.
Someone turns all of that work into process documents, governance models and carefully designed diagrams. The files are published. Leadership announces the new way of working.
Then everyone gets busy.
The documents are too long to remember. The process does not quite fit the real situation. A senior leader needs something urgently and goes around it. The team follows the exception because that is where the authority sits.
The workaround becomes the real process. The official process becomes something people show auditors, new starters and consultants.
So when I talk about a spec-driven organisation, one of the first reactions is understandable:
Is this not just another attempt to document and control everything?
Is it bureaucracy with AI?
The honest answer is that it will be if we repeat the same mistakes.
People are right to be sceptical
Traditional process work often created more administrative effort without meaningfully changing how work happened.
The process could not apply itself.
For it to matter, a person had to:
- know it existed;
- find the current version;
- read it;
- understand what it meant for this situation;
- remember it while doing the work; and
- choose to follow it when pressure made the shortcut more attractive.
If the process turned out to be wrong, changing it required another meeting, another approval and another round of communication.
Going around it was usually faster.
That created the worst combination: a formal process that slowed down the people who followed it and an informal process that remained invisible to everyone else.
Calling that experience bureaucracy is fair.
The old process document sat beside the work
The central weakness was not that the organisation had rules.
It was that the official rules and the actual work lived in different places.
The document described what should happen. People still had to interpret and execute it. When reality changed, the work moved immediately and the document remained behind.
Eventually nobody trusted it enough to use it.
A living specification is meant to close that gap.
It is loaded before the work begins. People, agents and systems use it while carrying out the work. If the work reaches something the organisation has not decided, that decision is surfaced rather than guessed. If completed work changes what is true, the specification is updated as part of finishing the job.
The specification participates in the work instead of sitting beside it.
That is the difference that matters.
AI changes the economics of process
Before AI, every additional rule depended on another person understanding and applying it.
More process often meant more human effort.
Now an agent can begin with the current goals, rules and boundaries already loaded. It can check the result, collect the evidence and route an exception to the right person without expecting someone to remember every requirement.
This means sufficient clarity can reduce manual coordination rather than add to it.
A well-designed guardrail can remove hundreds of future approval requests because everyone knows what is safe to do without asking.
Guardrails are not the opposite of autonomy. They are what allow autonomy to scale.
The purpose of the specification is not to make every action require permission. It is to make clear where permission is no longer required.
Bureaucracy and discipline are not the same thing
Some organisations respond to the failures of rigid process by celebrating responsiveness.
Leaders make quick calls. Teams adapt. Exceptions are approved. The business prides itself on moving fast.
But there is a hidden difference between responsiveness and volatility.
Once people and agents rely on a decision, changing it has consequences. Systems need updating. Teams need informing. Connected work may need to be reconsidered. Customers may already have been promised something under the previous rule.
The leader experiences a captain’s call as one quick decision.
Everyone downstream pays the change tax.
A captain’s call feels fast to the captain. Everyone downstream pays for the change.
The opposite of bureaucracy is not constant improvisation.
People need enough consistency to act without checking whether today’s answer will be different from yesterday’s. Agents need the same thing at much greater scale.
Discipline is what makes the organisation dependable enough for other people to use their judgement.
A good specification removes approvals
One practical test is whether the specification creates more requests for permission or fewer.
A bad specification says:
- follow these 27 steps;
- complete these forms;
- seek approval at these five points; and
- escalate anything unusual.
A good specification says:
- this is the outcome we need;
- these boundaries must hold;
- you can make these trade-offs;
- these decisions are yours;
- these questions remain open; and
- involve this person only when you reach one of these boundaries.
The first version controls activity.
The second creates room to act.
A good specification should remove repeated approvals, not add them.
Long documents do not create more clarity
AI makes it very easy to create impressive-looking documentation.
Ask for a process and it will generate pages of roles, controls, steps, edge cases, risks, matrices and recommendations. The weight of the report feels like value.
But an organisation does not become clearer because it has more words.
If people cannot understand the specification as a whole, they cannot challenge it, recognise contradictions or remain meaningfully responsible for what it says.
The document may be machine-readable while the business becomes incomprehensible to its own people.
A long specification can also hide disagreement. Everyone’s preference is included, nobody has to choose and the underlying conflict remains unresolved beneath a polished layer of prose.
AI has made documentation cheap. It has not made clarity cheap.
The document gets shorter as the organisation’s understanding gets better.
Specify the few things that matter
A living specification should hold the durable truth about one part of the business.
That might include:
- why it exists;
- the outcome it is responsible for;
- the goals and anti-goals;
- the important language;
- the rules that must not bend;
- the places where judgement is allowed;
- the decisions that remain open; and
- the person who owns the result.
It should not become the dumping ground for every related fact.
Current delivery status belongs with the work. Technical instructions belong with the technology. Customer records belong in customer systems. Temporary plans can disappear when the job is complete.
The specification remains useful because it does not attempt to become the whole business.
A lean specification is not missing information. It is confident about which information belongs somewhere else.
Do not prescribe the route when the outcome is what matters
Another source of bureaucracy is describing every piece of work as a fixed sequence.
Traditional automation required this. A system could not understand what you were trying to achieve, so you had to tell it exactly what to do next.
Agentic work gives us another option.
We can define:
- what must be true before the work starts;
- the goal;
- what must be true when it is finished;
- the quality checks at the handoff; and
- the boundaries that cannot be crossed.
Then a capable person or agent can find the best path for the situation.
Exact sequences still belong where order itself is part of correctness: some safety controls, legal requirements and inflexible system interactions.
But they should be the exception.
Guarantee the handoff, not every movement that happens before it.
That is how a specification protects quality without turning judgement into compliance theatre.
Fast experiments, deliberate specifications
A living specification should be able to change. That does not mean it should change with every new data point or management preference.
There are three different things happening:
- Signals are being observed. Agents collect results and surface patterns.
- Experiments are being tested. The organisation tries a variation to see what happens.
- The specification is being changed. An accountable person decides that the organisation has learned something durable.
These should not happen at the same speed.
Experiment quickly. Change what the organisation treats as true deliberately.
An agent may be able to follow a specification that changes a thousand times a day. The people responsible for the outcomes cannot.
If nobody understands why the process keeps changing, the organisation has not become adaptive. It has become unstable.
Start small and whole
The other path to bureaucracy is attempting to specify the entire organisation before anything useful can happen.
Do not do that.
Choose one product, service or repeated piece of work. Find the smallest valuable part that can run properly from beginning to end.
Before it goes live, make sure:
- the people doing the work and receiving the result agree on what is being introduced;
- its purpose and outcome are clear;
- its boundaries and handovers are understood;
- decided and undecided questions are visibly separated; and
- someone owns the result.
Then use it in real work and improve it from what happens.
The first specification does not need every answer. It needs to be true about the part you are asking people and agents to depend on.
Start small and whole, not broad and rough.
Seven tests for living specification or bureaucracy
Before adding another process document, ask:
- Does this guide real work? Or will it sit in a folder waiting for someone to remember it?
- Does it have an owner? Who can explain what it means and is accountable for the outcome?
- Are open decisions visible? Or has uncertainty been buried in vague language?
- Can the affected people understand the whole thing? Or is it technically complete but humanly unusable?
- Does it reduce repeated questions and approvals? Or add new gates?
- Will completed work keep it true? Or is maintenance someone else’s future problem?
- Can it change deliberately? Is there a clear difference between an observation, an experiment and a new organisational rule?
If the answer to those questions is no, the sceptics are probably right.
You are building bureaucracy.
Bottom line
A spec-driven organisation becomes bureaucratic when specifications are long, static, disconnected from the work and used to control every action. A living specification should do the opposite: make the important decisions clear, create room for people and agents to act, surface real uncertainty and improve from what the organisation learns.
The goal is not more process.
It is less repeated explanation, less avoidable coordination and fewer decisions travelling back to the same people.
Done badly, specification adds another layer of administration.
Done well, it is the layer that allows the administration to disappear.
BusyWork Dispatch helps organisations begin with one product, service or repeated piece of work, not a whole-company documentation programme. The Workbook holds durable context; Dispatch connects it to work that gets built and shipped. See how BusyWork works or book a call with Ben.
