Mix and match mental models.

A few days ago, I got to have a delightful chat with Katie Wilde, digging into a question that we’ve both found difficult to answer: what distinguishes managers perceived to have good judgment from those perceived to have bad judgment? In exploring that question, the topic of mental models came up frequently.

Mental model is a somewhat overloaded term, but roughly means having a structured view on a given topic. This structured view allows you to predict how changes will propagate across the entire problem, and allows you to rapidly prove or disprove your current perspective on a topic.

For individual contributors, whether someone develops a clear mental model is usually easiest to see in debugging complex problems. For managers, it’s usually easiest to see in evolving process. For example, most folks have a pretty explicit mental model of their interview process along these lines:

• Prospective Candidates
• Interested Candidates
• Phone Screens
• Onsites
• Offers
• Hires

If someone suggests that you need to hire more recruiters, the mental model helps you identify the right data to evaluate that suggestion. If you have very few candidates reaching Interested Candidates, then hiring more recruiters (particularly sourcers) is a good suggestion. If you have a good number of folks reaching the onsite process, then hiring more recruiters probably doesn’t make much sense.

Even if they don’t use the phrase “mental model” explicitly, it’s pretty clear when you’re interacting with someone who relies on mental models to navigate complex problems. They ask narrow, specific questions that allow them to quickly refine their view on a given problem. These sorts of questions are one of the hardest parts of presenting to executives, who will sometimes press you on seemingly random points of data while working your proposal through their own mental model.

While having a clear mental model correlates with good judgment, demonstrating good judgment requires going a bit further. To have good judgment, you have to avoid being too attached to any given mental model. If you get too attached to a mental model, then it’s easy to defend its validity even when reality disagrees.

One example of mental models that folks get caught in is sizing engineering teams. I do generally believe that teams of six to eight engineers are ideal, and I find that folks who advocate for smaller teams are often being a bit cavalier in ignoring the downsides of doing so. That said, I would never argue that there are no cases where small teams are appropriate. It might be a transitory stage until your headcount math supports a larger investment, it might be a short-lived exploratory team, etc.

Avoid getting caught in your mental model by always keeping a couple mental models handy. Run the problem through one mental model, and then run it through a second mental model. If both models agree on the problem or approach, then great. However, if they disagree, then spend time digging into why they disagree. There’s something valuable to learn there.

As an example of employing multiple mental models, I’ve been thinking a bit about headcount planning lately, particularly as it relates to infrastructure teams. Two different mental models I’ve found helpful for thinking about infrastructure engineering headcount planning are establishing a hiring ratio and documenting your organizational design. If you determine your headcount through both models, you’ll learn much more than just relying on one.