Effectiveness and certaintythe same dayI’ve been thinking about the limits to seeing, and this diagram popped…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.

Build a thing to build the thing2023When building new products, there’s always a weird tension between making something…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?”

Separating cargo from the train2023I’ve been puzzling over a problem that many engineering teams face and…Correlated compounding loopsfive days afterA thing that became a bit more visible for me is this…Hosting and hosted API design perspectiveslinks here, 2021It is also important to note that, using Hamilton Helmer’s classification, the…Lenses, framings, and modelslinks here, 2022Finally, models are networks of causal relationships that form within my framings.…Objects in vision are farther than they appearlinks here, 2022Especially in environments where there’s pressure to show results quickly, the distortion…Moving the ladderlinks here, 2022Getting back to our notion of settled and transient opinions, I hope…The Plumber Agelinks here, 2022Some organizations try to reject the Plumber Age, and attempt to skirt…One miracle at a timelinks here, 20231️⃣ Start with the inventory of miracles. Have a rigorous miracle count…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.