Mistakes Were Made But Not By Me

The Corporate Art of Taking Responsibility Without Losing Anything

I've sat through enough post-mortem meetings to recognize the moment someone says the wrong thing. You can hear it before the words land. It's the slight pause before "mistakes were made," the way someone will use passive voice to describe outcomes they personally signed off on, the practiced humility that somehow leaves their title intact. This isn't about politics. This is about boardrooms, incident reports, and HR conversations where accountability goes to die. The phrase "mistakes were made but not by me" describes a specific category of workplace communication. It's not one sentence. It's a structural pattern you can find in incident response documents, quarterly reviews, and executive emails. Someone acknowledges that a failure occurred at a level high enough to suggest awareness, but they construct the sentence in a way that makes it impossible to trace the responsibility back to any individual or team. The phrase exists because the people who use it need a way to look transparent without actually being transparent.

Mistakes Were Made But Not By Me

When I was managing infrastructure deployments at a mid-size SaaS company, we had a policy where any incident causing more than four hours of downtime required a written post-mortem. I wrote thirty-seven of them. About twenty of them contained variations of this phrase. The ones that landed cleanly followed a predictable template. They opened with a timeline, identified the technical failure point, acknowledged the impact on customers, and then shifted into a paragraph where every subject was either a process, a tool, or an unnamed group of people. Here's what nobody tells you about writing these documents: the trick isn't avoiding accountability, it's making the accountability so diffuse that assigning it becomes an administrative burden no one wants to take on. You say the migration process lacked adequate rollback procedures rather than saying you approved the migration without a rollback procedure. The factual content is identical. The legal and political consequences are not. I learned this the hard way in 2023 when a client integration project I was technically leading collapsed because our staging environment hadn't been updated to match production API versions. The engineering team had flagged the drift three weeks earlier. I'd acknowledged the flag in an email and then didn't escalate it. When the integration broke on a Friday afternoon, I drafted a status update that said something like "inconsistencies between environments were identified but not resolved prior to rollout." That sentence is a textbook example. It's grammatically correct. It's technically accurate. And it assigns zero blame to any person while still documenting that the problem was known and unaddressed.

The workaround I used was simpler than you'd think. I stopped trying to hide the failure inside passive voice and started writing two versions of every incident summary. The public version used the standard corporate construction. The internal version, which I shared only with the engineering leads who actually needed to prevent the next occurrence, named names and decisions explicitly. This created a documentation gap that bothered me for a while until I realized the gap was the entire point. The public document exists for auditors and executives. The private document exists for engineers. Mixing them up serves neither audience. There's a specific technique within this pattern called the collective attribution shift. You start with an action that has a clear single decision-maker and gradually broaden the subject until it encompasses everyone and therefore nobody. A paragraph might begin by discussing a specific vendor decision, then transition to "the team's assessment," then to "organizational priorities," and finally to "the current operational model." Each sentence is defensible on its own. Together they create a wall where accountability simply has no surface area to stick to. Another pattern I see constantly is temporal deflection. You describe a decision that was correct given the information available at the time, then separately describe why the information was incomplete, and present these as two independent facts rather than a causal chain. The reader is left with the impression that the decision was sound and the outcome was unfortunate, with no necessary connection between the two. This works particularly well in written form because the causal link only appears when someone actively traces it backward.

The counter-intuitive part that most people miss is that this isn't just about evasion. It's about information compression. A full accountability report naming specific decisions and responsible parties creates liability exposure, damages team morale, and often triggers legal review. The corporate ecosystem has evolved this phrase as a pressure release valve. It allows an organization to acknowledge a problem publicly without opening the door to litigation or resignations. Whether that's wise is a separate question from whether it's effective, and it is effective. I've seen it work for exactly this reason. Here's where it breaks down though, and I want to be blunt about it. This approach fails completely in environments where the person receiving the report has direct knowledge of the underlying decisions. If your CTO personally approved the budget that killed the testing phase, telling her that "resource constraints impacted testing depth" won't land well. It reads as either insulting or cowardly depending on your relationship with her. The technique only works when there's a genuine information asymmetry between the writer and the reader. It also fails in regulated industries where the standard of care requires naming specific failures. In healthcare, aviation, and financial services, passive-voice incident reporting doesn't just look evasive. It can constitute a compliance violation. I consulted for a fintech startup that tried using this technique in their SOC 2 audit responses and had to rewrite everything because the auditor flagged it as an attempt to obscure material control deficiencies. The framework requires you to name the gap, not describe it poetically.

If you're looking to actually write these documents effectively rather than just recognizing them, here's what I'd suggest. First, understand what audience you're writing for. Is this going to legal, to the board, to the engineering team, or to customers? Each audience requires a different level of specificity and a different tolerance for vagueness. Second, be consistent with your terminology. If you use "the process failed" in one paragraph and "we missed a step" in the next, you've inadvertently assigned agency to yourself in the second sentence while denying it in the first. Pick a framing and stick with it. Third, and this is the part most people skip, verify that the facts in your vague sentences are actually true. I've seen people write that "testing was insufficient" when in fact no testing was conducted at all. The difference matters when someone later asks for evidence. There's a specific edge case that catches people out. When you're writing about a failure that involved multiple departments, the collective attribution shift can accidentally implicate the department you were trying to protect. I worked on a project where a product decision conflicted with a security policy, and I wrote something like "competing priorities across teams led to a gaps in the review process." The word "teams" is plural. It implicates everyone. It looked like I was spreading blame, which in retrospect was fine, but it also looked like I was admitting organizational dysfunction, which gave leadership an excuse to escalate the whole thing to the executive committee. I should have been more specific about which team's priorities took precedence. Being vague in the wrong direction is just as dangerous as being precise. Download templates aren't really useful here because the technique is entirely context-dependent. What works for a software outage post-mortem falls apart in a manufacturing quality report. What I can offer is a decision framework. Before you write any sentence about what went wrong, ask yourself three questions in sequence. Who had the information? Who had the authority to act on it? Who had the incentive to communicate it upward? If all three answers point to the same person or group, your sentence should reflect that reality or it will collapse under basic scrutiny. If the answers point in different directions, which they often do in complex organizational failures, then the passive construction might actually be describing something true rather than evading anything.

The phrase itself became popular in political discourse around 2009 when it was used in a congressional hearing about mortgage practices, but it's had a much longer career in corporate environments. I've found versions of it in incident reports going back to the early 2000s, which suggests this isn't a cultural trend so much as a structural feature of how organizations handle bad news when the people involved have something to lose. One more thing that's worth understanding and this is where it gets uncomfortable. The people who use this technique most effectively are rarely the ones getting caught. I've watched senior engineers and middle managers write brutally honest incident reports that named their own mistakes clearly, and they were the ones who got pushed out during reorganizations. Meanwhile, the executives who could draft the most impenetrable accountability-free summaries were the ones who got promoted. There's a selection effect at play here. Organizations that tolerate this language tend to retain the people who are good at using it and lose the people who refuse. By the time anyone notices the pattern, the wrong people are in charge of writing the next incident report. If your goal is to write a post-mortem that people will actually read instead of filing away and forgetting, the best approach is to front-load the specific failures and bury the deflection in footnotes. Give readers the actionable information first. The vague accountability language tends to get skimmed anyway, so don't waste the prime real estate on it. Your engineering team needs to know what broke and why. Your executives need to know that you're aware of the systemic issues. Those are two different audiences with two different documents, and pretending they're the same is what creates the problem in the first place.