The miracle count

While working on a technical design this week, my colleagues and I brushed up an old framing: the miracle count. I found it useful when considering the feasibility of projects.

Any ambitious project will likely have dependencies: a set of unsolved problems that are stringed together into a causal chain. “To ship <A>, we need <B> to work and <C> to have <metric>.” More often than not, the task of shipping such a project will be more about managing the flow of these dependencies rather than their individual effectiveness or operational excellence.

Very early in the project’s life, some of these dependencies might pop out as clearly outsized: ambitious projects in themselves. If I want to make an affordable flying saucer, the antigravity drive is a dependency, and it still needs to be invented. I call these kinds of dependencies “miracles” and their total number in the project the “miracle count.” Put it simply, the miracle count is the number of unlikely events that we need to happen for our project to succeed.

I don’t know about other environments, but in the engineering organization, having a miracle count conversation is useful. The miracle might be technological in nature (like that antigrav drive), it could be a matter of shifting priorities (“this team is already overloaded and we’re asking them to add one more thing to their list”), or any number of things. Recognizing that a dependency is a “miracle” is typically a prompt to de-risk, to have a contingency plan. “Yeah, I wonder if that generalized cache project is a miracle. What will we do if it doesn’t go through?”

Miracle-spotting can be surprisingly hard in large organizations. Each team is aiming high, yet wants to appear successful, and thus manage the appearance of their progress as a confident stride to victory. I have at least a couple of war stories where a team didn’t recognize a miracle dependency and parked their own “hacky workaround” projects — only to grasp for them suddenly (“Whew! So glad this code is still around! Who was the TL?”) when the miracle failed to materialize. I’ve also seen tech leads go to the other extreme and treat every dependency as a miracle. This inclination tends to create self-contained mega-projects, and increase their own miracle-ness. In my experience, finding that balance is hard, and usually depends on the specific constraints of a dependency — something that a robust miracle count conversation can help you determine.