Work Backward From Production

Your team just shipped a quarter’s worth of features in a week. The agents did the typing, the demos look great, and everyone is thrilled. Congratulations. You just got faster at the cheapest part of the job.

Coding was never the expensive part, unless you never delivered it. The cost didn’t vanish when AI made generation cheap. It was never in the typing to begin with. Map any real delivery process, and the coding is a sliver of the whole. I’ve measured this across multiple teams, and it’s always the same: requirements, integration, testing, approvals, and the long tail of keeping the thing alive dwarf the time spent writing the code.

So if the cost isn't in the keyboard, where does it live? It lives after you ship. That is the part most people don’t plan for until coding is already “done.”

“It’s awesome! How do we deploy it?”

It’s like building a piece of fine furniture only to discover it won’t fit through the door of your shop, and your options are to abandon it or tear down a wall.

When someone tells me operations isn’t a problem anymore because they moved to a managed platform, they’ve answered a different question. A platform like that solves hosting. It does not solve operations. Hosting is where the software runs. Operations is everything involved in keeping a running system useful: keeping it available, supporting the people who depend on it, patching it as the threat landscape shifts under you, and changing it as the business changes. You can rent infrastructure. You own the rest.

Here’s a sharper way to see the scope. Operations is keeping the thing running and useful once real people depend on it, and most of that turns out to be a question of information. Do you have the instrumentation to catch a problem before your users do, or before they quietly stop using the product and never tell you why? Do you know which features are actually earning their keep, so you can add what helps and cut what doesn’t? Can you ship the next version and the security patch after that without your customers noticing an outage? None of that is hosting, and none of it shows up in the demo.

The product's lifespan is longer than people like to admit. You aren’t done when you ship. You’re done when you delete the code. Quality was always more than “does it work?” It means the system is stable, available, fit for purpose, and secure. That last word is not a one-time certification. Something secure today is exploitable tomorrow. A dependency with no known vulnerabilities becomes the victim of a supply chain attack the week after you ship. Operations is the work of carrying out all of that for years.

If operations is this large and this obvious, why do capable organizations keep treating it as someone else’s job until it’s on fire?

The pattern repeats because the incentive structure rewards building, not operating. Teams get celebrated for shipping features. In organizations where people get promoted for big, splashy changes or putting out fires, the change blast radius increases, and fires happen more often. Nobody gets promoted for keeping a system boring and stable for six months, so no one focuses on the work that keeps it that way.

Everyone cares about what they’re incentivized to care about. If you reward output, you get output, and you get a growing pile of operational debt that nobody is paid to notice. This isn’t a character flaw in your engineers. It’s a rational response to the scoreboard you gave them.

Watch how it plays out in the metrics. When an operations team is measured by tickets closed, the number actively punishes the right work. Closing tickets scores. Removing the reason the tickets exist does not. So nobody automates the recurring request, nobody fixes the root cause, and the queue regenerates forever. You optimized for the appearance of work rather than its elimination.

The deeper version of this is the decision to shield developers entirely from production, handing the running of the system to a separate group that absorbs the pain of choices it didn’t make. It feels efficient. It’s also how you guarantee the people building the system never learn what it’s like to run. You build it, you run it. Shield the builders from production, and they never find out what they built.

None of this is a discipline failure on the team floor. It’s a design decision made by someone above the team about how the work is structured and rewarded. That makes owning the full lifecycle a leadership responsibility, not a team chore.

If leadership owns the lifecycle, leadership needs a discipline for it. There’s one that works, and it runs in the opposite direction from how most projects start.

Start at the end and work backward. Decide what operating this system needs to look like, then let that drive the architecture, the team shape, and the pipeline. The outcome you want is a system that stays up, recovers fast, and can be changed without breaking for years. You don’t arrive there by accident after the features are done. You design for it first.

To do this, we invert the usual build order. The first feature is the ability to deploy safely. Observability (knowing what the system is actually doing in production) and a way to undo a bad release without standing up a war room come before the shiny thing the demo is about.

This is what continuous delivery is actually for. Not shipping features faster, though it does that too. Its real value is the ability to respond safely to whatever operations needs: the urgent fix at two in the morning, the security patch that can’t wait for the next scheduled release, the rollback when what you shipped starts misbehaving. You build one safe path to production and use it for every change, including emergencies, so you never have to bypass your own controls at the worst possible moment. A team that can only deliver when nothing is on fire cannot operate.

For a leader, working backward isn’t a technical exercise you delegate. It’s a gate you hold before you fund the work. Three questions decide whether a build is ready to start.

How will we know this system is healthy, and how will we change it when the change is urgent and the pressure is on?

Who operates it, and can that team sustain it on top of everything they already carry?

How do we keep it patched and secure as the threats evolve? The certification you pass at launch expires the moment the world changes.

These are not questions the team quietly answers for itself after the fact. They’re the questions you require answered before you approve the build. All of it compresses to one blunt question. Ask it before you approve anything: can you sustain it?

At this point, the smartest person in the room objects. And they’re half right.

You can’t predict production, they’ll say. The strong form of that objection is real: any operations plan you write before the system has seen real traffic will be wrong in its specifics. The failure modes you carefully designed for won’t be the ones that take you down at three in the morning. I’ll concede that completely. The specific plan will be wrong.

Production is non-linear, stateful, and adversarial. Spiky traffic with the same average as smooth traffic behaves nothing like the average. The threat landscape shifts under you on its own schedule, which is the same reason a security certification doesn’t stay true. The tools for reasoning about all of this precisely are poor. Pretending otherwise is how you get surprised.

But “the plan will be wrong” is not a license to skip planning. The value of working backward was never the accuracy of its predictions. It’s the controls, the instrumentation, and the muscle memory you’re forced to build before you need them. You don’t plan in order to be right. You plan in order to be ready.

We already know this from physical engineering. Nobody builds a bridge and then figures out how to maintain it and hopes only one car uses it at a time. You design for expected load, for inspection and repair, and you put controls in place to prevent collapse. A bridge has it easier than your system, in fact: its load is slow and well understood, while yours is adversarial and changes by the hour. That is exactly why you design for inspection, recovery, and safe response instead of for a forecast you know you’ll miss. I have scars from decades of doing this the hard way, and the lesson from each one is the same. You plan for failure before it happens, not make it up on the fly in the middle of the night.

That pattern holds in software as much as it does in concrete. None of this is new. It was all true before AI. What AI changed is the payment schedule.

The gap between the shortcut and the consequence used to be months, sometimes years. Long enough that the people who took the shortcut had often moved on by the time the bill arrived. When you ship a quarter’s worth of changes in a week, production exercises every untested path that much sooner, so AI collapses that gap to weeks. The bill didn’t get bigger. It just comes due faster and in larger batches.

That’s because AI amplifies whatever you already have. The bottleneck was never the typing, so making the typing faster fixes nothing. It just lets you manufacture operational liability at a rate your old, slow timeline used to hide from you. A disciplined team compounds its strengths. A team without it ships time bombs primed to explode in production, only faster.

So the order of the questions has to change. Don’t fund a build without an operations plan, and work backward from production before you write the first line. The teams that make this shift are the ones that start measuring what’s sustainably running, not just what shipped. Once you measure that, people start asking, “Can we operate this?” before “Can we build this?”

The cheap part was never the question. Coding was always the easy part. The real question, the one that decides whether you’re building an asset or a liability, has always been whether you can live with what you ship. AI didn’t change that question. It just means you have to answer it before you start, not after it’s on fire.