Making direction legible to the team

I have seen this happen in engineering teams many times. A leader walks me through their team's direction with confidence. The deck is good and the OKRs are written. Two weeks later I pull a senior engineer aside and ask what the team is optimising for. They give me something close to what the leader said, but not quite the same. The phrasing has drifted and the trade-offs are missing. A junior on the same team gives me a third version. None of them are wrong, exactly; they are operating on different versions of the strategy.

Most leaders I talk to treat this as a communication problem. Distil, repeat, visualise, name the why. That advice is correct, but it is not the bottleneck. The team ends up with a different version than the leader has, and saying it louder will not close the gap. You have to fix the structure: write the direction so the team can use it, and stop the rest of the system from contradicting it.

What follows are seven practices I keep coming back to. They are not glamorous, but they are the work that makes the all-hands deck honest.

Translate the cascade in the team's currency

Org direction comes down in org currency. ARPU, runway extension, weekly active teams. Cascade it unchanged and you produce two problems at once. The team cannot act on the number because it does not refer to anything they actually work on. Leadership cannot check whether the direction reached the team, because there is no team-level version sitting alongside the org one.

Write the team version yourself before any cascade meeting, in the team's own units, and publish both side by side. If the org goal is doubling weekly active teams, the platform team's version might be "percent of new signups who complete a meaningful action within fourteen days". Show the math that connects them. Now when an engineer needs to choose between two projects, they can test each one against the team-level number. Between reducing signup friction and shipping a partner integration, only one moves the metric, and the choice becomes obvious.

This sounds obvious, but it rarely happens. When I see engineers stuck between two plausible projects, I usually find the missing translation layer first.

Push direction down to the individual

The team-level version is easier to write than the individual-level version, which is exactly the trap. Every report, even a junior who joined six months ago, should be able to finish the sentence "the team is doing X, which means I am responsible for Y" without prompting from me.

If they cannot, two things follow. The juniors treat themselves as task-takers waiting for tickets. The seniors pick up their own work plus everything no one else owns, and burn out doing it. The team looks productive in the standup. No one proposes anything beyond their tickets.

When the individual version is missing, the sign is clear: a strong junior ships well for six months and never once proposes a feature. They understand the team's general direction, but no one has translated it for them personally. Have a mid-tenure conversation. This is not a hiring or performance problem.

Put the trade-offs inside the artifact

Most strategy docs say what the team is doing. Fewer say what it is not doing, and almost none say what cost the team is accepting in exchange.

Skip any of the three and the direction is incomplete. "We are focused on self-serve onboarding this quarter, which means custom prospect-specific work is deferred, and the cost we accept is potentially losing a deal we would otherwise win." That last clause is the one that makes the trade-off real. Without it, every mid-quarter ask looks equally legitimate, and the team agrees to all of them in the corridor.

The trade-off content belongs inside the same artifact as the direction, never in an appendix. Split them and the team reads the goal without the constraint, and within a week the team stops applying it.

This section only covers what the written direction itself has to contain. Refusing specific asks, under-resourcing on purpose, and drawing your own red lines each have their own essay.

Distil into thumb rules that work at every altitude

OKRs name the numeric target, but they are not a decision filter. Between OKR cycles the team makes a hundred smaller calls a week, and the team uses thumb rules to keep those calls aligned with the direction.

The test of a thumb rule is whether it applies at three altitudes:

• Feature scoping. "We are about to build a notifications panel. Does this serve activation of new users or retention of existing ones?"
• Annual operating plan. "We are allocating thirty percent of capacity to platform work next year. Does that match the direction we narrated?"
• Team or execution change. "We are about to split the platform team in two. Does this serve the direction or just reduce coordination cost?"

If the same rule survives all three, it is a rule. If it only applies to features, it is a slogan. The Monday ticket and the reorg both have to be testable against it.

Reports can also use these rules to push back on a leader's proposal in a principled way. A report who can quote the rule back at a leader is doing the work of the direction. I once proposed splitting the platform team in two. A staff engineer pushed back in writing using one of the team's own thumb rules, and I rethought the proposal. The leader uses the rules to align the team, and the team uses the same rules to push back on the leader.

Make incentives agree with the words

This is the one most teams skip. By this point the direction is written, the trade-offs are named, and the rules are in the doc. Then half a cycle later, leaders review the team, and they end up rewarding what was visible over what served the direction. The engineer who shipped three custom features for the founder's biggest deals gets the top rating. The engineer who built the new-user activation tracking, the work that actually serves the direction, gets an average rating because the impact was hard to point to.

The team reads this in one cycle, and by the next quarter no one is touching the activation work. The strategy deck says self-serve; reviews reward custom work for individual deals. The team follows the reviews.

The remedy has two pieces. Involve reports in setting the team-level number rather than handing it down, so they own it from the start. Then align every adjacent system to the direction:

• Reviews ask what direction-aligned outcomes a person drove, alongside what they shipped.
• Promotion conversations name contribution to the direction explicitly.
• Recognition flows to direction-serving work, including the low-visibility kind.

If you cannot make the surrounding systems agree, do not bother sharpening the strategy doc. Teams trust what shows up in their review packet over what is written in the strategy deck.

Default to over-transparency on context

Withhold the reason and the team will make one up. The version they invent is almost always worse than the truth, and rarely flattering to leadership.

I once worked with a team whose company changed its growth strategy without explaining why. For three months, the team assumed the founder was chasing a trend. People showed up and shipped, but the energy was off. When the leader finally explained that the company's runway was running low, the team committed, but they carried a quiet resentment about being kept outside the room. If the leader had explained the pressure on day one, the team would not have wasted those three months.

Default to context that feels slightly excessive:

• Say the org-level reason.
• Say what you considered and rejected.
• Say which constraint is binding.

Trust that engineers can hold business context, and treat withholding as the riskier path.

Diagnose legibility on a cadence

Sending the memo is not where the work ends. The test of legibility is whether a report can explain the direction to a peer, today, without prompts.

Two places work well for this. The first is 1:1s. In your 1:1s, ask what the team is optimising for right now and what would tell us we picked wrong. Listen for drift in the answer. The second is the new-joiner ramp. A senior IC in their third week is the cleanest stranger test you have. If they cannot operate from the strategy doc alone, the doc is the problem. The joiner is not.

When you find drift, tighten the doc and fix the missing translation layer. When you find that the direction itself has changed and you have been quietly steering against the published version, that is a different topic with its own essay.

The test

These seven are the construction work. Without them, the strategy never lands.

Walk into a 1:1 with an engineer who has been on your team for six months. Ask what the team is optimising for, and what they personally are responsible for inside that. If both answers come back clean, without your prompts and without contradiction, the direction is legible. If either is missing, one of these seven is the one you have left to do.