The Bending Rules

A few weeks ago I was staring at the aftermath of a production outage, trying to figure out what went wrong, and I realized the answer was: nothing dramatic. No catastrophic bug. No malicious actor. Just an engineer who ran an infrastructure change directly against a shared environment, from a local branch, outside the deployment pipeline, without a review. Four shortcuts, taken simultaneously, by one person, in one afternoon.

Each shortcut, on its own, was ordinary. Running something locally instead of through the pipeline — we allow it to be flexible. Working from a feature branch against a shared environment — not standard, but we allow it to be flexible. Skipping a review on what felt like a straightforward refactoring — easy to justify in the moment and we allow it to be flexible. Using a technique the tooling didn't handle the way you expected — an honest knowledge gap. None of these decisions, taken alone, would have caused a problem. Together, they cascaded in a way that nobody could have predicted from looking at any single one. Some resources got destroyed before their replacements could be created. The application went down. Recovery took the rest of the evening — right before a go-live.

I keep coming back to the same question: which of those shortcuts should have been impossible?

Everyone Bends Differently

Here's what I've noticed across every team I've worked with. When deadline pressure builds, people cut corners. That's not controversial, everybody knows it. What's less obvious is that everyone cuts different corners. One engineer skips writing tests. Another hardcodes configuration values with a mental note to fix them later. Someone else merges without review because the change "looks simple." Another ships without updating documentation. Everyone has their own hierarchy of what's negotiable under pressure, and those hierarchies almost never align.

This means that under enough pressure, the ways your team degrades are essentially random. The shortcuts compound across people, across days, across systems — and since everyone's threshold is different, nobody has visibility into the full picture. Each person thinks they're making one reasonable trade-off. The organization is making dozens of them simultaneously, in different directions, with nobody keeping score.

I don't think people make these choices carelessly. Most of the time, the trade-off feels rational in the moment. The deploy is urgent. The refactoring seems safe. The review would slow things down by a day and the stakeholder is waiting. The individual cost-benefit analysis isn't wrong — it's just incomplete, because it can't account for what everyone else is quietly deciding to skip at the same time.

A Name for the Pattern

Diane Vaughan studied this dynamic — not in software, but in one of the most analyzed organizational failures in history. Before the Challenger shuttle disaster in 1986, engineers at Morton Thiokol warned that the O-ring seals were unsafe in cold temperatures. NASA managers, under intense schedule pressure, overruled those concerns and launched anyway. What Vaughan found, though, was that the launch decision wasn't a single moment of recklessness. It was the end point of years of smaller decisions, each one slightly expanding what was considered acceptable. She called this normalization of deviance: the gradual process through which practices that violate standards become accepted as normal, because they've been repeated enough times without visible consequence.

The mechanism is quiet. A team bypasses a safety procedure once, under pressure, and nothing bad happens. So they do it again. Over time, the deviation stops feeling like a deviation. It becomes "how we do things." Cost, schedule, and safety compromises were normal for managers and engineers alike — not because anyone made a conscious decision to lower standards, but because the repeated absence of consequences made the lower standard feel like the real one.

What strikes me about Vaughan's work is that she identified three forces working together: production pressure (the schedule had to be met), structural secrecy (the people with the safety data couldn't get it to the people making the launch decision), and a culture where the contradictory pressures of quality and speed were resolved, implicitly, in favor of speed. Every time. Not by policy — by practice.

I see the same three forces in software organizations, including my own. The deadline is real. The person who understands the risk isn't always in the room when the shortcut gets taken and the unwritten survival rule — the one nobody says out loud — is that shipping on time is what gets rewarded. Standards around security, resilience and maintanability are what get talked about during retrospectives.

Define the Bending Rules

I don't think the answer is "never bend." That's not realistic, and I don't trust anyone who claims their team never takes shortcuts under pressure. The answer, I think, is to make the bending explicit.

Every organization has things that should never be on the table, regardless of deadline pressure. Skipping security review. Deploying to production outside the pipeline. Merging infrastructure changes without a second pair of eyes. These are hard rules — not because they're convenient, but because the blast radius of getting them wrong is too high to leave to individual judgment in the moment.

But here's the thing about hard rules: if they exist only as agreements, they're still vulnerable to the same pressures that erode everything else. An agreement not to deploy outside the pipeline is only as strong as the moment someone is tired, stressed, and convinced their change is safe. If a corner can never be cut, it shouldn't be possible to cut it. The things that are never on the table need to be encoded in the pipeline itself — in the policies, the checks, the gates that run before anything reaches production. You cannot enforce a behavior without an enforcer, and your CI/CD pipeline is the enforcer that doesn't get tired, doesn't feel schedule pressure, and doesn't make exceptions at 6 PM on a Friday.

Every organization has things that can flex, under stated conditions. Reduced test coverage on a feature, as long as there's a follow-up ticket with a deadline. Simplified error handling with a documented TODO and an owner. A shorter review cycle where one reviewer focuses on architecture rather than line-by-line coverage. These are soft rules — the team agrees on what can bend, how far, and what the payback plan looks like.

The distinction matters because without it, everything is implicitly negotiable. When everything is negotiable, people negotiate with themselves, under pressure, alone which is how you end up with four simultaneous shortcuts stacking into a production outage.

I also think these rules need to be written by the team, not handed down by management. Not because management's instincts are wrong, but because rules that the team collectively defines carry social weight that top-down mandates don't. If my team decided together that manual production deploys are off the table, there's peer accountability behind that. If I decree it from above, it's a policy to be worked around when nobody's looking.

Implicit Rules Are Still Rules

Here's what I keep learning the hard way: if you don't define the bending rules, people will infer them. They'll look at what leadership tolerates, what gets flagged in retros and what gets quietly ignored, which shortcuts trigger a conversation and which ones don't. Those inferences become the real rules — the implicit ones. Implicit rules are still rules. They're just bad ones, because nobody agreed to them, nobody can see them, and nobody is accountable for their consequences.

When a deviation goes unaddressed — when someone bypasses the pipeline and nobody says anything — it doesn't register as a non-event. It registers as permission. The team updates its mental model of what's acceptable. Not consciously, not maliciously, but reliably. The implicit rules become the culture, whether you intended them or not.

I wrote in The Flood about what happens when the substance of review drains out while the rituals persist. This is a related failure mode, one layer deeper. The Flood was about what happens when we can't keep up with the volume of what needs to be reviewed. This is about what happens when we haven't even agreed on what must be reviewed — when the boundaries of acceptable risk are left to individual interpretation under conditions that make good interpretation nearly impossible.

I don't have a clean ending for this. The outage got resolved. The application came back up. We had a good retro. I'm reasonably confident we'll prevent that specific failure from recurring. What I'm less confident about is whether we've had the broader conversation — the one about which rules are rules and which are guidelines, the one about what's never on the table. I think that conversation is harder than fixing the incident, because it requires admitting that the problem wasn't one person's judgment. It was the absence of a shared agreement about where judgment ends and hard constraints begin.

I suspect most engineering organizations are in the same position. Not failing catastrophically — just bending in enough different directions, at enough different thresholds, that the cumulative distortion is invisible until something breaks. The question isn't whether your team cuts corners under pressure. They do. The question is whether you've decided together which corners can never be cut — or whether you're leaving that to chance, and hoping the holes don't line up.