Fast interventions.
One specific problem.
Framework built.

What This Looks Like

Last month: Engineering team stuck on architecture decision. Microservices vs monolith. Eight weeks debating. Product couldn't start work until decided.

One 3-hour session: Mapped decision criteria (scalability, team capacity, timeline). Evaluated both options. Made choice. Documented rationale so everyone understood why.

Surprise bonus: Extracted the decision framework. Team's used it 3 times since for other architecture calls.

Timeline: 8 weeks stuck → 4 hours to decide and document.

Here's What Happens

We start by getting everything on the table. All options. Not just the obvious two you've been debating. Often there's a third path nobody's named yet.

Then we surface the real criteria. What makes a good decision here? Impact vs effort, sure. But also: strategic fit, risk tolerance, team capacity, timeline constraints.

Silent voting reveals where consensus already exists (often more than you think).

The part most people miss: We don't just make the decision. We build the framework for how you made it. So next time, team applies it themselves.

You Walk Out With

• The decision. Made. Documented. Everyone aligned on the rationale.
• Action plan with owners. Who's doing what. By when. How you'll communicate this to the rest of the company.
• The decision framework. Criteria. Weighting. Evaluation process. Documented so you can use it again.
• 30-day follow-up call to ensure implementation and refine framework based on what you learned.

Pick This If

• ONE specific choice stuck (not many competing priorities)
• You know what needs deciding, just can't align on the answer
• Deadline forcing resolution (board meeting, launch date, contract expiring)
• Everyone has valid points — that's why you're stuck

Not a Fit If

• Decision obvious, just need buy-in (different session)
• Data doesn't exist yet (get data first, then call us)
• More than 12 people need voice in decision

Pattern We See Often

Team says: ‘Handoffs are unclear between PM and engineering.’

Five whys deeper: PM thinks strategically (big picture, 3 steps ahead). Engineers think analytically (need specifics first, edge cases).

That's not bad communication. That's mismatched wiring. PM's handoff includes strategic context but not enough specifics. Engineer's questions feel pedantic to PM. Cycle repeats.

Solution isn't ‘communicate better.’ Solution is redesign handoff for how they each think.

One retro found the pattern. Fixed the system. Issue gone.

How This Works

We don't start with ‘what went well.’ We start with: What keeps happening?

Silent writing first. Everyone writes recurring issues. Then cluster. Usually 2–3 real patterns emerge from the noise.

Pick one. Dig to root. Five whys. Not stopping at ‘communication’ — that's a symptom. Keep going until we hit the actual cause.

Map team wiring. How does this pattern relate to how people naturally think?

Design 2–3 concrete fixes. Not vague aspirations. Specific system changes matched to how your team works.

You Leave With

• The real pattern identified. Not ‘communication issues’ — the actual root cause.
• Two to three concrete changes. Specific. Testable. Owners assigned.
• Team bought in because they found the pattern themselves. You facilitated, they discovered.
• Bonus: The deeper retro format documented. Team can run it themselves next time issues surface.

Pick This If

• Same issues every sprint
• Current retros feel performative — team going through motions
• Need one retro that goes deep enough to actually change the pattern

This is Diagnosis, Not Therapy

• 2 hours to find pattern + design fixes
• Team implements the changes
• Not ongoing facilitation of every retro

Last Month's Translation

Strategy: ‘Move upmarket to enterprise.’

Team's questions: Do we still support small teams? What about current SMB customers? Feature X is critical for SMB, do we finish it? Sales wants enterprise features, which ones?

After translation session:

• START: SSO, advanced permissions, audit logs
• STOP: New features optimized for small teams
• CONTINUE: Support existing SMB customers, no new acquisition
• Feature X: Finish current sprint, then pause

Monday morning: Team knew exactly what to do differently.

The Translation Process

We start by decoding. What does ‘focus on enterprise’ mean? Not in theory. In practice. What's changing vs staying same?

Surface all the questions. Team's assumptions. Confusion points. ‘Does this mean…’ questions all on table.

Then translate to clear start/stop/continue. Specific. Actionable. ‘Start building SSO’ not ‘focus on enterprise.’

Build decision filter. When new request comes: How do we evaluate it against this strategy? Clear yes/no criteria.

Communication plan. How we explain this to stakeholders who'll push back.

You Leave With

• Strategy translated into clear start/stop/continue for your team. Not abstract. Specific actions.
• Decision filter. When stakeholder requests feature tomorrow, you evaluate it: Does this serve the strategy? Clear answer.
• Communication talking points. How to explain why you're saying no to certain requests now.
• Surprise: Most teams discover 2–3 projects they can kill immediately. Frees up capacity for new strategic work.

Pick This If

• Leadership ALREADY decided strategy (not helping you decide)
• Team needs to understand implications for their work
• Gap between strategy and execution
• Before quarterly kickoff (right after strategy rollout)

Different from Priority Reset

• Strategy Clarity = Translate leadership's decision
• Priority Reset = Team MAKES the prioritization decision