How to Build Structural Courage
We keep trying to change the people. The environment changes them back.
Most of us have worked for that one leader who made the team feel different. You could say “I don’t think this is the right problem” without it costing you a reputation for being a roadblock. You could make a call without chasing three approvals. When some metric didn’t fit how your team actually worked (say/do, anyone?), they took the heat so you didn’t have to.
For a while, the product work felt the way it was supposed to.
Then that leader left. Maybe it was a better opportunity, a reorg, or maybe a layoff.
That leader was holding the whole thing together with duct tape and glue, and it held right up until they let go. We praise leaders like that, and we should.
The person who replaced them wasn’t a villain. They just played a different game, maybe the one the rest of the company rewards. Perhaps it was the deficit of trust or a different leadership style that you lost your autonomy in product decision-making. The team went back to measuring outputs (what we were shipping), instead of outcomes (what problems we were solving). A few cycles later, you reverted to being a feature factory, not building products.
A team that only works because of one specific leader isn’t a system. It’s a personality trait, and personality traits leave when the person does.
I’ve named the alternative Structural Courage, and I’ve written about it in pieces. The short version: Structural Courage is when the system takes care of the things we normally need individual bravery for. Telling the truth, killing an experiment that’s secretly your baby, saying out loud that you got it wrong. On most teams, those take a deep breath and a good day. The point is to make them ordinary.
Since writing and speaking about it, I have been thinking about what it takes to build Structural Courage. So let me be specific. There are two pieces you can put in place on your own team - Enabling Constraints and Operational Autonomy, and a third that decides whether any of it outlives you - that’s density. Let me explain.
Enabling constraints. A constraint is just a boundary, but the right one makes the behavior you want the path of least resistance. Without it, people drift back to whatever the system rewards. I learned this the slow way. I taught my team to ask “what problem are we solving,” but the demos and planning asked “what are we delivering”, and within weeks, they were listing features.
So, I rewrote the performance rubric for how I measured the team. Instead of asking for a list of which features you shipped, it asked which user problem you solved and what it did for the customers and the business. You can’t answer that with a backlog. Most of my team couldn’t answer it at all at first, because they’d never actually measured impact, so they had to go build the instrumentation for it. The constraint forced new work into existence.
Operational autonomy. This helps push decision-making down to the teams that have the information, without coming to ask first. I got the mechanics from David Marquet, the submarine captain who took over the worst-performing ship in the fleet and learned to stop giving orders. His crew started saying “I intend to” instead of waiting to be told. But the crucial part is that he didn’t just hand over the keys and hoped for the best. He built two things first - Competence and Clarity. The team had to be competent to know what was actually safe (do they know how?), and they had to have clarity about why it mattered (do they know why?). Competence and clarity work together. Clarity tells you what matters. Competence gives you the confidence to defend it.
Density. Here’s what I got wrong doing all of this. I built enabling constraints and operational autonomy on my team. And it worked until I left. I had built something that still needed me to sustain it, which is a hard thing to admit about work you were proud of. The research on how norms spread says you need somewhere around a quarter of a group behaving the same way before the behavior spreads and stops needing a champion. I didn’t build density, I was the density. One brave team is not a system. This only survives when enough people carry the behavior that no single one of them is exposed for holding it.
If you take one thing from this, watch the questions that get asked in your next planning meeting - when will something be delivered, or why it matters. That’s the system telling you what it actually rewards. If the questions don’t change, the system won’t either.
Structural courage is building that foundation on purpose, so the next time a good leader moves on, the team they shaped keeps working without them.
Don’t be the hero. Build the system so you don’t need one.