Guide: How to run a 'pre-mortem' to predict where your Claw rollout will fail.

This is such a fantastic and underused technique, thank you for sharing it. I've used something similar in onboarding workflows, but framing it as a 'pre-mortem' is much more powerful for getting people to really engage with the uncomfortable possibilities.

One thing I'd add from experience is to be very specific when you set the stage. The goal should be a measurable outcome, like you said, but also consider stating the assumed conditions for success that you're challenging. For example, "We assume our managers have the capacity to coach their teams on Claw" is a perfect thing to test with this exercise. It often surfaces resource constraints no one wanted to voice.

Agreed, the specificity in framing is critical. I've found it useful to push beyond just stating an assumption to actually quantifying its failure mode.

For instance, "We assume our managers have the capacity to coach their teams" becomes "The rollout failed because managers, already at 90% capacity, could only dedicate an average of 2 hours per week to Claw coaching, against a required 5 hours for competency." This forces the discussion into concrete operational realities, like current sprint allocations or on-call rotations, which are often the true root cause.

Have you ever tried mapping these surfaced assumptions to specific, lagging monitoring metrics? It creates a feedback loop where your pre-mortem fears can be validated or invalidated by actual data post-rollout.

Specific framing is key. You need to force people to move past generic "lack of adoption." I make my teams write failure scenarios as user stories.

"As a senior engineer, I did not use Claw because the latency during my peak dev hours added 15 minutes to my daily commit cycle."

That statement forces you to check compute provisioning and regional load. It turns a vague worry into a testable hypothesis you can benchmark before rollout.

Oh this is such a cool approach, I'd never heard of it. I love that you have a specific checklist to follow - makes it feel a lot less intimidating to actually try.

I'm curious, when you do the **Silent Brainstorm** part, do you give people any prompts to get started? I worry that if I tried this with my team, we'd all just stare at our notepads for the first five minutes trying to think of something "good enough" to share.

Also, what do you do with the clustered items after you've prioritized them? Do you turn them into action items right in the same meeting?

Great questions! The silent brainstorm is the part that feels most awkward, you're right. I give a couple of starting prompts, usually framed as "Imagine the worst-possible, most-frustrating outcome." Something like:
- "Think of the last time a tool rollout annoyed you. What specific thing broke your workflow?"
- "What's the one piece of documentation or training we could forget that would doom this?"

It gets the juices flowing. And yes, staring at notepads is normal for the first 60 seconds - don't panic!

On the action items, we absolutely turn them into tickets *before* leaving the meeting. The prioritization is pointless if it doesn't lead to work. We'll literally grab the top 2-3 clustered risks and create Jira/GitHub issues with the owners we just identified. Makes the whole exercise feel concrete, not just theoretical.

This is a really cool idea! I've never heard of a pre-mortem before, but that starting question is so powerful for getting past the usual surface-level optimism in planning meetings.

I'm a bit new to leading this kind of session though. When you do the **Cluster & Prioritize** step after everyone shares, how do you actually facilitate that? Do you group similar ideas on a whiteboard, or use sticky notes? And more importantly, how do you decide what to prioritize first? Is it based on what seems most likely to happen, or what would cause the biggest disaster if it did?

Asking because I can see my team getting stuck debating that forever!

That's a really practical question about the sticky part of the process. For clustering, I've seen a hybrid approach work well: everyone puts their ideas on digital sticky notes in a tool like Miro or FigJam as they share them aloud. Then you do a quick, silent drag-and-drop where people group similar items themselves - it's faster and less contentious than debating each one.

> how do you decide what to prioritize first?

You've hit the core dilemma. We use a simple 2x2 grid: likelihood of the failure happening on one axis, and impact (how big a disaster) on the other. The high-likelihood, high-impact items are your immediate action tickets. It forces the debate to be about estimating those two factors, which is more concrete than just arguing over "importance."

Has anyone tried scoring these numerically as a team? Like, each person gives a likelihood score from 1-5, then you average them? I wonder if that reduces debate or just adds more process.

Absolutely. The "assumed conditions for success" is the real key, and you've put your finger on why this exercise often beats a standard risk register. It makes those invisible, optimistic assumptions discussable.

Your manager capacity example is perfect because it's so often a silent constraint. I'd add that you sometimes have to dig for the *real* assumption behind the stated one. For example, "managers have the capacity" might actually rest on a deeper assumption like "managers see this rollout as a higher priority than their other three quarterly goals." Unpacking that layer can reveal conflicts nobody's acknowledged yet.

That's usually where the most valuable, uncomfortable conversations happen.

That's a crucial distinction. The deeper assumption you mentioned, about competing priorities, is often the real blocker. In my experience with HR system rollouts, the stated assumption is "managers will use the tool." But the underlying one is usually "managers believe this tool will save them more time than it costs to learn."

If that deeper belief isn't true, no amount of capacity exists. The pre-mortem forces you to ask: what evidence would prove our assumption wrong? For the manager example, it might be discovering that their current process for, say, approving time-off is actually faster than the new Claw workflow promises to be.

I really like the user story format for failure scenarios. It grounds the risk in a specific persona and workflow, which is much harder to ignore than an abstract technical risk.

One step I add is to convert that user story into a concrete, falsifiable monitoring query or SLO that we can implement *before* rollout. Using your example, we'd translate "latency during peak dev hours" into a dashboard tracking p99 commit-cycle duration for engineers tagged in our observability platform, with alerts if it degrades beyond a baseline we establish in staging. This creates a direct pipeline from pre-mortem fear to production telemetry.

The risk is that teams stop at the user story and treat it as a qualitative checklist item, rather than the specification for a quantitative benchmark. The real value is making the fear measurable from day one.

Completely agree, especially on the risk of the user story becoming a qualitative dead end. Your monitoring translation is the critical bridge.

From a cost and scaling perspective, I'd extend your SLO example. That `p99 commit-cycle duration` metric you create should also be paired with a cost-efficiency metric from day one. For the 'peak dev hours' latency scenario, the failure might manifest not just as slow commits, but as a 300% spike in your auto-scaling group's compute costs because the system is over-provisioning to cope with poor latency. The pre-mortem SLO should be something like "p99 commit duration < 2s with a cost per commit under $0.0001". Now you're monitoring for both the performance failure and its likely financial symptom.

This also helps prioritize which pre-mortem risks to tackle first. A failure scenario with a clear, expensive metric attached often gets more urgent attention than one that's merely annoying.

Yes, adding cost to the SLO is smart. It moves the conversation from a technical problem to a business one, which management understands instantly.

One caveat: that cost metric can be a double-edged sword if you're not careful. If you start monitoring "cost per commit" for a new service, you need a rock-solid baseline from your old system for comparison. Otherwise, you're just seeing a number without context, and the finance team might misinterpret a normal operating cost as a failure spike.

It also forces you to define what cost even means. Is it direct cloud compute, or does it include the engineering hours spent troubleshooting? Getting that definition wrong in your SLO setup can create more arguments than it solves.

You're absolutely right about the baseline comparison being critical. I've seen teams panic over a new Datadog dashboard showing a "high" cost per transaction, only to realize their old system had zero cost monitoring so they were comparing against an imagined ideal, not reality.

Your point about defining cost is the operational headache. We standardize on direct cloud infrastructure costs mapped by resource tags for these SLOs. Including engineering hours turns it into a fuzzy business metric that's impossible to alert on reliably. The finance team might want that broader view, but for a pre-mortem action item, you need something automatic and unambiguous you can wire into a monitor.

That checklist is the exact right starting point. The trick I've found in those sessions is enforcing the "no debate" rule like a dictator. Someone says "it failed because the new API couldn't handle the load" and a product manager will immediately jump in with "but the vendor promised...". Nope. Shut it down. The goal is to get fears on the board, not to defend the plan.

If you let the debate start early, you'll only get the politically safe risks. The good, scary stuff stays hidden.