Making direction legible to the team

A leader walks me through their team's direction with confidence, the deck is good and the OKRs are written, and two weeks later I pull a senior engineer aside and ask what the team is optimising for. What comes back is close to what the leader said but not quite it: 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, and I have watched this exact sequence on many engineering teams.

Most leaders I talk to treat this as a communication problem and reach for the standard tools: distil the message, repeat it, make it visual, name the why. That advice is correct, but it is not the bottleneck. The team holds a different version than the leader does, and saying the leader's version louder does not touch that. You close the gap structurally: write the direction so the team can use it, then stop the rest of the system from contradicting it.

I keep coming back to seven practices for this. None of them are glamorous, and together they are the construction 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 work on, and 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 an engineer choosing between two projects 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 too obvious to need writing down, and it rarely happens. When I find engineers stuck between two plausible projects, the translation layer is the first thing I go looking for, and it is missing more often than not.

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 settle into being task-takers waiting for tickets, since tickets are the only version of the direction anyone has translated for them, while the seniors pick up their own work plus everything nobody else owns and burn out doing it. The team looks productive in the standup the whole time, and nobody proposes anything beyond their tickets.

You can spot the missing individual version from a distance: a strong junior ships well for six months and never once proposes a feature. They understand the team's general direction, but nobody has translated it for them personally. That is worth a mid-tenure conversation, and it 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 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, because agreeing in the corridor costs nothing today and the bill only arrives at the end of the quarter.

The trade-off content belongs in the same artifact as the direction rather than 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 nobody consults an OKR while scoping a Tuesday ticket. Between cycles the team makes a hundred smaller calls a week, and thumb rules keep those calls aligned with the direction.

My test for 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 doing its job; if it only applies to features, you have written a slogan, and the Monday ticket and the reorg both need something they can be tested against.

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

Make incentives agree with the words

This is the step most teams skip. By this point the direction is written, the trade-offs are named, and the rules are in the doc, and then half a cycle later the leaders sit down to review the team and end up rewarding what was visible over what served the direction, because visible work is cheap to evaluate and direction-serving work has to be traced. 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 the direction asked for, 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, which is not cynicism so much as engineers reading their environment correctly. The strategy deck says self-serve while the reviews reward custom work for individual deals, and the team follows the reviews.

You repair this in two moves. Involve reports in setting the team-level number rather than handing it down, so they own it from the start, and 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 behind a direction and the team will make one up, and 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, those three months would not have been wasted.

Default to context that feels slightly excessive:

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

Engineers can hold business context, and the riskier path is withholding it.

Diagnose legibility on a cadence

Sending the memo does not end the work. The direction is legible when a report can explain it to a peer, today, without prompts.

Two places work well for checking. The first is 1:1s: ask what the team is optimising for right now and what would tell us we picked wrong, then listen for drift in the answer. The second is the new-joiner ramp, because a senior IC in their third week is the cleanest stranger test you have; if they cannot operate from the strategy doc alone, the problem is the doc rather than the joiner.

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 problem with its own essay.

The test

Walk into a 1:1 with an engineer who has been on the team for six months and ask two questions: what is the team optimising for, and what are they personally responsible for inside that. If both answers come back clean, without prompting and without contradicting each other, the direction is legible and the 1:1 can move on to better uses. If either answer is missing, one of the seven above is the one you have left to do.