Decision-making as a leadership competency, in behaviors

"Strong decision-maker" appears on nearly every leadership competency model, usually rated on a five-point scale by someone who has never watched you make a hard call under time pressure. It's a strange thing to score, because decision-making isn't a trait you have more or less of — it's a sequence of things you do, most of which happen invisibly, in your own head, in the minutes before anyone else sees an outcome. The label rates the outcome. The competency lives in the process, and the process is made of behaviors.

This is the deep-dive pattern from this pillar applied to the competency people are most confident about and least able to describe. Break decision-making into the specific behaviors it's actually made of, and two things happen: you can see where yours breaks, and you can develop it — because a behavior is something you can change, while "be a better decision-maker" is a wish.

What decision-making is actually made of

For a leader, the decision-making competency decomposes into a handful of observable behaviors — observable in the sense that a thoughtful person working with you could tell whether you do them or not, even when you can't. As the pillar's manifesto argues, that's the only level at which any competency can be developed or assessed.

Naming that a decision exists — and who owns it. A surprising share of bad decisions were never actually made. They drifted: the meeting ended, everyone assumed someone else would call it, and the default won by inertia. The behavior is making it explicit — this is a decision, I own it, here's when it's made by — so a choice happens on purpose rather than by fatigue. The weak version leaves the room without anyone able to say what was decided.

Surfacing the case against, before committing. The strongest predictor of a bad call isn't lack of intelligence — it's never having genuinely invited the reasons it might fail. Gary Klein's project premortem is the behavior in its cleanest form: before you commit, imagine the decision has already failed a year from now and ask everyone to write down why. It works because "prospective hindsight" — assuming the failure has happened — makes people about 30% better at naming real risks than open-ended worry does. The observable version is simple: does the room ever hear the case against, out loud, before you decide, or only after it's gone wrong?

Making the reasoning visible. Announcing what you decided without why costs you twice: the team can't align against a rationale they never heard, and they can't learn how you think, so every similar decision routes back through you. The behavior is saying the reasoning out loud, especially the trade-off you didn't take. (It's also where decision-making overlaps communication — a decision nobody understood is, functionally, a decision you didn't make.)

Closing at the right time. Decisions have a cost of being made too late and a cost of being made too early, and the competency is knowing which risk you're running. Deciding before the cheap information arrives is recklessness; waiting for certainty that will never come is a decision to let the default win. The observable behavior is whether you can name what you're waiting for — and whether, when it arrives, you actually close.

Updating on evidence, not on doubt. Reversing a decision because new facts appeared is a strength. Reversing it because someone pushed back hard, or because the discomfort of having decided crept in overnight, is thrash — and your team can tell the difference even when you can't. The behavior worth watching: when you reopen a call, did new information actually arrive, or just new anxiety?

Why you can't tell, from the inside, whether yours works

Here's the trap. You remember your decisions as a highlight reel of the good calls, narrated with the reasoning you can articulate now rather than the actual impulse that drove them at the time. What you don't see is the pattern: the three decisions that quietly drifted, the reversal that looked like thrash to everyone downstream, the call you made fast because sitting in the ambiguity was uncomfortable and you told yourself it was decisiveness.

Your team sees the pattern and not much of the reasoning — the exact inverse of what you see. That asymmetry is why decision-making is a competency you genuinely can't develop alone: the evidence you'd need to improve lives in the observations of the people who watch you decide and live with the results, and almost none of it reaches you unless you ask.

How to actually develop it

You develop decision-making through the loop, not a course on "executive judgment." Pick one of the five behaviors — not "decision-making." If your gap is closing, the one behavior might be: for any decision I've reopened twice, ask whether new information arrived or just new doubt, and if it's doubt, close it. If your gap is surfacing the case against, it might be: run a two-minute premortem before any call that's expensive to reverse.

You pick one because "make better decisions" gives you nothing to do on Monday, while "state the decision, the owner, and the revisit date before this meeting ends" is a rep you can run this week. The point of the loop is reps on one behavior, measured — not a resolution to be wiser.

A worked example: from "decisive" to actually deciding

Say your self-image is that you're decisive, and a round comes back with your team rating your decision-making well below where you put it — with comments about decisions that "keep coming back." You resist fixing "decision-making" and find the specific behavior: you decide fast, announce the what, skip the why, and then — because nobody understood the reasoning — the decision gets relitigated in hallways until you quietly reopen it. What felt like decisiveness read as instability.

The one behavior becomes: state the reasoning and the trade-off I'm accepting, in the same breath as the decision. The cue is any call that affects more than one person. For the first few weeks it feels slow — you're used to just calling it — but the relitigation drops, because people are aligning against a rationale instead of guessing at one. You re-ask the same people a couple of months later whether decisions feel more settled. If the read moves, the competency moved, through one behavior. If it didn't, closing probably wasn't the gap — maybe it was surfacing the case against — and you pick again.

See where yours actually stands

The starting move is the same as for any competency: an honest self-assessment of these behaviors, then the same questions answered by the people who watch you decide. The decision-making style template is built for exactly this — you answer first on how you think you decide, send the same questions to the people affected by your calls, and read the two columns side by side. The gap between "I'm decisive" and "your decisions keep reopening" isn't a criticism; it's the most useful thing you can learn about this competency, and it points straight at the one behavior to work on. (If you want the raw material first, the manager self-assessment's "what you decided" questions are a good solo warm-up.)

That same decompose-then-measure approach works for any competency on any framework. Decision-making is just the one people are surest they've mastered — which is exactly why the gap is worth checking.

Decision-making, in one place

• "Strong decision-maker" rates the outcome. The competency is a process made of behaviors, and only you can see the process — which is why you can't self-assess it.
• The behaviors: name that a decision exists and who owns it, surface the case against before committing, make the reasoning visible, close at the right time, update on evidence rather than doubt.
• Your team sees the pattern (drift, reversals, decisions nobody understood) that you don't. That makes feedback the only real signal.
• Develop it through the loop: pick one behavior, attach a cue, run it in real decisions, re-measure with the people who live with your calls.
• A premortem is the highest-yield single behavior — inviting the case against before you commit beats explaining the failure after.