A few years ago, at one of my earlier employers, I sat in a planning meeting that turned into a 90-minute debate over a fairly small architectural decision. The team was deciding whether to introduce a new internal service to handle a piece of glue logic that lived in two places. Easy decision, you’d think. The eventual call cost about a week of work, and was reversible inside an afternoon.
Yet for 90 minutes, three of the most senior engineers on the team listed reasons we should be careful. One remembered a similar service from a previous job that had become a maintenance nightmare. Another raised the spectre of “service sprawl”. A third wanted to write an RFC, get sign-off from the architecture group, and align with a few adjacent teams before we shipped.
I was one of those three. I was the one who’d been burned before, who knew where the bodies were buried, who’d “seen this exact thing go wrong” at the previous company. I felt responsible. I felt like I was protecting the team. I made the case for caution with the full weight of a decade of engineering scars behind it, and the juniors in the room nodded along.
What I should have said, and didn’t, was the thing I now believe is true: the most experienced engineers on a team are often the single largest source of Fear Premium in an engineering org. (I coined term “Fear Premium” earlier in this article) And for a couple of years, that engineer was me.
That meeting wasn’t an isolated event. I’ve sat in versions of it at three different companies - twice as the over-cautious senior, once as the manager watching it happen and wishing I’d run the room differently. The pattern is the same every time, and it’s worth naming.
The scar tissue compounds
Engineers don’t become risk-averse with age because they read a book about it. They become risk-averse because they’ve been on call when production caught fire. They’ve spent a long weekend fixing data corruption because someone shipped a migration without a backout plan. They’ve watched a careless deploy take down revenue for hours, and they remember the postmortem, and the look on the VP’s face.
These are real things, and the lessons are real. Hot stove, don’t touch.
Mark Twain put it better than any postmortem:
We should be careful to get out of an experience only the wisdom that is in it — and stop there; lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again — and that is well; but also she will never sit down on a cold one anymore.
The risk for senior engineers isn’t that we fail to learn from pain. It’s that we over-learn, and there’s about fifty years of cognitive science explaining how. The availability heuristic means we estimate how likely something is by how easily an example comes to mind; a senior engineer reaching for a probability is reaching for the most vivid prod incident they ever saw, not the base rate over their last hundred deploys. Negativity bias is what Baumeister and colleagues summarised, fittingly, as “Bad is stronger than good”, as it adds that negative events imprint deeper and pull harder on future decisions than positive events of the same size. Ten years of scary stories, processed through those two filters, produces a brain that systematically overestimates blast radius.
The problem is that the lessons compound. Every scar adds a new rule of thumb. “Always write an RFC before introducing a new service”. “Always have two engineers review database migrations”. “Always get product approval before refactoring a hot path. Always-always-always” and so on. By year ten, a senior engineer has accumulated a personal library of “always” rules, each of which made sense at the moment of the burn that produced it.
Individually, every rule is defensible. Collectively, they form a fortress. Imagine if every defense line increased timeline of every delivery by multiplier of 20%, and then you compound, say, 10 of them?
Gerd Gigerenzer has a name for this fortress when you find it in organisations: defensive decision-making. The chosen option isn’t the best one for the problem; it’s the safest one for you if something goes wrong. He documented it first in medicine, where doctors over-order tests not because the tests help patients but because absent tests are something a malpractice lawyer can point at. The engineering analogue is the third review forum nobody needed and the RFC for the two-day change. It’s not the best answer to the technical question. It’s the answer nobody can blame you for.
This is one of major reasons why engineering leaders want to invest in the culture where engineers aren’t punished for failure!
The same trait we hire senior engineers for. pattern recognition, having seen things go wrong before, is also the trait that, in the wrong context, slows the team to a crawl. They’re not malicious. They’re not lazy. They’ve simply optimised their personal risk function over a decade of fires, and the optimisation is local.
I want to stress: I’m describing myself here as much as anyone else. The version of me that walked into that planning meeting was operating on twelve years of accumulated rules, and I genuinely believed each of them was load-bearing. Most of them weren’t.
Why this fear spreads faster than anyone else’s
Here’s where it gets bad. The same seniority that makes senior engineers effective at their craft also makes their fear institutionally contagious.
When a junior engineer says “I’m worried about this,” the room politely listens and then moves on. When a tech lead with 12 years on the platform says “I’m worried about this,” the room writes a document about it. A new column appears on the Jira board. A weekly review forum gets scheduled. The architecture group adds an item to their agenda. By the end of the quarter these added rituals are part of “how we work here,” and nobody quite remembers who started them or why.
I’ve watched the pattern unfold the same way more than once:
- A senior engineer raises a legitimate concern about a specific case
- The team adds a process to cover that case
- The process generalises beyond the original case
- Nobody re-evaluates whether the process is still load-bearing two quarters later
- The senior engineer who raised the concern moves on to another team, taking the context of why-we-do-this with them
- The process remains, now justified by tradition
There are at least two well-studied dynamics doing the work here. An information cascade is what happens when each person in a sequence rationally over-weights the signal coming from the people before them and under-weights their own quieter private information; the room converges on the high-status concern regardless of what any individual actually thinks. An availability cascade is the slower-burn version: a vivid worry, once voiced, becomes more cognitively available to everyone in the room, who later make it more available to everyone they tell, until the worry is something “everyone knows” the company is exposed to. Sociology has been calling this a goal displacement since Robert Merton named it in 1940, the rule outlives its purpose, the ritual is preserved because it exists, and the original “why” becomes unrecoverable.
Half the safeguards I personally lobbied for in my IC years had no business existing six months after I introduced them. I was doing Fear Premium with the best of intentions. The worst part is that I was praised for most of them at the time. In all honesty, some of the rituals I introduced earlier in my career probably shouldn’t have existed at all.
The promotion trap
There’s a structural reason for this, too, that’s worth naming.
Some engineering ladders promote people for *not breaking things*. Senior, staff, principal, every rung up the ladder rewards judgement, mentorship, and reliability. Rarely I’ve seen a process that explicitly rewards someone for removing safeguards. They reward people for adding them. Additions are visible, go onto brag doc, while deletions are often overlooked.
So a senior engineer optimising for promotion is, structurally, optimising for adding things - architecture diagrams, design docs, review forums, “let’s get aligned” meetings. There’s no incentive to delete. Deletion is invisible work. Adding a new RFC template gets you praised in a calibration meeting. Killing an obsolete one rarely does.
Behavioural economists call the underlying asymmetry omission bias: people judge harmful actions more harshly than equivalent harmful inactions, even when the outcomes are identical. The engineering ladder inherits the bias wholesale. Shipping the bug is a commission. Failing to delete the dead process is an omission. The first ends careers. The second is invisible.
The result is that the people with the most authority to cut zombie rituals are the same people whose promotion trajectory is rewarded for creating them. This is not their fault. It’s the system. But it’s worth seeing clearly, because it explains why the problem is so persistent.
What this doesn’t mean
A quick pause: I’m not arguing that senior engineers are the problem and we should ignore them. I’m not saying their fears are wrong. Often they’re absolutely right, and the team should listenm especially on one-way door decisions, where their scar tissue is exactly the asset you’re paying them for.
What I’m arguing is that the calibration is off. A senior engineer who reflexively adds caution to every decision is misapplying a high-precision instrument. The instrument is correct for some cases, and harmful for others. The work is helping them notice the difference. Including, and especially, when “them” is yourself.
If I had to describe the ideal senior engineer in a high-velocity SaaS environment, it would not be “the person who catches every risk.” It would be “the person who knows which risks are worth insuring against, and who is psychologically capable of letting the rest pass.”
How to un-condition (without dismissing the scars)
A few things that have worked for me: first when I had to un-condition myself, later when I was helping other senior ICs do the same.
1. Make door-classification an explicit team practice. Before any technical debate, ask: is this a one-way door, or a two-way door? Force the team to answer it out loud. Two-way doors get five minutes of debate and a decision. One-way doors get the RFC treatment they deserve. The act of asking the question changes the conversation, because it makes the assumption “we should be careful here” something the team consciously decides on, not something the most senior voice in the room imports for free.
2. Ask “what would happen if we did the quick version? before the debate, not after. Senior engineers default to imagining the worst case. Make them imagine the realistic case too. Quantify the blast radius. Most of the time it’s smaller than the fear suggests.
3. Celebrate deletion as loudly as you celebrate creation. When a senior engineer kills a process that’s no longer earning its keep, name it in the team retro. Promote it as a milestone. Mention it in the calibration round. Make it visible. If your ladder doesn’t recognise deletion as senior-level work, advocate up the chain to fix the ladder.
4. Pair a senior engineer with a “fresh eyes” partner once a quarter. Someone newer to the team, ideally newer to the company, whose explicit job is to ask “why do we do this?” about every ritual. The senior provides context, the fresh eyes provide the question. Many rituals don’t survive a 30-minute interrogation by someone who isn’t emotionally attached to them.
5. Normalise saying “I was burned by this, and I’m probably overcorrecting.” I started doing this in my own technical reviews, out loud, years before I moved into management. *”I want to flag that the last time I saw something like this, it cost us two weeks of cleanup. I might be over-indexed. What does the rest of the room think?”* It changed the room. It gave juniors permission to push back. It also gave me a chance to notice my own reflexes and decide whether they actually applied this time.
6. Hire for the second kind of seniority. When interviewing senior candidates, ask about times they removed a process, killed a ritual, or argued for shipping the cheaper version. If they can’t tell you one story, no matter how impressive their technical answers are, you’re probably hiring more Fear Premium into your team.
The quiet asymmetry
The thing that’s hard to internalise is that the cost of an over-cautious senior engineer is invisible, and the cost of a reckless one is loud. When someone ships too fast and breaks production, everyone hears about it. When someone slows the team for six months with a parade of unnecessary reviews, nobody hears about it, they just see velocity drift down, shrug, and call it “scaling pains.”
This asymmetry is exactly why the problem grows. The reckless engineer gets corrected immediately. The over-cautious one gets promoted. And the team learns, slowly and silently, that the path of least resistance is to add more caution, more process, more rituals because nobody ever got in trouble for adding a step, but plenty of people got in trouble for skipping one.
There’s one last cognitive piece holding the whole thing in place. Hindsight bias is the much-replicated finding that once we know how a story ended, we remember having predicted the ending all along. Every senior engineer who has seen a failure now feels they *saw it coming*. The fear feels like wisdom because the brain has retroactively rewritten the past into a sequence of warnings that, in the moment, weren’t nearly that clear. That’s why “trust the senior’s gut” is harder to argue against than it deserves to be: the gut is reporting back from a past the brain has tidied up after the fact.
If you’re an engineering leader, this is worth sitting with. Your senior engineers are doing exactly what your system asked them to do. They’re not failing. The system is succeeding at producing them. The job is to change what the system rewards. And if you came up through engineering yourself, the harder version of this is recognising the same pattern in your own instincts, and being willing to name it out loud.
**Don’t fear, be brave** applies to senior engineers too. And to the people we used to be.
---
Notes & further reading
When working on the article I’ve been challenging my ideas with existing research, and there’s quite a bit of it. I didn’t read majority of these books in full, so rather treat it as sources of evidence rather than reading recommendation.
Mark Twain (1897), Following the Equator - source of the cat-on-the-hot-stove-lid epigraph. The whole maxim is about the cost of over-generalising a single bad experience.
Tversky & Kahneman (1973), Availability: A heuristic for judging frequency and probability (Cognitive Psychology) - the original demonstration that we judge frequency and probability by how easily examples come to mind. For a recent experimental confirmation that availability-by-recall causally drives real risk judgments, see Efendić (2021), How do people judge risk? (Risk Analysis).
Baumeister, Bratslavsky, Finkenauer & Vohs (2001), Bad is stronger than good (Review of General Psychology) - the canonical synthesis of negative events imprinting more deeply than positive events of equal size. For a recent large cross-national replication using psychophysiological measures, see Soroka, Fournier & Nir (2019), Cross-national evidence of a negativity bias in psychophysiological reactions to news (PNAS).
Gigerenzer (2014), Risk Savvy (Penguin) - the popular treatment of defensive decision-making, with the doctor-ordering-CYA-tests example. For the formal organisational-behaviour version, see Artinger, Petersen, Gigerenzer & Weibler (2015), Heuristics as adaptive decision strategies in management (Journal of Organizational Behavior).
Bikhchandani, Hirshleifer & Welch (1992), A theory of fads, fashion, custom, and cultural change as informational cascades (Journal of Political Economy) - the foundational model of rational agents in sequence converging on a high-status signal and ignoring their own quieter private information. The formal version of “the room writes a document about it.”
Kuran & Sunstein (1999), Availability cascades and risk regulation (Stanford Law Review) - the slower social-amplification version of an information cascade, in which a vivid concern becomes “what everyone knows” through repeated retelling.
Merton (1940), Bureaucratic structure and personality (Social Forces) - origin of “goal displacement,” the observation that the means of a bureaucratic rule outlive and eventually replace its original purpose. The dead-process-still-on-the-Jira-board paper.
Spranca, Minsk & Baron (1991), Omission and commission in judgment and choice (Journal of Experimental Social Psychology), with Ritov & Baron (1990), Reluctance to vaccinate: Omission bias and ambiguity (Journal of Behavioral Decision Making) — the experimental establishment that harmful actions are judged more harshly than harmful inactions of identical consequence. The “added a step vs skipped a step” asymmetry.
Fischhoff (1975), Hindsight ≠ foresight (Journal of Experimental Psychology) the original “knew-it-all-along” demonstration. For the modern synthesis, see Roese & Vohs (2012), Hindsight bias (Perspectives on Psychological Science); for a recent defence of the evidence base against replication-era critique, see Gerken (2023), Assessing the evidence for outcome bias and hindsight bias (Review of Philosophy and Psychology).