Ask for Forgiveness, Not Permission
Or: The Four Words That Changed How an Entire Room Understood Failure
Beer and Servers Don't Mix — Microservices Workshop Series, Part 3 of 4
The slides had been up for forty minutes. Three quarters of missed targets, laid out in the kind of clean charts that make bad news look almost academic — until you do the arithmetic, which everyone in that room had done, silently, before the presenter got to the third slide. Three quarters. Not a blip. Not an unlucky run. A pattern. The people sitting closest to the presenter had, without seeming to notice they were doing it, shifted their chairs a few centimetres further away — the universal body language of people who have decided, at a subconscious level, that proximity to this moment carries a cost. The air conditioning hummed. Nobody moved.
The presenter finished. The room went the kind of quiet where you become very aware of your own breathing. Every eye moved to the end of the table.
The CEO said: "What did we learn?"
I've been teasing that story across two posts. It earns the wait, I think, because the thing that makes it significant isn't what it did for the presenter. It's what it did for everyone else in the room.
Every person sitting there was running the same risk calculation, and four words answered it for all of them at once. Not a policy. Not a values statement in a slide deck nobody reads after the all-hands. A live demonstration, in the highest-stakes moment available, of what failure actually costs at this company. They all left that room knowing. And because they knew, each one of them was — fractionally, measurably, but genuinely — more willing to try something that might not work.
That's the fix. Not a process change. Not a new metric. A repeated, observable pattern of what happens when things go wrong — and the manager behaviour that either builds that pattern or destroys it.
Why Punishment Travels Faster Than Praise
In the last post, we looked at the structural traps — the sprint metrics, the misaligned product person, the process that classifies initiative as failure. Those are real and they need fixing. But you can fix all of them and still have a team full of engineers waiting for permission they don't need, if the cultural signal underneath the process is wrong.
The cultural signal is set almost entirely by what leaders do when things go badly. Not what they say in retrospectives. Not what's written in the engineering principles doc. What they actually do, in the room, when someone took a risk and it didn't work out.
Here's the uncomfortable mechanism: punishment is more contagious than reward. When someone gets publicly criticised for acting without asking — overruled in a meeting, asked to "run it by me first" next time, had their initiative quietly un-done — the lesson doesn't land only on that person. It lands on everyone who saw it happen. The engineer sitting next to the engineer who got corrected updates their model faster than anyone. They weren't even involved. They didn't need to be. The signal was broadcast.
One incident, observed, can teach an entire floor of engineers that initiative isn't safe. That's not an exaggeration — it's how organisational learning actually works. We're social animals calibrating behaviour based on what we watch happen to each other, and we're very good at it.
The inverse is also true, but it takes longer to propagate and requires more repetition to stick. Which is why the CEO story matters as much as it does. Three quarters is a lot of evidence. The response, when it came, landed with proportional force.
The Manager Who Breaks It Without Knowing
Theodore Roosevelt put it plainly: "The best executive is the one who has sense enough to pick good men to do what he wants done, and self-restraint to keep from meddling with them while they do it."
Self-restraint is the part most managers underestimate, because the moment someone starts genuinely taking ownership is precisely the moment managerial anxiety spikes. An engineer stops a sprint without asking. A developer makes a call on an architecture decision you would have made differently. Someone ships a small change and tells you about it afterward instead of before.
The instinct — entirely understandable — is to re-establish the loop. "Just keep me in the loop." "Could you check with me before decisions like this?" "I want to make sure we're aligned."
Each of these is a veto in process clothing. And it registers that way, even when it isn't intended that way. The engineer who just acted on ownership instinct — who is, in fact, doing exactly what you said you wanted — has now received a clear signal: the thing I did created friction. Don't do it again without asking.
The particularly insidious version is the manager who says all the right things about ownership and autonomy, and then responds to every exercise of that autonomy with "that's great, but next time loop me in earlier." Said once, it's feedback. Said consistently, it's a policy. And it's a policy that teaches engineers your words and your behaviour are different things — and that your behaviour is the one that counts.
If your best engineers are still waiting for permission they don't need, the honest question isn't what's wrong with them. It's when was the last time someone acted without asking, and what did your face do.
What "Rewarding Initiative" Actually Looks Like
The CEO didn't congratulate the product person for failing three quarters running. He asked what was learned — which carries an implicit expectation: that the failure produced data, that the data is now owned, and that it will be used. The reward isn't the failure. It's being treated as someone who tried, learned, and is still in the room.
That distinction matters because "celebrate failure" has become the kind of advice that sounds meaningful and means almost nothing in practice. Nobody is celebrating failure. What they're doing — when they do it well — is separating the act of trying from the outcome, and making it observable that the act of trying is what the organisation values.
Concrete behaviours that build this pattern over time:
When someone acts without asking and it works: praise the action, not just the outcome. "Good call to just go for it" lands differently than "great result." The first rewards the decision-making. The second rewards the luck.
When someone acts without asking and it fails: "What did we learn?" Not "how did this happen?" Not "why didn't you check with me first?" The question signals that the information matters more than the accountability, and that the person asking it is interested in the former.
When someone asks permission for something they clearly could have just done: push it back. "Why are you asking me? You know this better than I do." This one feels counterintuitive — surely it's good that they checked? — but what you're actually doing is interrupting the waiting reflex at the exact moment it surfaces, and replacing it with a signal that says: your judgment is sufficient here. Use it.
When you disagree with a decision someone made: be precise about what you're disagreeing with. "I would have decided differently, and here's why" is a conversation. "You should have checked with me first" is a punishment. The first develops judgment. The second teaches caution.
Amy Edmondson's research on psychological safety — documented in The Fearless Organization — shows consistently that teams where members feel safe to take interpersonal risks outperform those that don't, across a remarkable range of contexts and industries. The finding isn't that safety makes people comfortable. It's that safety makes people willing to do hard things. That's a different claim, and a more useful one.
Ask for Forgiveness, Not Permission
The old line is usually treated as a piece of mildly cheeky personal career advice. It's actually an organisational design principle.
Environments where every action requires prior approval are environments where action slows to the speed of the approval queue. When initiative carries personal risk — a correction, a raised eyebrow, a "why didn't you loop me in" — people learn to wait. Not because they're timid. Because they've correctly read the incentive structure and made the rational choice.
The phrase "ask for forgiveness, not permission" is really describing a specific kind of organisational trust: the trust that says your judgment is presumed sound until proven otherwise, rather than presumed unsound until cleared. Most engineering organisations say they extend this trust. Most engineering organisations, if you watch the behaviour rather than listen to the words, do not.
Building it requires consistency more than anything else. One public demonstration of the CEO question — "what did we learn?" — shifts a room. But one contradicting incident, where someone tries something and gets visibly corrected for the trying rather than the outcome, can undo several of those shifts at once. The asymmetry is frustrating and it's real. Culture is built slowly and damaged quickly, and the damage is always done in the moments when it's hardest to get it right.
The Permission You're Not Giving Explicitly Enough
Here's the piece most engineering leaders miss: the permission to act without asking often needs to be stated directly, not just implied by the absence of rules against it.
Engineers who've spent years in environments where initiative was risky don't automatically update their model when the environment changes. They need to hear it said out loud, in a one-on-one, specifically: "You've been flagging this problem for three weeks. You don't need to ask me to fix it. If you see something that needs doing and you're confident in the call — do it. Tell me about it afterward."
That conversation, followed by a manager who responds to the first exercise of that permission with something other than friction, is worth more than any amount of "we're an ownership culture here" messaging. It's the difference between a policy and a pattern. And patterns are what people actually navigate by.
The station transitions from the first post — from waiting to reacting, reacting to initiating — don't happen by osmosis. They happen because a manager named them explicitly, gave specific permission for the next step, and then responded to the first attempt in a way that made the second attempt feel safe.
This is the work. Not the process reform from the last post, as necessary as that is. Not the metric changes. This: being the kind of leader who, when the room is watching and things have gone badly, asks what we learned — and means it enough that everyone in the room leaves knowing the answer.
In the final post, we look at what it looks like when all of this is working. Station 4 ownership — engineers who bring you problems you didn't know you had and arrive with solutions already forming. How to teach the proposal format. How to know when someone is ready for it. And the metrics that tell you the culture has actually changed, rather than just gotten better at describing itself.
Tags: Software Engineering, Engineering Leadership, Software Development, Tech, Engineering Culture, Psychological Safety, Management
LinkedIn: Culture isn't what you say when things go well. It's what you do when everyone's watching and things have gone badly. Four words can change a room.