How do you identify and mitigate technical risk?

Question

Accepted Answer

**Technical risk** is anything that could derail delivery or break in production, unknowns, fragile dependencies, scaling limits, single points of failure. A TL's job is to **surface risk early and shrink it deliberately**, because risk is cheapest to address before you've built on top of it.

## How to manage risk

```text
1. IDENTIFY — what could go wrong? (unknowns, deps, scale, security, people)
2. ASSESS — likelihood x impact. Focus on the high-high quadrant.
3. ATTACK the biggest unknowns FIRST — spike, prototype, load-test
4. MITIGATE — reduce likelihood or blast radius (redundancy, flags, fallbacks)
5. MONITOR — track known risks; have a plan if they materialize
```

## De-risk early, not late

The most dangerous risks are *unknowns*, the things you can't estimate. Tackle them first with a spike or prototype, so you learn the truth while the project is still cheap to change. Building the easy, known parts first feels productive but leaves the landmine for the end.

## A concrete example

A project depends on a third-party API you've never used at scale. Don't design the whole system assuming it works, prototype against it in week one. If it can't handle your load, you find out now, not after you've built everything around it.

## A pitfall

Doing the comfortable, known work first and saving the scary unknown for last. That maximizes the cost of being wrong, exactly backwards.

## Why it matters

Risks ignored until late become crises, expensive, schedule-wrecking, and morale-crushing.

A TL who hunts risk early trades a small known cost now for avoiding a large unknown cost later.

That foresight is much of what makes a senior lead worth their salt.