Troika Consulting: Getting Unstuck on a Problem That Never Converges

Our flaky-test channel had a thread that was, by the time I noticed it, eleven days old. Same three engineers, same theory-of-the-week, same conclusion every Friday: “still flaky, will keep looking.” Nobody was being lazy — I checked. Each of them had genuinely spent hours on it. The problem was structural, not effort-shaped: the same two people had been talking to each other the entire time, which meant they’d converged early on a shared frame (“it’s a timing issue in the queue worker”) and every new fact got bent to fit that frame instead of challenging it. Eleven days of confirmation bias dressed up as diligence.

What broke it wasn’t a debugging session. It was twenty minutes of Troika Consulting, a Liberating Structure built for exactly this shape of stuck — one person with a real problem, surrounded by peers who are barred from doing the thing peers instinctively do, which is take over.

What it is and how it runs

Troika Consulting is Liberating Structures’ peer-coaching format, designed by Fisher Qua, and it works in trios. One person is the client — they have the actual problem. The other two are consultants. Groups of three-plus-three or four-plus-four run in parallel across a room; there’s no plenary needed until the very end, which is part of why it’s fast even with a big group.

The sequence, timed tightly (5 rounds, roughly 25-30 minutes total):

1. The client states the problem and their question — one to two minutes, no back-and-forth yet. The consultants aren’t allowed to respond, only to ask brief clarifying questions if the problem is genuinely unclear.
2. Consultants ask clarifying questions — a strict couple of minutes. Not “have you tried X” disguised as a question. Actual information-gathering.
3. The client turns their back or looks away — physically, if the room allows it — while the consultants talk about the client as if they’re not there. This is the structural trick that makes the whole thing work: with the client silent and half-turned-away, the consultants stop pitching solutions at someone and start genuinely brainstorming with each other, which produces braver, weirder ideas than they’d ever say to the client’s face.
4. The client turns back and reports what landed, what they’re taking, what didn’t fit.
5. Roles rotate and the next person becomes the client.

The facilitator’s only real job is holding the clock. Five minutes over budget on round three and the format collapses back into a normal conversation, which is exactly what it’s designed to prevent.

Running it on a flaky-test triage that won’t converge

I pulled three people out of that eleven-day thread — the two who’d been circling each other, plus a third engineer who’d been peripherally aware of the bug but hadn’t touched it. That third person turned out to be the whole point.

Round one, one of the original two was client: “Our checkout E2E test fails about 1 in 6 runs, always in CI, never locally, and I don’t know if it’s the test or the app.” Clarifying questions surfaced something neither of them had said out loud in eleven days of Slack: it only failed on the second test in a given CI run, never the first. That fact had been sitting in the CI logs the whole time; it just hadn’t been said aloud to someone outside the frame.

Round three, backs turned, the outside engineer floated something the two insiders hadn’t considered because they’d been fixated on the app’s queue worker: shared state between test runs — a seeded record or a leftover browser session — surviving from test one into test two. Not a groundbreaking insight on its own, but it was a different hypothesis, generated by someone whose thinking hadn’t been shaped by eleven days inside the old frame. The client, listening in, said afterward that hearing it discussed rather than pitched made it easier to actually consider — nobody was selling it to her, so she wasn’t triggered to defend her own theory.

Round four, roles rotated and the outside engineer became client with their own smaller question about CI flake rate reporting — and got useful pushback on a metric they’d been quietly assuming was solid.

Twenty-five minutes, three rotations, and the checkout test bug turned out to be exactly the shared-state theory: a Postgres transaction from a previous test wasn’t rolling back cleanly under parallel CI workers. It took another day to actually fix. But the eleven-day stall — the part that wasn’t really a technical problem — ended in one structured half-hour, because the format forced a fresh person into the loop and forced the two insiders to stop pitching and start genuinely thinking out loud.

Why the “talk about them, not to them” step matters

It’s the part every group resists on first read and the part that does the real work. When consultants address the client directly, two things happen automatically: the client starts defending or explaining instead of listening, and the consultants — reading the client’s face for approval — self-censor toward safe, obvious suggestions. Turn the client away and address each other instead, and both effects vanish. Consultants say the odd idea because they’re only risking it in front of a peer, not the person who owns the problem. And the client, freed from having to respond in real time, actually processes what’s said instead of preparing a rebuttal.

For an engineering team specifically, this maps onto a failure mode that’s endemic to bug triage: the two or three people closest to a stubborn bug develop a shared, unexamined frame, and every subsequent conversation just adds detail to that frame rather than questioning it. Troika Consulting’s forced rotation guarantees at least one voice per round hasn’t been marinating in that frame.

When to skip it

Troika Consulting needs a real, specific, personally-owned question — “how do I get unstuck on this” — not a diffuse team problem like “our test suite is too slow,” which has no single client and dissolves the structure’s whole premise. If the room can’t name one person whose problem it actually is, use a different structure (Wicked Questions or a straightforward retro works better for shared, ownerless problems).

It also assumes psychological safety most teams have to build deliberately. If the client can’t tolerate being talked about, even briefly and kindly, in the third person, the format reads as ambush rather than help. I’ve seen it land badly exactly once — a newer engineer who hadn’t done it before found the “turn your back” step humiliating rather than freeing. Explain the mechanic before round one, every time, and give a genuine opt-out. And don’t run it on a problem that’s actually a management or interpersonal issue in disguise — Troika Consulting solves technical and process stuckness; it isn’t built to mediate a conflict between two people in the room, and using it that way tends to make the unspoken tension worse, not better.