Leadership Garden
Stay in the Room
The first time I had to end someone’s job, I rehearsed the sentence in the elevator.
Three lines, agreed with HR the day before. Clear, kind, final. I had the words. What I didn’t have was any idea what to do with my hands, or where to look when his face changed, or how to walk back to my desk afterward and sit among the people who still had theirs.
So I did the thing. Stared at my screen, clicked around, pretended to work. Left early. It sat with me for months.
Here is what that experience did to me, and it’s the only reason I’m writing this. It made me a much better hiring manager. Not in a vague, inspirational way. Specifically: the next time I was in a room with five people talking themselves into a candidate who was “probably fine,” I was the one who said no. Because I knew, in my body, what “probably fine” costs twelve months later.
That’s the real subject here. Not pain. Proximity to the consequences.
Pain is a proxy
There’s a popular version of this argument that I want to take apart before I make my own, because it’s half right in a way that’s worse than being wrong. The version goes like this: people need to suffer to learn, big companies have made work too soft, real growth comes from feeling the full weight of your mistakes. No pain, no gain.
I get the appeal. I’ve felt the thing it’s pointing at. But “you need pain” is a sloppy stand-in for something more precise, and the sloppiness gives cover to managers who do real damage in the name of toughness.
The thing that taught me wasn’t the suffering. The suffering was incidental. What taught me was the short distance between my decision and its result. I hired carelessly, I had to be the one to undo it, and the loop closed fast enough and close enough that I couldn’t look away.
Plenty of pain teaches nothing at all. Getting humiliated in front of your peers teaches you to hide. A 60-hour crunch teaches you to resent the people who imposed it. Anxiety just teaches you to avoid. None of that is learning. It’s cost with no lesson attached.
So here’s the precise claim. People learn from proximity to the consequences of their decisions. Pain is sometimes a side effect of that proximity. It is not the active ingredient, and optimizing for it is a mistake.
Blame and distance are different dials
Almost every conversation our industry has about this collapses onto one axis: blame versus blameless. We argue about whether to name the engineer in the postmortem, whether someone should get fired for the outage, whether psychological safety has made everyone soft.
Wrong argument. There are two dials here, not one.
The first dial is blame: how much individual fault and punishment we attach to a failure. The second is distance: how far someone sits from the consequences of what they did. We’ve welded these together in our heads, as if turning blame down requires turning distance up. It doesn’t.
You can run a completely blameless postmortem in which the engineer who shipped the bug is in the room, hears exactly what it did to a real customer, walks through their own reasoning out loud, and owns the follow-up. No fault assigned. Full proximity. That’s the good quadrant, and it’s available to anyone who wants it.
What actually happens in a lot of “mature” orgs is the other thing. We turn blame down and distance up at the same time, then congratulate ourselves on the first and never mention the second. The bug becomes “an incident.” The incident becomes “a learning.” The learning becomes a ticket. By the time it’s written up it has the emotional texture of a weather report. Nobody got blamed. Nobody got changed either.
Opt in to a generative organizational culture instead.
(The original blameless idea, the Etsy and Google SRE version, never argued for any of this. It said: don’t punish people for honest mistakes, because punishment makes them hide the information you need. That part is correct. It said nothing about insulating people from what their mistakes actually did. We added that part ourselves, because it’s comfortable.)
Keep people close to the consequences
If proximity is the active ingredient, then the manager’s job is not to inflict pain and not to remove it. It’s to protect the signal. Keep people close to what their decisions do, and clear away the noise that makes them hide.
Start with the hard conversation. When you have to tell someone their performance isn’t working, or that the behavior in the last standup can’t continue, or that their role is gone, be the one in the room. The pull to outsource this is strong and getting stronger. There’s an HR partner who will “lead the conversation.” There’s a script. Increasingly there’s a video call, which I’ve never had to do and hope I never do, because I’ve watched enough of them happen to other people to know that talking into a webcam strips out the exact part that teaches you. The discomfort of doing it in person is not a defect to be engineered away. It is the feedback. It’s the thing that makes you hire more carefully and give feedback earlier next time. Remove it and you get a manager who keeps making the same hire and feels nothing when it ends.
I want to be careful here, because this is where the “no pain no gain” crowd goes wrong. The goal is not to make these conversations traumatic. It is not to make you good at them through repetition until you go numb. The opposite. The managers I trust most have done this many times and feel it less now, not because they’ve hardened, but because they know they did everything they could upstream. They hired well. They gave the hard feedback early, when it could still change something. They didn’t let it rot for a year. The proximity made them better, and being better is what eventually lowers the pain. Numbness from avoidance and calm from competence can look identical from the outside. They are not the same thing, and you can usually tell which one you’re looking at by checking whether the person did the upstream work.
The same logic runs straight through engineering. The best thing I’ve seen for code quality is not a process. It’s a customer on a call, describing in their own words and their own frustration the weekend they spent cleaning up data because of a bug someone on the team shipped. You cannot get that feeling from a Sentry alert. The phrase “some customers were impacted” is built, almost perfectly, to protect you from learning anything. Real names, real voices, real fallout. That’s what makes a team hold the line on quality past the point where holding it is convenient.
On-call is the cleanest version of this we have, and plenty of orgs quietly defang it. You build it, you carry the pager. When the people writing the code are the people getting paged at 3am by the code, the loop closes on its own. No values poster required. Split those two groups apart, one team shipping and another holding the pager, and you’ve built a machine for producing things nobody has to live with.
The last one is about you, not your team. When a project starts to wobble, the tempting move is to swoop in and fix it yourself. Feels like leadership. It’s actually the surest way to keep your team distant from their own consequences, permanently. They never feel the wobble, so they never learn to steer. I’ve done this more than once. It always feels generous in the moment, and it always looks, a year later, like a team that can’t operate when I’m not in the room.
The machinery of distance is mostly invisible
Here’s what makes this genuinely hard. Almost none of the distance in a modern org was added on purpose, and almost all of it was added for a good reason.
Feature flags are good. They are also a layer between you and the blast radius of a bad change. Staged rollouts are good. They also mean the thing you broke gets caught by a system instead of by a furious email landing in your inbox with your name on it. Blameless culture is good. Done lazily, it becomes a ritual whose actual function is making sure nobody feels anything. Remote work is good for a hundred reasons. It also turns the hardest human moments of the job into something you do through a screen, which is to say, badly.
I’m not arguing to rip any of this out. That would be its own kind of toughness theater. The point is only to notice that distance accumulates by default, quietly, one reasonable decision at a time, and that it is nobody’s job to notice it. So it becomes yours.
When you find a spot where your team is fully insulated from the results of their own work, that is not a sign of a healthy system. It’s a leak in the feedback loop. You should at least know the leak is there.
One open question
I’ll leave this one as a question, because I don’t think I have the answer yet.
The biggest distancing machine I have ever watched get installed is the one we’re all installing right now. When an engineer writes a function, they own it, and when it breaks they feel the tug of that ownership. When they accept a function an AI wrote, something shifts that I don’t think we’ve named well. The code passed review. It compiled. It was never really theirs. If proximity to consequences is what turns experience into judgment over a career, what happens to a generation whose relationship to most of their code is approval rather than authorship? Maybe nothing. Maybe judgment routes around it. But I’d want every leader rolling this out at speed to at least sit with the question, because the distance is being added the same way it always is: for good reasons, by default, with nobody assigned to watch it.
Find the places your people are protected from what they do. Some of that protection is mercy, and you should keep it. Some of it is just distance wearing mercy’s clothes. Learn to tell the two apart, and then stay in the room.