Fermi Thinking

As members of product and engineering teams, we will face many problems throughout our careers that have a great deal of complexity, ambiguity, and unknowns. At first glance, we may feel daunted and struggle to find a starting point that will help us find our way to a solution. I'd like to share an approach I’ve applied throughout my career that has helped in many scenarios.

My engineering professor asked us a seemingly irrelevant question on the first day of class: “How many barbers are there in Boulder, Colorado?” Each of us sitting in that brick-walled classroom furrowed our brows trying to understand how this applied to his course, or how the answer may help us navigate life outside the basement of the engineering building.

We then started working out the problem by asking questions while the professor chalked them up on the board, and we’d answer the ones we could. What is the population of Boulder? About 80,000 at the time. How many people go to barbers and at what frequency? We assumed it would be men, that men make up about 50% of the population and likely they get a haircut every three weeks. Even considering the city was known for its hippie nature, these estimates felt right. How many barbers would need to work each day to serve these 40,000 male clients? Other questions and thoughts started pouring out: How long do haircuts take? Maybe that varies for a fancy salon versus a local discount barber. What about barbers taking days off? Do more people get haircuts on the weekend than weekdays?

Each question leads us closer to a rough answer. And some questions we had relatively accurate answers on hand. For example, the population of Boulder was something many of us in that classroom knew within proximity, helping us corroborate estimates and starting us off with our first reasonably accurate variable. Some questions were estimates that we wouldn’t be able to answer without a survey, like the average frequency of haircuts, but the point wasn’t necessarily getting a perfect answer, it was to get us an approximation. Other questions like the type of shop that was servicing customers would take more effort to estimate, and wouldn’t have as much impact on our calculation.

This approach to problem solving is associated with Enrico Fermi, a WW2-era physicist who is described as the architect of the nuclear age. The principle is to take an ambiguous problem that is full of uncertainty and break it into subproblems that are often further divisible. As we break them down into their manageable components, we can quickly approximate solutions for these smaller problems or identify components that can likely be ignored without affecting the overall approximation. In a majority of cases, the resulting solution gives us a sufficient idea of the size and components of the larger problem. As humans, operating in ambiguity is often challenging, so having a boundary around a problem is a helpful and an effective way of reducing anxiety that complex problems bring, and increasing our comfort and certainty around the path to a solution.

In software development, grooming the backlog to assign story points or t-shirt sizing epics are places where we commonly utilize this pattern of Fermi thinking. As each engineer calculates their point estimate, they are quickly visualizing how they would solve this problem. Filtering the knowns and considering the unknowns. Sometimes the uncertainty warrants a conversation where the team can quickly work the problem with their disparate knowledge and perspectives, or determine the uncertainty is too high to confidently estimate and the story requires more research before giving a sufficiently confident estimate.

Let’s play this out with a feature that requires integration to an external API that nobody on the team has interfaced with in the past. It’s likely engineers on the team have integrated with other APIs and they know that things like authentication, rate limits, error handling, retry logic, and other such subproblems will need to be solved. Other external APIs may have already been integrated into the application, and product or engineering folks that are present may be able to speak to the existing infrastructure, code abstractions, or design patterns that may or may not have already been solved. It’s also important to consider more practically if the API is well documented? Are test credentials/environments easily available? Will there be support for unexpected issues? Within a few minutes of conversation, the team can quickly approximate the size of the overall problem which will get the product folks the information necessary to make business decisions, and to prioritize work.

Fermi thinking lets us move fast individually and collectively. Sometimes the estimates will be spot-on and other times they will miss the mark, but with time and practice, we will improve our estimation skills, taking less and less time to quickly arrive at estimations that come very close to the actual answer.