Recently, my team was discussing our team mission, strategy, etc. and the question arose whether we should write down our team’s values. My teammate George was skeptical: in reality, when your back is up against it, won’t the decisions you make be based on whatever it takes for your team to survive, rather than some high-minded set of written values? My response was, “What if you replaced our whole team with a brand new set of people and gave them the same mission? Would they make the same decisions we do? If not, doesn’t that say that our values are something distinct from our mission?” You could see the light bulb go off in his head, and he immediately said yes, we should write down our team’s values.
After the meeting, George pointed out that this is a strength of mine: to put an idea into such a clear perspective that what was once a confusing and controversial idea becomes clear and easy to come to consensus on.
This is a skill I picked up in grad school, but I can’t say I learned it explicitly. It was just something that senior folks in the department did, and the rest of us picked it up slowly through osmosis. We gradually learned that being able to put your finger on an important part of a problem was a kind of superpower, and could accelerate progress towards key insights. I distinctly remember when one of the senior professors in the department (Mitch Wand) told me I had asked a really good question during a research talk and I realized I had picked up this superpower too.
On reflecting what this skill even is, I think it’s this: I clarify meaning through Venn-diagram thinking and concrete scenarios.
Let me explain with an example. Suppose I’m a software engineer in a meeting with my team, and the tech lead says “From here out, our focus is on reliability”. Immediately my internal ambiguity alarm starts firing: this is a vague statement and can mean very different things to different people. Should we drop any and all work that is not reliability-focused? Or should we adjust our ratio of work so that, say, 75% of our work is on reliability but we still leave 25% for new features?
I think of these various interpretations as overlapping sets in a Venn diagram (see figure 1): in many situations, the decision is the same (either way, at least 75% of the work is on reliability), but not always.
So the goal is to figure out which of these overlapping sets they’re referring to: A or B. And the way I do that is to think of a concrete scenario that’s in A, but not in B (see figure 2). So in this situation I might ask the tech lead, “Focusing on reliability can mean a lot of different things. For example, that new feature the product manager just asked for is a top priority request from one of our largest customers, but it has nothing to do with reliability. Are we still going to work on it?”. Once I’ve put my finger on a concrete example of the ambiguity in the statement “our focus is on reliability”, the conversation usually moves on to a productive discussion of what is really meant, so that the whole team ends up sharing the same interpretation.
Once I learned how to apply this skill, I started to see in how many situations it applies: defining team priorities, writing a mission statement, explaining the overarching philosophy in a design, assigning ownership of project components, and more.
A key part of the skill is to detect that there’s some ambiguous meaning to clarify in the first place. Unfortunately, I don’t have any better advice other than to apply the above method in your head as you’re listening to someone describe an idea and determine if something seems missing. See if there are concrete scenarios where a statement might have multiple interpretations, and if so, try to tease out which one is meant.
Even though it wasn’t the direct goal of my PhD, this technique was one of the most important skills I picked up in grad school. But no one ever sat down and explained it to me, so it took a long time to learn. I hope by laying out the process I follow helps others pick up the idea faster. I really do believe this is a big point of leverage for senior folks in tech, so hopefully it’s useful to many of you out there.