This transcript was produced by robots and left as-is. Accuracy and elegance are not guaranteed.

Engineers are trained to select the right tool for the job. You wouldn’t use a torque wrench where a rubber mallet is called for. That’s pretty basic. You’d never do it on a physical job site. But most engineers apply the same level of analytical rigor to every decision, regardless of what it actually requires. Maximum review, complete data, defensible logic, every time.

That mismatch is expensive and it’s the thing this episode is about.

So the skill we’re talking about isn’t decision-making. Engineers are already good at making decisions. The skill is decision triage, the ability to quickly classify what a decision requires before you start analyzing it, and then match the right level of rigor to that classification. Engineers who don’t triage treat every decision like it’s a professional engineer stamp.

PE stamp standards, full review, complete data, someone who can defend every assumption if challenged. Some decisions deserve that. Some need it, but most don’t, especially in leadership. And here’s the part that gets missed. The cost of over-engineering a decision isn’t just your time. It’s the signal it sends to everyone watching.

When you apply maximum rigor to everything, you’re telling your team that you don’t trust them, yourself, or the process to handle uncertainty. And that signal compounds.

Now, I’m an Edmonton Oilers fan, so I get to watch Conor McDavid, who is the best player on the ice by a significant margin. And there’s a pattern that shows up when his team is in trouble. Everyone passes to him and he demands the puck every time because he’s the best option and it usually works.

But two things happen when that becomes the default. The team stops developing judgment. Why would they when he’s always there to bail them out? And McDavid carries a load that should have been distributed. He burns out doing work the team owns collectively.

A leader who applies maximum rigor to every decision or who becomes the person everyone defers to creates the same outcome. Decision quality isn’t a personal performance. It’s a shared capability. And the way you model that for your team is by calibrating your own rigor visibly so they can see what the standard actually looks like for different types of decisions.

So here’s the triage framework. Before you commit to a level of analysis, run these four questions. Number one, how reversible is this? A two-way door gets a fast call. A one-way door gets deliberation. The error most engineers make is treating two-way doors as one way. If you can undo it in a week without significant cost, it’s a two-way door. Decide and move.

Number two, how time sensitive is the cost of being wrong? Some mistakes are cheap to fix in week one and expensive after six months. If you’re inside that window, the cost of waiting can exceed the cost of making the wrong call and correcting it. Waiting has a price. It’s just less visible than the price of a bad decision.

Number three, who needs to own the implementation? If someone else has to execute the decision, maximum rigor from you and zero input from them is a specific kind of failure. You get compliance without commitment. They’ll implement the letter of the decision, but not the spirit. We covered this in episode 10, their involvement in the decision is part of the mechanism. It’s not consultation theater. It actually changes how they carry the work out of the room.

Lastly, number four, what’s the minimum information that makes this decision reasonable? So we’re not looking for airtight, just reasonable. That’s a different threshold. Once you have enough information to make a defensible call, not a perfect one, but a defensible one, the decision is ready. Collecting more data past that point isn’t rigor. It’s delay dressed up as rigor.

A couple of years ago, I was working with a client who had relocated a water pump outside of their cistern. The problem, the pump ended up being mounted higher than the cistern itself, and it couldn’t overcome the head pressure to pull the water out of the tank. Water that fed an operating plant. The system wasn’t working and they needed a solution.

Full disclosure, I’m an electrical engineer, not mechanical, not civil, not process. But I ran a fast informal triage in my head before I said anything. How reversible is the solution? Depends on what we propose. How time sensitive is being wrong? High, there is a plant waiting on this. Who owns the implementation? Well, that would be the mechanical team. What’s the minimum information I need to make a reasonable suggestion? I had enough.

So I said, what if you dig a vault adjacent to the cistern and drop the pump down to that same level? It eliminates the head pressure problem entirely. Simple, direct, relatively low cost to implement if it works, other than digging a giant hole and building a vault. The mechanical team took it, applied the appropriate rigor to the design package and it worked.

Now the point here isn’t that I was clever. The point is that the suggestion required maybe 30 seconds of structured thinking before I offered it. The right level of rigor for that moment wasn’t a full engineering review from me, which I couldn’t do anyway. It was a reasonable directional call that the right people could then build on. That is triage.

Now, there’s a distinction worth naming directly. Precision is about being right. Triage is about being appropriately right. Those are different standards and conflating them is what creates the torque wrench problem. The goal isn’t maximum accuracy. It’s the right accuracy for this decision made in time for it to matter. An engineer who can triage well isn’t less rigorous, they’re more efficient with rigor. They know where to spend it.

So here’s something simple to try this week. Before your next significant decision, run the four questions. See where you actually land. If it’s a two-way door, low stakes, time sensitive, set a time limit and decide. If it’s genuinely one way and high consequence, take the rigor, it’s warranted.

The goal this week isn’t to make faster decisions, it’s to notice, even once, that you’ve been applying PE stamp standards to a rubber mallet problem.

You came into this arc over relying on logic. Over the past few episodes, you’ve picked up mechanics for influence, tools for hard conversations, a diagnostic question about identity, and now a framework for decisions. None of that required a personality change. None of it required you to become someone you’re not. That’s a system and engineers build systems. That’s what this podcast is here to do.