When we moved to pipeline-first delivery, we removed engineers' standing access to production and built a break-glass process for emergencies. It provided secure, audited access when needed. We rolled it out, it worked, and I considered it done.
Then we reviewed how engineers were using it. The volume of requests prompted a closer look, and we found emergency access handling routine tasks. Someone would run a test that left data behind in production, then request break-glass to clean it up. No pipeline existed for that cleanup.
Nobody set out to misuse an emergency process. I hadn't anticipated that we were giving routine work a reliable emergency route while leaving it without a supported path of its own. Each approval confirmed that this was how the work got done.
We could have responded with a reminder that break-glass is for emergencies. Instead, we looked at those routine tasks and built pipeline paths so they no longer required emergency access.
Break-glass worked as designed, but the workflow around it was incomplete. The control didn't have to fail for the system to reinforce the wrong behavior.
Your platform teaches engineers what normal work looks like, whether or not that is the lesson you intended.
Deming was asking management to do its job
A post by Dan Koe on personal discipline brought me back to a management question: what does the environment make easy to repeat?
An executive announcement can create urgency, and a migration deadline can concentrate attention. Neither fixes the broken template someone encounters on an ordinary workday. Deming's work puts responsibility for improving those conditions on management.
“A bad system will beat a good person every time.”
W. Edwards Deming, as documented by the Deming Institute
His 14 Points for Management make that responsibility concrete. He opposed slogans demanding higher quality when the causes of poor performance sit outside workers' control. He called for training, leadership, continual improvement, driving out fear, and quality built into the work rather than dependence on inspection.
People still make mistakes, and accountability still applies. But when capable people repeatedly struggle with the same task, investigate the conditions of the work before prescribing more determination.
It's tempting to translate the quotation as “a bad platform will beat a good engineer,” but that makes the system too small. Staffing, ownership, deadlines, review practices, incentives, and management decisions are part of it too. A better pipeline can't compensate indefinitely for an organization that rewards bypassing it.
I read Deming as asking management to stop making good people compensate for problems management owns.
The lesson is in the interaction
Platforms are one way organizations remember. We take what we've learned and make it reusable, so the next team doesn't have to rediscover the same problem.
They also preserve practices nobody deliberately chose. Defaults make decisions on an engineer's behalf, while failures and exceptions show them what matters, where help is required, and whether a rule is firm, negotiable, or outdated.
In a platform review, I'd look at interactions like these:
| Platform interaction | Lesson it can reinforce | A more useful design |
|---|---|---|
| Routine tasks lack pipeline paths, but emergency access is available. | Routine work gets handled like an emergency. | Give operational tasks a pipeline path of their own. |
| The approved starter fails; a copied repository works. | Use whatever succeeded last time. | Test and maintain the starter against the current delivery path. |
| A policy check rejects work without explaining the correction. | Progress requires knowing whom to ask. | Explain the failed requirement, the reason, and the supported next step. |
| Routine work waits indefinitely; escalations receive immediate attention. | Everything needs to become urgent. | Give routine requests clear ownership, status, and predictable handling. |
| Teams repeatedly need the same exception. | The standard is something to negotiate around. | Investigate whether the standard or the supported capability needs to change. |
The first row reflects our experience. The others are illustrative.
In my Claude Code setup, I stopped repeatedly asking for checks and added a hook that runs a fast type check. I also put standards and project lessons into files the workflow could use. Documented guidance, an automated check, and an agent's review do different jobs; none substitutes for the others. Together, they make expectations more explicit than “please be careful.”
These interactions are part of how culture forms. Engineers learn from colleagues and managers too, but the platform affects what they have to overcome to do good work.
Agents need the context behind the pattern
Platforms need to serve developers and their agents with authoritative context and usable capabilities. That includes explaining which patterns are approved and which are exceptions.
Take the copied repository from the table. An experienced engineer might remember why it contains an exception that shouldn't carry into a new service. A new colleague may have no more of that context than an agent does. To either, a working example can look like evidence of the intended pattern.
An agent can repeat that pattern across subsequent tasks without knowing why the exception existed. Given equivalent tools and permissions, it could also have made the same choice our engineers did with break-glass. The risk is repeating a decision without the context that justified it.
Here, “teaching” means influencing behavior within a workflow. Reading a repository leaves the underlying model unchanged. Instructions, examples, tool responses, and saved memory provide context. Claude Code's documentation describes project instructions and memory as “context, not enforced configuration.”
That leaves three distinct responsibilities: explain the intended approach, provide a supported way to execute it, and independently enforce the boundaries that must hold. An instruction file can't substitute for an access control or a release gate.
Good context doesn't guarantee good decisions. Agents can still misunderstand instructions and produce incorrect work, so test the results rather than assuming clearer documentation solved the problem.
Make judgment durable, but keep it revisable
Intent and judgment need to survive beyond the person who supplied them. Specifications, standards, and operating mechanisms make that possible. Preserving a decision only helps if we also preserve a way to discover it's wrong.
Suppose several teams keep asking how to configure a service's recovery settings. A better template might prevent that confusion. Before making it universal, we should understand which workloads it fits, what tradeoffs it introduces, and what evidence would show it helped.
Deming's Plan-Do-Study-Act cycle, developed from Shewhart's work, offers a way to approach this: state an expectation, try a change, study the result, and let the result inform what comes next.
This is my application of continual improvement to platform engineering; Deming's own model is PDSA. People review and test outcomes before a change becomes a standard.
In our break-glass example, the change was a pipeline path for routine tasks. Judge its success by whether that work uses the supported path rather than by whether we finished building it.
Resist turning every incident into another gate. Sometimes the answer is clearer documentation, training, more capacity, or removing a rule whose cost exceeds its value. A gate checks whether work meets a defined standard; the improvement process checks whether that standard is still useful.
A useful default has an owner, a reason to exist, and a way to change. Without those, yesterday's judgment becomes durable and tomorrow's correction becomes expensive.
Good defaults shouldn't make reasoning optional
Following a supported path and understanding it are different things. A template can produce an acceptable configuration without explaining when it stops fitting. A green check establishes that a specific test passed, not that the system meets the customer's need.
The recovery template should explain which failure it addresses and when a workload needs a different approach. Otherwise, we've made the configuration reusable without making the reasoning available.
Coherent defaults need escape hatches. Support the common case well, make legitimate deviations explicit, and keep mandatory controls separate from preferred choices. An escape hatch needs review and safeguards of its own; it must not silently remove protections the organization depends on.
The platform should make repetitive decisions less demanding, so engineers have more attention for decisions that require judgment. A platform that trains them to stop asking questions has failed at that job.
Start with what the next engineer will encounter
Choose one common workflow: creating a service, requesting a database, or getting a change through review and into production.
Watch an engineer who didn't build the platform attempt it. Make clear that you're evaluating the workflow, not the engineer. Then run the same task with an agent in a controlled environment with representative permissions.
Observe where each looks for guidance, which examples they choose, what happens when something fails, and whether the next step is clear. Notice where progress depends on context that exists only in the platform team's heads.
Pick one recurring problem, state what you expect a change to improve, and measure that outcome alongside the risks. Fewer support tickets can mean people stopped asking. Faster deployments that produce more failures are a regression.
Your platform communicates what normal work looks like through defaults, errors, and approved exceptions. Leaders need to examine what those interactions encourage.
Before asking your engineers to work differently, examine what the system is teaching them to do. Then change the system, and check whether the lesson changed.
