Face the Risks First

Three times in my career, I’ve seen teams fall into the same trap. They set ambitious goals, started delivering, and then…progress stalled. Trust eroded. Why?

In each case, the team had spotted big risks early on. But instead of tackling them, they focused on the parts they knew how to do, showing progress first and saving the risks for later. Unsurprisingly, those risks came back to bite them.

My advice, which I give to every new project I lead or coach, is simple: face the risks first.

This doesn’t mean solving every risk upfront or finding all the “unknown unknowns.” But it does mean taking risk seriously from the start. Here’s the three-step approach I use.

1. Identify the Risks

Start by categorizing risks into two groups: inherent and transient.

• Inherent risks: These are baked into the project’s goals. Look for these two types in particular.

  • High customer impact: Will this project significantly affect customers’ experiences or expectations?

  • One-way doors: Are we making decisions that are costly to reverse, like public APIs or foundational technical bets?

• Transient risks: These are challenges that arise during the project but will disappear once it’s successfully delivered. I use the Cynefin framework to break these into two.

  • Complex risks: Unknown unknowns—there’s no clear solution, and the only way to learn is by trying.

  • Complicated risks: Known unknowns—there’s expertise to solve them, but do you have the right people or knowledge?

Write these risks down. Naming them is the first step toward managing them.

2. Hedge Your Bets

Once you’ve identified the risks, take steps to reduce uncertainty. This might mean solving the risks upfront, or it might mean gathering enough information to proceed with confidence. Here’s how I approach each type of risk.

• Inherent risks:

  • High customer impact: Validate assumptions with customer conversations, UX tests, PRFAQs, or small experiments.

  • One-way doors: Use feedback and alignment tools like RFCs, architectural reviews, financial analyses, or peer discussions to refine decisions.

• Transient risks:

  • Complex risks: Build throwaway prototypes or run experiments to explore the unknown.

  • Complicated risks: Bring in experts who’ve solved similar problems. If expertise isn’t available, experiment. But recognize that the riskier the situation, the more valuable expertise is likely to be.

My goal for transient risks is to reduce every complex problem to a set of clear or complicated problems and to have believable confidence that there’s at least one viable path forward for each complicated one. Without this, teams risk stalling—or digging a hole to nowhere.

3. Face Risks Together

As you start building, involve key stakeholders—peer leaders, managers, and the business—in understanding the risks you’re taking on. Innovation inherently involves uncertainty, but shared awareness builds trust and enables better decision-making.

When tackling the work, again, face the risks first for each vertical slice and even each pull request. Start with the riskiest or least-understood parts of the problem until you are confident in your approach. By addressing risks early, teams build momentum and confidence while keeping the project on solid footing.

Closing Thoughts

Of course, there are exceptions. I’ve seen teams paralyzed by “analysis paralysis,” where the biggest risk was their own inability to start. In those cases, the best approach is to build momentum with quick wins, even if it means leaving some risks for later.

But more often, teams benefit from learning the value of delayed gratification. Like the marshmallow test, facing risks first can lead to better outcomes in the long run, even if it feels harder in the moment.

Do you find yourself coaching teams to tackle risks early, or driving action first? I’d love to hear how you approach this challenge.