Why Standardised Processes Fail Creative Technical Teams

Standardisation helps until it starts treating skilled people as interchangeable operators.

Creative technical teams need shared tools, repeatable practices and clear constraints. They also need people who can recognise when the model no longer fits reality. An enterprise mandate fails at the front line when following the prescribed process becomes more important than solving the actual problem.

Here, “creative technical work” means more than making art or building things. It includes novel problem-solving under uncertainty, critical thinking about unfamiliar systems, diagnosing why something failed, designing a solution that nobody has tried before, and any work where the right answer depends on judgement rather than a lookup table. Curiosity, healthy scepticism and the ability to hold several conflicting constraints in mind are as important as domain skill.

I originally described this as ‘Victorian production’. The industrial-revolution metaphor was deliberately provocative. In game development, I could see a similar risk in the way engines, pipelines, methodologies and specialist job descriptions were being used. The broader claims below are patterns I observed in game studios and later technical work, not a claim that every standard has the same effect.

The tool was never the problem

Game engines made ambitious development possible. Middleware removed work that did not need to be reinvented. Production methods helped teams coordinate projects too large to run through informal conversation.

The problem began when a useful tool became an organisational theory.

Buying an engine did not remove the need to understand rendering, performance, tools or game design. Writing down a production process did not make every project predictable. Dividing work into specialist roles did not mean one person could be exchanged for another without losing context, judgement or relationships.

Yet that was sometimes the assumption behind the plan: choose the machinery, document the procedure, train people to operate their part and manage by checking whether every stage had been followed.

That model looked efficient from above. At the front line, it often created a different reality.

Compliance can hide the absence of progress

A prescribed process produces visible evidence. Tickets move. Documents are completed. Meetings occur. Status reports turn green.

None of those things proves that the game is becoming better, the software is becoming safer or the team has resolved its most important uncertainty.

When the mandated process fits the work, those artefacts help. When it does not, people learn to satisfy the process alongside the real work. The organisation then sees compliance while the team privately handles exceptions, repairs gaps and negotiates around rules that were meant to simplify delivery.

The reporting becomes cleaner as the work becomes less visible.

This is closely related to the mistake of using fixed attendance as evidence of contribution. Both substitute something easy to observe for the harder managerial task of understanding whether useful progress is being made.

Frontline judgement is not process failure

Enterprise mandates often assume that variation is waste. Sometimes it is. Repeated release errors, incompatible formats and undocumented decisions deserve a common response.

But variation can also be information.

A team may depart from the standard because its platform, customer, risk, maturity or dependency is different. A developer may challenge a rule because the rule encodes an assumption that is no longer true. A producer may change the sequence because the current uncertainty needs to be resolved before the official milestone plan makes sense.

Treating every exception as resistance trains people to hide exceptions. Treating every exception as wisdom produces chaos. The management job is to distinguish the two.

That requires conversation with the people doing the work, not another layer of process intended to eliminate the need for conversation.

Standardisation becomes brittle in five ways

From game studios through later software and enterprise work, I have repeatedly seen five failure modes. The method becomes the objective, so teams optimise for passing governance rather than improving the product or reducing risk. Context disappears upwards when reports compress uncertainty into comparable categories. People appear interchangeable when plans count roles and capacity but ignore domain knowledge and trust. Problems move out of sight when the approved route cannot respond quickly enough. Change then exposes the weakness because the system performs only while conditions remain familiar.

The last failure is the most revealing. A robust process helps people respond to change. A brittle process works only while reality behaves as predicted.

The same mistake repeats with each new technology

Rory Sutherland, vice-chairman of Ogilvy UK, used factory electrification to illustrate this pattern in a 2026 talk reported by The Drum. The history is more complex than the analogy, but the shift from central shafts and belts to motors driving individual machines is documented in Paul David and Gavin Wright’s historical account.

The useful comparison is not that AI will recreate the assembly line. It is that a new capability can deliver limited benefit when it is inserted into an old arrangement. Teams using AI to do existing work more cheaply may be making a sensible local improvement. The larger opportunity appears only when they test whether feedback loops, team structures or services should change as well.

The pattern is the same one this post describes. A new capability arrives. It is plugged into the existing structure. The structure does not change. In some cases, the gains may disappoint. The more useful question is then what the structure would look like if designed from scratch around the new capability.

The original language blamed the wrong people

The 2015 version referred dismissively to ‘drone artists’, interchangeable workers and managers who merely followed methodologies. That language reflected frustration, but it aimed too much of it at the people inside the system.

Most people working within an imposed process are not the authors of it. They are responding to incentives, job boundaries and reporting demands. A specialist using an established pipeline is not uncreative. A manager applying a standard is not automatically thoughtless.

The useful question is not whether an individual looks like a cog. It is whether the organisation gives them permission and a credible route to say that the machine is producing the wrong thing.

Use standards as infrastructure, not instructions for thinking

A good standard removes avoidable decisions. It might define how code is reviewed, how risks are recorded, how accessibility is checked or how a release can be rolled back.

It should not pretend to decide the parts of the work that depend on local evidence and professional judgement.

Before imposing a common process, ask:

• What specific failure is this standard preventing?
• Which constraints genuinely must be shared?
• Where is local variation safe or necessary?
• How can the front line challenge an assumption without being labelled non-compliant?
• What outcome will show that the process works?
• When will the process itself be reviewed?

There is no silver-bullet delivery process. The right amount of standardisation changes with the work.

Do not industrialise the judgement out of the team

Creative technical work can and should become more reliable. Reliability does not require pretending that every important decision can be designed in advance and issued from above.

Use engines. Use templates. Use governance. Reuse what is genuinely repeatable. But keep the feedback route from the people encountering reality to the people setting the rules.

If a process cannot learn from the front line, it is not an operating system for the organisation. It is a historical assumption with a compliance mechanism attached.