The Impact Bomb

Six months ago, in a perfectly quiet, overly air-conditioned 1:1 room, I sat across from one of my best engineers. Let’s call them Morgan. Morgan is a machine. They are the biological equivalent of a beautifully indexed database: quiet, reliable, and capable of retrieving the exact right piece of institutional context in milliseconds. I was sitting there, leaning back in my ergonomically aggressive chair, dispensing what I believed to be canonical corporate wisdom. Morgan had just asked what it took to get to the next level.

I steepled my fingers. I actually steepled my fingers, projecting the calm authority of an executive who understands exactly how the organizational machine routes its incentives. I told Morgan they needed to demonstrate more Impact.

Morgan nodded, dutifully writing the cursed capitalized word down in their notebook. I assumed we had just established a healthy, highly motivated career trajectory.

We were finished, right? Wrong. The trap was set, the timer was ticking, and I was entirely oblivious.

I didn't know it at the time, but I had just planted a time bomb deep in our codebase. The detonation was entirely silent at first. It required a long, agonizing incubation period of background processing before the blast radius became visible to the naked eye. Morgan wanted a promotion, and I had handed them the exact cryptographic key required to unlock it. I thought I was being a Coach. I was actually an arsonist.

Smash cut to six months later. It’s 2:14 AM on a Thursday, and my phone is aggressively buzzing itself off the nightstand. The product is bleeding users, the support queues are overflowing, and the codebase is completely on fire. A highly articulate, deeply enraged viral geekyschmidt post accurately diagnoses our unasked-for UI update as a textbook case of Verschlimmbesserung—an attempted improvement that objectively makes things worse.

The ensuing Hacker News comments are a masterclass in blistering outrage over a perfectly good workflow being ruined. You read the thread and your stomach drops. The blood leaves your face because, despite the unrelenting vitriol, the internet strangers are entirely correct. The new interface is an unmitigated disaster of latency and convoluted navigation.

Let us pause to clarify a critical distinction regarding organizational decay. Cory Doctorow’s concept of enshittification arrives through executive malice and a greedy thirst for corporate profit. Verschlimmbesserung operates on a far more tragic frequency. It is driven by sheer competence masked as ambition. Morgan woke up and executed the exact algorithm I provided to achieve their career goals. This was the inevitable output of my garbage input.

Let us reverse-engineer this disaster by violently winding the clock backward from that raging Hacker News thread.

We must rewind past the panicked hotfixes shipped at midnight by a deeply caffeinated, profoundly cynical triage team.

We rewind past the exhausted QA lead, staring blankly at her monitor at 6 PM on a Friday, missing a critical edge case because she lacked the cognitive bandwidth to process the sheer volume of Morgan's bloated pull request.

We rewind past the fateful sprint planning meeting where Morgan aggressively advocated for a total UI rewrite. Morgan cited a vague, urgent need for architectural updates and the deprecation of legacy frameworks to drown out any architectural objections from the senior staff—who were too tired to argue, because they were busy fighting actual fires. The senior staff capitulated under the overwhelming technical jargon, asking only that the core login pathways remain untouched. (Spoiler: The login pathways broke).

We wind the clock all the way back, past the wireframes and the Jira tickets, and we land straight back in the chair in my overly air-conditioned 1:1 room.

The Decay of Impact:
Manager says "Impact"
   ↓
Engineer imagines Rewrite
   ↓
QA misses Edge Case
   ↓
User posts Angry Thread

Morgan committed медвежья услуга—a Russian idiom describing a well-intentioned action that results in catastrophic harm—purely because I cornered them with a vague, terrifying requirement. MORGAN JUST WANTED TO DO A GOOD JOB. By weaponizing the concept of Impact without defining its boundaries, I forced my best engineer to scramble and find the loudest, most disruptive project imaginable. I initiated a catastrophic context switch from quietly maintaining stability to launching massive features designed solely to attract executive attention.

I have a false dichotomy for you. If you strip away the polite agile fictions and the HR prescriptive bullshit, all engineering labor falls into one of two capitalized buckets.

First, we have The Flash. This is the shiny new button, the radical aesthetic redesign, the highly visible, easily quantifiable feature work that executives can slap onto a quarterly presentation slide. The Flash is loud. The Flash is sexy. The Flash gets you applauded in all-hands meetings by people who don't know what a compiler is. The Flash is what gets a junior developer noticed by the vice president who only drops into the Slack channel once a quarter to leave a rocket-ship emoji.

Second, we have The Foundation. This encompasses the microscopic bug fixes, the technical debt paydown, and the agonizingly slow, entirely invisible maintenance that keeps the system from collapsing under its own weight. The Foundation is a thankless, silent void. Doing this work is the equivalent of running defragmentation on a spinning platter hard drive… nobody cares until the entire disk crashes and you lose three years of customer data.

We have seen this binary play out on a global scale. Consider the universally stable Microsoft Office 2003, an application practically vibrating with pure Foundation. It was boring, rigid, and it worked every single time you launched it. Contrast that with the chaotic introduction of the controversial Office 2007 Ribbon, a textbook manifestation of pure Flash that utterly disrupted established workflows across the globe. The humans building the Ribbon required a massive, highly visible project to prove they were doing something worthy of a promotion.

The mathematical proof of this systemic failure is Eliyahu Goldratt’s axiom: "Tell me how you measure me, and I will tell you how I will behave.". When your promotion rubrics demand Impact but fail to define invisible stability as a valid form of it, you introduce catastrophic packet loss into your team's decision-making algorithm. Your engineers will dutifully tape unnecessary, highly combustible fireworks to the roof of your perfectly functional car. They will do this because fireworks are the only metric the network actually routes to the promotion committee.

If you tell the humans on your team that keeping the servers running earns zero political capital, they will abandon the servers. They will start building a bespoke, untested framework just to put their name on the repository.

Frank, I literally have to evaluate them on something objective so the committee doesn't reject the packet.

No.

You are confusing ease of measurement with actual value. Evaluating The Flash is trivial because it has a high-resolution screenshot. Evaluating The Foundation requires the manager to genuinely understand the latent architecture of the system and aggressively fight for the engineer who is quietly preventing memory leaks in the dark.

The business will naturally worship The Flash because a shiny new interface renders beautifully on an investor deck. As the leader of the humans, you must operate as a rigid firewall shielding the system from that emotional chaos. You must mechanically protect the invisible work. Caving to the rubric and permitting your team to chase shiny objects makes you complicit in destroying your own product's trust. The business will always demand fireworks. Stand up, ignore the noise, and make absolutely sure the building doesn't burn down. Reward the Foundation. No matter what.