Sometimes People Have to Grab Hold of the Electric Fence
There is a moment — and every leader has had it — when you are watching someone on your team walk directly into a mistake you have made before. You can see it coming. You can feel the muscle memory of the thing going wrong, and you can feel the words forming in your mouth: don’t. Just, don’t.
Sometimes you should say the word. Sometimes you should let them reach for the fence.
The craft of being a manager, an executive, or a board director is knowing which is which — and doing both well, several times a week, for your entire career. It’s the other half of working on the org rather than in it : the leader who has built an engine still has to decide which decisions are theirs to make and which to hand back.
Some of the time, let them grab the fence
I want to start with the case leaders handle worst — which is the case where they should not intervene but feel compelled to anyway.
If you are constantly telling people what to do, you are not helping them build their own resilience or their own capability. You are solving their problem for them, which is not the same as developing them. A team whose leader intervenes in every decision becomes a team that cannot make decisions. You have replaced the collective judgement of your organisation with the single-point-of-failure judgement of one person — yourself — and the moment you are not in the room, the team cannot move. This is, incidentally, the single most common failure mode I see in early-stage product operating model attempts — the leadership team says the words “empowered teams” and continues intervening on every Type B call, and the teams learn quickly that empowerment is decoration.
Some decisions are exactly this shape. Some decisions are recoverable, low-stakes, and the cost of the wrong choice is a small amount of learning for the person making it. If you take that learning away from them, you haven’t saved them from the mistake — you’ve stolen the education the mistake would have provided.
There’s also a blunter, more selfish reason to hold back. You have finite time. A leader who tries to intervene on every decision runs out of oxygen long before they reach the decisions that actually matter. The cost of intervening on the small stuff isn’t just cultural damage to the team — it’s that you have nothing left in the tank when the genuinely consequential call arrives. Protecting your own attention is not laziness. It is how you remain useful to the organisation when something big needs you.
So for some meaningful share of decisions, the move is: tell them what you see, offer your view, then get out of the way and let them choose.
Type A and Type B decisions
The default breaks down for a particular kind of decision.
Jeff Bezos popularised a useful framing, and I have used it for twenty years since the first time I read it. Decisions come in two types. Type B decisions are two-way doors. You can walk through, and if the room on the other side turns out to be wrong, you can walk back through the door. The decision is reversible at modest cost. You learn, you come back, you try something else. A lot of the decisions a product team makes in a given week are Type B.
Type A decisions are one-way doors. Once you walk through, the door closes behind you. The choice is durable, consequential, and expensive or impossible to reverse. A core architectural decision. A major platform commitment. A senior hire into a founding team. A multi-year contract with an infrastructure vendor. The adoption of a data model the entire company will build around for a decade. Once a Type A decision is made, the organisation is living with it, and “we tried it and we’ll change our mind” is not available as a recovery strategy.
The leadership rule is simple in principle and hard in practice. Type B decisions are usually where you hold back. Type A decisions are usually where you intervene. The word usually is doing real work in both halves of that sentence — the art is in recognising which one you’re looking at, and that recognition is the craft of the job.
I got a Type A wrong, once, on day one
I will give you the example that still makes me wince.
My first day at Trayport, I was asked to opine on a particular architectural decision. The team had thought about it, they had a recommendation, and they wanted my view. I had enormous misgivings. I also had, at that exact moment, absolutely no tenure in the company, no credibility with the team, and no appetite to start my first day by overriding their judgement. So I swallowed the misgivings and trusted the team.
Five years later, we were still fighting with the architecture. Every single quarter the consequences of that decision showed up in the roadmap — in the capacity the team lost to working around it, in the features we couldn’t ship because the architecture wouldn’t bend, in the engineers we struggled to hire because the tech stack was off-putting. A Type A decision, made in a single afternoon, compounded into five years of drag on the business.
That was an electric fence I should have pulled someone back from. The fact that it was my first day, and my misgivings were based on pattern-matching rather than specific evidence, did not make them wrong. They were, in retrospect, exactly right. And the cost of the politically easy choice on day one was the hardest five years of my tenure.
Every developer does it once
The technical version of this happens in almost every engineering team I have ever run.
Every developer, at some point in their career, decides they are going to build a data store using an N-tuple model — some generic, maximally-flexible entity-attribute-value pattern that promises to handle every future data shape the business might ever need. The pitch is always the same. “It gives us ultimate flexibility. We won’t have to refactor the schema every time the product changes.” It sounds like wisdom. It sounds like engineering maturity. It is, in almost every case, the exact opposite.
An N-tuple data model (or its close cousin, the “let’s build everything as a graph database” proposal) solves a problem most products don’t have by creating a problem every product does have — namely, that no query is ever simple, no index ever fits, no performance characteristic is predictable, no new developer can read the data, and every feature you build takes twice as long because the schema has been perdurably abstracted away from the domain. Five years later the team is still paying for the architecture; the promised flexibility has hardened into a prison.
As a senior developer, do not let that person grab that particular fence. This is Type A. The cost of the mistake is too high, the recovery path is too painful, and — critically — the person making the decision cannot feel the cost in advance, because they haven’t yet lived through the five years of maintenance that will follow. You have. That is exactly when seniority is earned and exactly when it should be spent.
How to tell them apart in the moment
The honest answer is that there is no bright line. But the three questions I ask myself when I watch someone about to make a decision I would make differently are these.
How reversible is this? If the team can run the thing for six weeks, learn it’s wrong, and back out for the cost of the six weeks, it’s Type B and I shut up. If backing out involves a migration project, a vendor exit, a redesign of something deeply cross-cutting, or a write-off of a year of work, it’s Type A and I speak up.
Has the person making this decision seen it play out before? A team making a Type A decision with relevant prior experience has earned the benefit of the doubt. A team making a Type A decision from first principles, without having watched the failure mode, is vulnerable — and if I have seen the failure mode, it is my obligation to share it, even if I’m new, even if I haven’t earned the political capital yet.
Is the pattern one I recognise in my gut? Sometimes the misgivings are vague. Sometimes they are sharp and specific. Both are valid. Vague misgivings that persist after I have tried to argue myself out of them are almost always correct, and twenty years of leadership has mostly taught me to respect them rather than talk them down.
When you do intervene, do it well
The worst version of the intervention is the one where you make the person feel small. That destroys the relationship and teaches them nothing except to route around you next time.
The better version is the one where you say the three words — I’ve seen this — and then you tell the specific story. Not “I don’t think this will work,” which is a veto. Not “trust me,” which asks for blind faith. Instead: “Five years ago I watched a team do exactly this, here’s what happened, here’s why I think you’re about to hit the same wall.” Then you step back, because even with that context the decision is theirs.
Sometimes they will still grab the fence. That is their right, if the decision is genuinely theirs to make. But the intervention has done two things. It has given them information they didn’t have, and it has put a marker down that when the fence turns out to be electric, you and they will have a post-mortem rather than a fight.
When you let them grab it, support them afterward
The counterpart — and the one most leaders handle badly — is what happens after. If a team grabs the fence you warned them about and it is electric, your job is not to say “I told you so.” Your job is to help them recover, to make the learning explicit, and to ensure the cost of the lesson doesn’t compound into something career-damaging for the person who made the call. A team that feels punished for one bad bet stops making bets. A team that is helped to learn from a bad bet gets sharper.
The long-term health of the organisation is a function of how well it converts small mistakes into durable judgement. That only happens if mistakes are permitted, examined honestly, and not punished when they were Type B. The leader’s role is to run the post-mortem with kindness and rigour in equal measure, and then to let the team carry forward what they’ve learned.
An honest note on the examples
Most of the stories I’ve told here sit on the “I should have intervened” side of the fence. That isn’t because intervention is usually the right call — it isn’t. It’s because the mistakes that hurt are the ones that stick in memory; the decisions I chose not to intervene on, where the team worked it out and nobody got hurt, don’t form memories the same way. Those probably outnumber the dramatic interventions heavily. I just can’t easily remember them, which is the nature of calls that didn’t need to be made.
Hold both sides of this. The craft is the calibration, not the intervention.
The underlying claim
Sometimes people have to grab hold of the electric fence. That’s how they learn the fence is electric, and how they develop the muscle that will let them stand on their own two feet when you are not in the room. Sometimes you have to pull them back from the fence — because the shock is career-ending, or architecture-ossifying, or company-killing, and the cost of the lesson exceeds what the organisation can afford to pay.
Knowing which is which, deciding in the moment, explaining yourself when you intervene and supporting the team when you don’t — that is most of the job. Everything else, over a long enough career, is decoration.