Setting Clearer Expectations: The Compass vs. Map Method

A quick technique to help set your teams up for success: are you giving your team a compass or a map?

Managers often provide too little detail when setting expectations. This is the compass method. Let’s say you’re in Italy. You tell your team to head north. They may end up in Switzerland, Lichtenstein, or Austria. They might also keep travelling and end up in Germany, or somewhere in the Arctic Circle. The compass method is just a direction, without a lot of constraints.

Managers sometimes prefer this method of expectation setting because it feels less “micromanage-y.” A clear direction should be enough to get your team where they need to go, but it’s not specific enough to inhibit their own creativity. It also doesn’t tell them how to get there — whether it’s by air, road, or sea.

The map method provides more constraints. Here, I’d give my team a map and tell them “travel north from Rome, via Berlin, and stop in Denmark.” I’m telling them the direction, but I’m also giving important constraints: an intermediate waypoint, the minimum result I’m looking for (just over the border in Denmark) to the maximum result (leaving Denmark). There’s less room for interpretation in what to do, but it’s also less likely that the team doesn’t hit my expectation.

Using the map method is challenging: you need to know what your lower threshold is. Leaders and managers are routinely pretty crappy at this, because we often don’t have the time (or take the time) to clearly define what we want to see. “I’ll know it when I see it” or “it’s their job to figure it out” are not great ways of approaching clear expectation setting. If you don’t know what you want, how can you expect your team to deliver it?

Real life map vs. compass example

Scenario: your team of engineers works closely with a product manager and the customer success team on big launches.

Compass: “If the project scope changes, the whole project team needs to be informed.”

Map: “If there are material changes to the UI or UX because of technical constraints, the whole project team needs to be informed before those changes are deployed — including PMs and customer success. It’s not enough to just mention them in your PR. We need to discuss it in Slack, and have these discussions as early as possible in case we need to change something.”

You know your team the best. Setting a direction, like in the compass example, might be enough for your team. But don’t count on it: I’ve spent hundreds of hours coaching engineering leaders, and even for very senior teams, people often need more direction than we think they do. Specifically, the key piece of information that helps teams succeed is “what’s not enough.” We get this in the map method, by sharing the minimum result, or by sharing an anti-pattern that may cause the team to think they’re doing fine (i.e. sharing the UX changes in a GitHub PR) but that actually misses the expectation that you have (sharing UX changes early and in Slack so everyone can see them, including non-engineering team members).

Remember that your team can’t read your mind.