Some problems are too sticky for a normal sprint. The backlog is full, the pager is angry, and two teams disagree on what is even broken. That is where the Solver archetype earns its keep. It is not hero mode. It is pattern hunting with a bias to ship.
What I walk into
- Ambiguity. The problem statement is usually wrong.
- Cross team dependencies. Ownership is fuzzy.
- High risk delivery. If we miss, it hurts customers or the business.
How I start
- Quiet triage. I look at logs, dashboards, recent changes, and rollouts. No meetings yet.
- Reframe the problem. Write a one paragraph statement anyone can repeat.
- Draw the minimum map. Data flow, interfaces, failure points. Whiteboard, then code.
Tools that work
- Spike branches that answer one question at a time.
- Toggle flags to test in production without chaos.
- Shadow traffic or read replicas for safe experiments.
- A daily note with what we learned, what we cut, and what we try next.
Momentum mechanics
- Deliver thin slices. Prove the path in a week, not a quarter.
- Borrow experts for 48 hours, not 8 meetings. Pair, get the insight, keep moving.
- Make rollback the default. Confidence comes from safe exits.
Handing it back
The toughest part is the exit. Solvers can leave a mess if they toss code over the wall. I do this instead:
- Keep the solution small and documented.
- Add runbooks, alerts, and a test that fails loudly when the original bug shape returns.
- Agree on an owner before the fix merges.
- Do a short readout on what we learned so the team levels up.
What I will not do
- Stay forever. If I am the only person who understands it, I failed.
- Optimize the wrong bottleneck. Prove it with data.
- Confuse activity with progress. A noisy Slack channel is not a milestone.
Wrap up: The Solver archetype is about unlocking stuck work. Triage fast, experiment safely, ship thin, and make the handoff boring.