Move Fast and Blame Things

I was on a call with a client recently, walking through bugs in a booking flow I'd built for them.

Weeks earlier, I'd asked in writing whether there were any recurring issues he wanted me to get ahead of, specifically so problems didn't compound. He wrote back that there was nothing on his end, but he'd let me know if that changed. You can guess what he never ended up doing.

Then, months into the engagement, on a recorded call, the story flipped: the code had never been “production ready”. Nobody had ever defined that phrase. The contract only ever specified a five-day bug window for identified problems, nothing else.

When I asked again for a written list of what "working" actually meant, so I'd have something real to check my own output against, the answer was: if he had to spell it out in that kind of detail, he wouldn't need me. He could just prompt an AI to build it himself.

In between those two moments, he'd also been pushing his own fixes directly into the shared codebase. He did it quietly, without telling me what he was changing or why.

Some of what got waved at on that call was evidence of ongoing quality problems and code neither of us had actually reviewed together. It was edited by two people working blind on the same files with no record of who touched what.

The real problem wasn't my code. It was a process with no shared definition of correct and no paper trail for who changed what, run by someone who'd already turned down, in writing, the one chance to fix that.

Naming a standard was beneath him. Not having one, or any record of who was editing what, was never treated as a gap at all, not until it became something for me to have failed at: reading minds and git history I was never shown.

I've watched this exact shape play out elsewhere too: in nonprofits, in a performance review that ended in my own layoff, and lately in how people talk to AI.

Nobody wants to do the work of saying what "right" means up front. Ask them to, and you've become the problem. Naming the standard reads as a confession you can't do the job without one. Failing a standard nobody bothered to state reads as proof you can't do it either. Somebody built this trap, even if no one sat down and designed it on purpose. Turns out it even has a slogan.

Frankly: all of this is infuriating, and everyone doing it should know better. Dealing with someone who holds a senior title and none of the instincts that are supposed to come with it is worse than dealing with most stomach parasites. A parasite, to its credit, never once asked me to write its own treatment plan.

I think it’s important to identify incentives. What is the incentive for someone to not do things right? Usually time pressure.

"Move fast and break things" was Facebook's internal engineering motto before Zuckerberg formalized it in his 2012 IPO letter and hung it on posters in every office. It gave skipping rigor a name and a shrug, so it stopped looking like negligence and started looking like a virtue.

Facebook retired the phrase in 2014, replacing it with "move fast with stable infrastructure," and the reason was on the record: what got broken turned out to be privacy, election integrity, people's attention spans. The company that coined the ethos concluded it doesn't scale past a toy project. Everyone still quoting it, including everyone currently pointing an AI tool at a problem with no definition of success attached, is citing a retracted finding.

The excuse only works because of what's happening underneath it, and that part has a name.

Once you know something, you can't easily imagine not knowing it. That's the curse of knowledge, named by economists Colin Camerer, George Loewenstein, and Martin Weber in a 1989 paper about traders who couldn't stop acting on information they should have ignored, even when it cost them.

It's since become the standard explanation for why an expert assumes a standard is obvious when it's only obvious to them. My client may genuinely believe "production ready" is self-evident. In his head, it probably is.

That's the charitable read. Personally, I believe people take advantage of the benefit of the doubt, so I think it boils down to: writing a standard down costs something socially. It means the standard becomes a specific, arguable thing instead of a vibe he gets to adjudicate after the fact.

Keep it unwritten and he keeps the power to decide, retroactively, whether it was met. Camerer's traders couldn't help themselves. My client can, which is the whole difference between a bias and a strategy.

I know this from the inside too, not just as a contractor. Years ago a manager put me on a performance improvement plan, and when I asked for specific examples of what I'd actually done wrong, she told me flatly: "you can't keep specific examples on this kind of thing."

One stated deficiency was failing to attend team activities, which turned out to mean I'd skipped a team hot pot outing on a Sunday and missed one team event while out sick. Fun fact: when you care about specificity, you can actually identify these things.

The plan required 80% attendance at company events to pass. I ran that against the actual events calendar and found it mathematically impossible to hit, even counting makeup videos, short of attending things like a mandatory fitness class.

My manager was also, by her own admission, keeping a second copy of the plan "with clarification" that differed from the one she was asking me to sign. Two standards existed. Only one of them was written down for me to see.

I filed a formal rebuttal with dates, names, and documentation for every claim, hit what vague targets I could hit anyway, and lost the job regardless. The standard was never the point. The paper trail was. Call it what it is: managerial cowardice with a Docusign attached.

Here's why nobody pushes back when the standard goes missing: asking feels like admitting weakness.

Alison Wood Brooks, Francesca Gino, and Maurice Schweitzer ran a set of studies in 2015 and found that people who ask for advice get rated as more competent, not less, especially on hard tasks and especially when they ask someone who actually knows the answer. The effect gets stronger as the task gets harder, which is the exact opposite of what everyone withholding a spec seems to believe about themselves.

A real spec does take work to write. My client wasn't wrong about that part.

Where he was wrong: thinking that asking for one, or offering one, said anything bad about either of us. The person avoiding that conversation is protecting against a penalty that the research says doesn't exist, while handing a real one to whoever has to guess in his place.

This isn't just my hunch about one client, either. Software engineering has been measuring this for decades under duller names. Ambiguous requirements are the most cited cause of late-stage rework and blown budgets.

Vague code review comments, the "this is confusing" kind with no named problem and no proposed fix, get ignored or misapplied at measurably higher rates than comments that state what's wrong and what to do about it. Teams got tired enough of doing this to each other, no client involved at all, that they invented Conventional Comments (different but altogether similar to Conventional Commits), a labeling convention that forces a reviewer to mark every comment issue: or nitpick:, blocking or not, before they're allowed to post it.

Nobody's short on data about how expensive this back and forth is. They're just missing the spine to act on it, because staying vague still costs them nothing and costs everyone downstream the difference.

Yes the thing made by humans is treated the same way we treat humans. The refusal to specify is now the default way most people talk to AI models.

It's actually a cleaner test case than any human relationship, because a model has none of the shared context that makes the curse of knowledge a plausible excuse. Nobody can claim a chatbot already knew what they meant. There's no relationship for the ambiguity to hide behind.

And yet: "make it better," "make this look professional," "fix the bugs," typed into a text box with no audience, no format, no constraint, no definition of what a correct answer even is. Real frustration follows when the output doesn't match a standard that only ever existed in the requester's head.

I've written before about how a model completes whatever pattern you actually hand it, not the one you meant to hand it. People run this exact move on each other too, but with a fig leaf attached: pretend the other party should already have known.

A model doesn't give anyone that fig leaf. There's nobody left to blame the ambiguity on except whoever typed the prompt, which might be exactly why so many people insist the model is what's broken. It usually isn't. You are, and some part of you knew that before you hit enter.

None of this survives by accident, either. There's an economic reason the behavior keeps winning: a shipping line can run its engines hot to hit a schedule because the emissions produced ocean and atmosphere’s problem, not on the captain's bonus.

A client can decline to write acceptance criteria for the identical reason. The cost of that decision, the rework, the arguments, the trust that erodes, lands on whoever had to guess, not on him. That's the shape of a principal-agent problem in general: the person who decides how much rigor to apply usually isn't the person who pays when it turns out to be too little.

Technical debt research puts a number on it: recent industry surveys estimate roughly a quarter of development effort goes toward servicing debt that was taken on to move faster earlier. That debt doesn't get erased. It gets paid later, with interest, by someone who usually isn't the person who chose to skip the rigor in the first place.

The mechanism is the same everywhere. What fixes it depends on what you're building.

The fix already exists and mostly goes unused: a written Definition of Done, agreed before the work starts, not adjudicated after. Not vague documentation, a specific one, covering what the client accepts as finished, what counts as a bug versus a feature request, who signs off and on what. Contracts already do this for scope and hours; almost none do it for quality, which is exactly the part left open to be redefined later.

This might also include the usual thing people forget: testing and more importantly regression testing. How do you know your changes worked and will work consistently, and how do you know the model didn’t introduce unexpected behavior?

When a client says "not production ready" with no attached definition, the answer isn't to fix faster. The next deliverable is the definition itself, in writing, and it's billable, because writing down a standard is real work, not overhead you do for free to prove you're not difficult.

Same failure, different vocabulary. Programs get funded and run for a year before anyone writes down what "impact" was supposed to mean, then a board or funder retroactively decides the outcome didn't count. Volunteers come into an org and you have no idea what on-boarding looks like or what they should know.

The fix is a logic model or a monitoring-and-evaluation framework approved before the program launches: here's the activity, here's the output, here's the outcome accepted as a signal of success, here's who signed off on that being the bar. It’s also standards, expectations, codes of conduct, and things people can lean on. (AI also makes this super easy to do; ask me how I know.)

This is the most dangerous version, because the paperwork looks rigorous while staying meaningless. A performance improvement plan that can't state, in advance, exactly what failing looks like and exactly what passing looks like isn't an improvement plan. It's a decision that already happened, dressed up enough to survive a wrongful-termination review.

The fix is the one HR departments already know and mostly decline to apply: performance criteria tied to the actual function of the job, measurable before the review period starts, with the standard fixed for the duration of the plan. If meeting the stated bar doesn't change the outcome, the bar was never the reason. It’s the same reason you don’t get your annual bonus after you were promised it for months.

Whoever controls the definition of success controls the verdict. The way they keep controlling it is by never writing it down.

My client and my old manager aren't cartoon villains, just people doing the thing that costs them least today: staying vague, deciding later, keeping the option to move the bar open.

Understanding the incentive isn't the same as excusing it, though. Both of them are adults with enough experience to know exactly what withholding a standard buys them. Calling it a bias is generous. Half the time it's just a strategy with better PR.

Refusing to define a standard looks like leanness and costs nothing up front. Asking for one is the move that gets treated as the weaker play, even though the research above says that fear is backwards. Nobody realizes that the technical debt will eventually come knocking.

Everybody's optimizing for themselves, and the whole thing gets worse for it. That's a system problem. It's also, on my less charitable days, just people who should know better choosing not to.