Aligning engineering with strategy: negotiated, not announced
You presented the strategy, everyone agreed, and the roadmap looks the way it did before. Explaining it again will not change that, because your teams already know something the plan does not, and no one has asked them yet. This page has the six questions that surface that knowledge before the planning cycle, and the response record that tells each team what happened to what they said, both free to copy. The worked example at the bottom is one platform team getting its knowledge onto the table, and a plan changing because of it.
Alignment is not a communication problem
The instinct when a strategy is not landing is to communicate it again. Another all-hands, a clearer deck, a written memo. Teams then repeat the strategy accurately and keep working much as before, which gets read as the message still not having got through. It got through. Awareness was never the missing piece.
The missing piece sits earlier, in how the plan was made. The people closest to the work hold information the decision needed, and most planning cycles have no route for any of it to arrive while the decision is still open.
Leadership still decides, and should. They hold context the teams do not: runway, commitments already made, where the company is going next. But a decision improves when both sides put their information on the table first, and the agreement that comes out the other side is the alignment.
A team that helped shape the strategy does not need it explained.
Six questions that surface what the teams know
Ask before the planning cycle, not after it. These only work while the answers can still change a decision; run them once the plan is set and the answers can no longer change anything.
- What are we likely to be asked to do next quarter that you already know will not work? The load-bearing question. Teams usually know this months ahead and usually assume someone senior knows it too. Whether anyone says it upward at all is psychological safety.
- Which dependency worries you that nobody outside this team is tracking? Cross-team dependencies are visible from inside a team and close to invisible from above. This is knowledge the planning conversation does not otherwise have.
- What keeps coming back from customers that never reaches a plan? Support patterns, sales objections, the same question in every onboarding call. Teams accumulate this and it rarely reaches anyone who plans. Getting customer evidence into the plan on purpose is dual-track discovery.
- What could this team do that leadership does not know is possible? Teams get asked about risk constantly and about capability almost never. Some of the best strategic options in a company are sitting unmentioned in an engineering team.
- Where are we spending effort you believe produces nothing? Naming it is a strategy input, not a complaint. Only leadership can authorise stopping something, so it has to reach them. If nobody can say what the effort was for in the first place, start with output vs outcome.
- What would you need in order to commit to an ambitious version of this? Turns a flat no into a negotiation. The answer is usually specific and often cheaper than the alternative plan.
The response record: your answer back to the teams
The questions above collect what your teams know. The response record is the second half: a short written answer back to each team, showing that leadership actually weighed what they said. One row per input: what was decided, the reasoning, and what changed in the plan. This is what makes it safe to keep contributing. Teams that get an answer keep talking; teams that hear nothing conclude that contributing changes nothing, and the next round of answers comes back thinner. Almost everyone runs the questions and skips this half.
- The input, in the team’s words Not summarised into management language. The wording is the evidence, and rewriting it is how the substance goes missing.
- Who raised it So the response goes back to a person rather than into a channel. Named inputs get answered; anonymous ones get filed.
- The decision: adopted, adapted, or declined All three are legitimate. What matters is that a decision exists and is written down, rather than the input going quiet.
- The reasoning, especially when declined A team that hears "we considered it and chose otherwise, here is why" can argue with the reasoning or accept it. Silence gives them nothing to do either way.
- What changed in the plan Concrete, or explicitly nothing. This is the field that proves the exercise was real, and the one that is uncomfortable to leave empty twice in a row.
- Who takes the answer back One named person and a date. Without both, the answer stays in the planning document and the team never hears it.
Declining most of what comes back is a perfectly good outcome. A strategy that adopts every input is not a strategy.
How do you align engineering teams with business goals?
By involving them while the goals are still being set, rather than explaining the goals better afterwards. The teams closest to the work hold information the strategy needs: which bets are undeliverable, which dependencies will bite, what customers keep asking for. Collect that before the planning cycle, decide with it in the room, and tell each team what happened to their input. Alignment is what is left over from that conversation.
Should engineering teams influence strategy, or just execute it?
Influence it. Leadership still decides, and should, because they hold context teams do not have: runway, commitments already made, where the company is going next. But a decision made without what the teams know is a decision made with a missing input. The useful model is negotiation between two informed parties, not consultation that collects opinions and files them.
What is strategic alignment in engineering?
A team is strategically aligned when it has understood the strategy and applied it to its work: what the team builds and prioritizes has actually changed, so that its output moves the company toward the strategic objectives. Reciting the strategy is not alignment; a changed roadmap is. This page is about the most reliable way to get there: teams apply a strategy they helped shape, and one that was only announced to them stays a slide. In Aurora Coach, Alignment is one of six domains of team effectiveness.
From what a team knows to a changed plan: a worked example
Simulated team · Real product output Negotiation is easier to show than to describe. The team below is Aldermark Mutual, a fictional mutual insurer: 850 people, 140 of them in technology. Keystone is its platform team, seven engineers running the internal developer platform for fourteen product teams. The engineering strategy was presented five months ago and has not changed a roadmap item since; the improvements promised along the way went the same direction. We scripted the inputs and ran them through Aurora Coach in production. Everything below is the product's real output.
1Sense and analyze
Everyone on the team answers structured questions in their own words, and can take any thread further in a check-in conversation. Answers arrive per team, not as one org-wide average that flattens the team with the objection worth hearing.
Alignment, or just awareness?
The team lead can recite the strategy and cannot name one roadmap item it changed. The coach names three things that would prove the plan actually listens to the teams, then reads the current state back: “input goes in, nothing comes back out. That's not a feedback loop, that's a suggestion box.” It ends on the question the lead has to take upward: who owns the gap between what the team knows and what the roadmap says.
2Recommend, refine, commit
Push back on anything too abstract to use and the coach gets concrete. Recommendations then become suggestions the team votes on and commits to, and the AI informs the decision rather than making it.
A route, with a return path
A senior engineer opens with the diagnosis this whole page rests on: “Two well-run processes that never touch. Which one is wrong?” Neither, says the coach; what is missing is the translation layer between them. Pushed to be concrete for seven people serving fourteen teams, the answer has three parts: one question added to the planning cycle the team already runs, a 30-minute monthly sync, and a written response from the strategy owner within a week saying “what they heard, what it changes or doesn't change, and why.” That is the response record above, arrived at from the other direction.
What the team knows, made visible to the plan
The suggestion the analysis tagged Alignment, implementation details open: a dependency visualization board, every cross-team dependency with its owner, status, and predicted delivery date. The Context field argues from this team's own number, dependency predictability at 2 of 5 and the cascading planning failures it causes. That is the “which dependencies will bite” knowledge from the questions above, turned into something the strategy owners can read before the next planning cycle instead of after the slip. Five action steps take it from a 30-minute team session to a baselined predictability score. The thumbs are the team's vote, and Commit turns it into a tracked improvement.
3Execute and re-evaluate
The team does the work alongside delivery, and the next period's analysis shows whether the agreement held under pressure. Alignment is easy in a planning week and hard in week seven. Keystone has run one period; the trend starts when the second one lands.
This is one use case. How the full product works is on the product overview.
Not ready to change anything today? You already have the questions and the response record above, copy buttons and all. If you want one improvement loop like these in your inbox each month, leave your email.
What this page cannot tell you is which of it applies to your team, this quarter. Aurora Coach works that out from your team's own words, recommends next steps with the reasoning, and the next period shows whether it held.
Both are free. The ROI mapper needs no signup and takes about two minutes. What team members write stays private to them: see AI governance.