Domain 3 — Strategy & Vision
Strategy & Vision is the work of connecting engineering effort to business outcomes and direction. It is the domain where engineering management stops being inward-facing (the team and its work) and becomes outward-facing (the business and its goals). This domain carries 20% of every exam (12 questions on EMA-I, 15 on EMP-II, 18 on EME-III).
The altitude arc: at Associate you translate a strategy handed to you into work one team can execute and believe in; at Professional you own a department strategy — a connecting thesis that ties several teams' work to business outcomes, defended against churn, encroachment, and capacity drains; at Expert you author the engineering strategy itself, argue it at the executive table and to the board, and keep it alive as the world changes. The throughline is reasoning about outcomes, not output: strong leaders connect every significant piece of work to why it matters to the business, communicate in the language of the listener, and make resource trade-offs explicitly. The exams favour options that tie engineering decisions to outcomes and stakeholder value over those that optimise purely for engineering preference.
3.1 Translating goals into technical direction
Strategy arrives in business language (grow revenue, reduce churn, enter a segment) and must be translated into engineering work that people can execute and reason about. Done badly, this becomes either a too-literal feature checklist with no theory of impact, or vague themes ("improve reliability") that give engineers nothing to act on.
The most useful shift is from output to outcome: frame work as the change you want in the world ("reduce involuntary churn from failed payments by 30%") rather than the thing you build ("ship the billing service"). Outcomes tell people what success looks like and free them to find a cheaper path than the one first imagined. For each goal, ask what would have to become true for it to succeed; those conditions organise the work, and when reality shifts you re-derive the work instead of clinging to a list. The test of a good translation at any altitude: pick any item on the plan and ask the person doing it why it's there. If the answer ties to a business outcome, the translation worked.
At Associate — translating for a team
The first-line version: frame the team's work as outcomes, derive features from the conditions for success, make sure every engineer can explain why their work matters, and re-derive the plan when circumstances change.
Strong judgment looks like: outcome framing; features derived from a theory of impact; a team that can articulate its "why"; plans re-derived, not defended, when the world moves.
Common pitfalls: strategy as a literal feature list; themes too abstract to act on; building things because they're on the roadmap.
At Professional — a connecting thesis for a department
The failure mode this band exists to prevent has a name: the bottom-up roadmap. When a department's plan is assembled from each team's wishes, the exec team is right that it doesn't add up to a strategy — the missing piece is a connecting thesis that ties team work to a few department-level outcomes. The fix is to define those outcomes and re-derive the roadmap from them, not to add detail to the wish list. The same logic sets the altitude of your own goals: a manager-of-managers' OKRs sit at department outcomes, not at a roll-up of team task lists — otherwise you have aggregated activity, not direction.
Translation at this altitude is mostly communication design. A strategy lands when teams can make good local decisions without asking: communicate intent, priorities, and constraints — the why and the boundaries — rather than prescribing solutions team by team. A strong department strategy deliberately does not specify exactly what every team builds for the year; it names the outcomes, the ordering, and what you are not doing. You know it isn't landing when teams can't explain how their work connects, when local decisions keep contradicting the stated direction, or when every prioritisation question still escalates to you. And when the company pivots mid-quarter and half your roadmap is suddenly irrelevant, the discipline is the same one the Associate learned, at scale: re-derive quickly from the new outcomes, kill the newly irrelevant work explicitly (don't let it limp on), and over-communicate the reasoning to the teams whose work just evaporated.
Strong judgment looks like: a department thesis a team lead can recite; OKRs at outcome altitude; strategy communicated as intent and priorities so decisions decentralise; fast, explicit re-derivation on pivots.
Common pitfalls: stapling team wish lists together and calling it strategy; OKRs that are task roll-ups; broadcasting the strategy once and assuming it landed; letting dead roadmap items keep consuming capacity after a pivot.
At Expert — strategy and organisation as one problem
At executive altitude, translation runs in both directions. Downward: the deepest version of "translating strategy" is recognising that the organisation itself is the implementation. When the company shifts from a single product to a platform strategy and your org — team topology, skills, architecture — was built for the old model, the strategy challenge is that all three must be realigned together; announcing the new strategy over the old structure just makes Conway's Law the real strategist. Upward: the executive's essential role is making the translation two-way — engineering strategy derives from company strategy, and engineering reality informs company strategy. When the company's strategy assumes capabilities your org does not have, your responsibility is to surface that misalignment explicitly and force the honest conversation — either the strategy adjusts or the capability gets funded; silently absorbing an impossible strategy fails the company twice. And when the company has no clear product strategy and engineering is asked to fill the vacuum, the right posture is neither refusal nor a silent takeover: lean in and co-create — bring options and evidence to force the strategic conversation the company is avoiding — while being explicit that engineering is contributing to, not replacing, product direction.
It is worth being precise about the artifacts at this altitude. A vision names the destination and why it matters; a strategy is a theory of how to win — a diagnosis and a coherent set of choices, including what you will not do; a roadmap is merely the current sequence of bets that follows from them. The most important thing a strategy does is commit: a "strategy" that keeps every option open in the name of flexibility is not flexible, it is absent — and because a real strategy makes real choices, it will meet real opposition; universal immediate agreement is a sign nothing was decided. What makes a strategy resilient is not vagueness but structure: outcomes and principles stable enough to survive change, with the means free to adapt — which is also how it stays alive between annual planning cycles: reviewed regularly against reality and revised when the signals say so, not when the calendar does.
Communicating strategy at this scale is a campaign, not an announcement: a memorable narrative, repeated relentlessly, embedded in visible decisions (what gets funded, what gets stopped), so it survives retelling three levels down.
Strong judgment looks like: treating org design, skills, and architecture as the strategy's implementation; telling the company what engineering can't yet do — before the plan depends on it; filling strategy vacuums with co-created options rather than silence or fait accompli; strategy communicated through decisions, not just decks.
Common pitfalls: new strategy, old org chart; nodding along to a company plan the org can't execute; treating the absence of product strategy as someone else's problem; a strategy that exists only in the offsite slides.
Self-check. Associate: what question tests whether a goal has been translated well? Professional: the exec team says your roadmap "doesn't add up to a strategy" — what is missing, and why doesn't more detail fix it? Expert: the company strategy assumes capabilities you lack — what is your responsibility, and what does silence cost?
3.2 Communicating with non-engineering stakeholders
A leader is the interface between engineering and the rest of the organisation — product, sales, finance, executives, customers. The competency is communicating in the listener's language and at their altitude: outcomes, trade-offs, and risks, not architecture lectures. Effective stakeholder communication is proactive and outcome-framed — translate technical realities into business consequences, surface bad news early, and set expectations you can beat. When you must say no or deliver disappointment, lead with the trade-off and the reasoning, not just the verdict.
At Associate — the team's interface
Tailor the same update to the CFO (cost, risk), the product lead (timeline, scope), the customer (impact, resolution). Raise risks before they mature into surprises. Under-promise and over-deliver, not the reverse.
Strong judgment looks like: messages pitched to the audience's concerns; technical facts translated to business impact; bad news early; expectations set to be beaten.
Common pitfalls: drowning non-engineers in detail; going silent on problems; one-size-fits-all updates; over-promising to dodge a hard moment.
At Professional — negotiating on behalf of a department
At department scale, stakeholder communication becomes negotiation with trade-off transparency as the core move. The recurring pattern behind most Professional scenarios: someone with power asks for something that violates capacity or sequencing, and the strong answer is never a bare yes or no — it is the trade-off, stated calmly. Asked to pull a Q3 strategic initiative into Q1 after a competitor's move: communicate precisely what the acceleration costs — what gets displaced, what risk is added — and let the decision be made on the real price. Asked to absorb a new product line with no additional headcount: respond with the capacity trade-off — what your department will stop doing or slow down — and get the choice made explicitly, rather than absorbing quietly and failing broadly. When leadership changes priorities every few weeks and the whiplash is hurting your teams, name the cost of the churn — the lost throughput, the eroding trust — and negotiate a stable planning horizon with an explicit fast-lane for genuine emergencies. In every case, presenting an investment plan to executives follows the same rule: what matters most is how the investment maps to business outcomes and what the trade-off of not doing it is — not the feature list, the technology choices, or the hiring plan.
The Professional also aligns sideways. Alignment between engineering and product at this scale is created by shared outcomes and joint planning — one plan, not two negotiated treaties. A partner department you depend on gets the same treatment: align roadmaps against shared outcomes with dependencies made explicit, and when their roadmap directly conflicts with yours, resolve it at the level where priorities are actually owned — jointly, with the shared goal on the table — rather than in a proxy war between teams.
Strong judgment looks like: every ask answered with its trade-off; capacity defended with numbers, not complaints; churn priced and negotiated, not silently absorbed; sideways alignment built on shared outcomes and joint planning.
Common pitfalls: heroically absorbing asks until delivery fails; flat refusals that read as "engineering says no"; escalating partner conflicts as blame instead of resolving them as priority calls; investment pitches framed in technology instead of outcomes.
At Expert — the executive table and the board
At executive altitude the audiences are the board, the CEO, and peer executives — and the stakes are engineering's standing in the company. To a skeptical board with tight margins, a three-year investment thesis is strongest when it is framed as business strategy: what the investment enables and protects, what not investing costs, staged with checkpoints — evidence over faith. When the board questions why headcount keeps growing without obviously faster output, the strongest response explains what the scaling actually bought (reliability, security, capacity to run more products, risk retired) and shows outcome measures — not a promise to make everyone busier. When the CEO says "engineering needs to move faster" with no specifics, the executive move is to clarify and diagnose before defending or promising: faster at what, by whose measure? Then respond with an evidence-based picture and a concrete plan. And when engineering is seen as a cost centre that says no, the fix is behavioural, not rhetorical: show up as a business partner — bring options and trade-offs instead of vetoes, tie engineering work visibly to revenue and risk, and make "yes, and here's the cost" the default grammar. The same executive-level framing solves the chronic case of sales committing custom features to close deals, fragmenting the engineering strategy: the fix is not to fight each deal but to change the system with your peer — an explicit gate for custom commitments (priced, capacity-checked, owned by product) agreed at the executive level, so the incentive to promise engineering's capacity without engineering stops existing.
Disagreement at this table is its own skill. When a powerful peer executive pushes a strategy you believe is wrong for the company, the responsibility is to disagree — directly, privately first, with evidence, framed on company outcomes rather than turf — and escalate honestly if it matters enough; then, if the decision goes against you, commit visibly rather than sabotaging quietly.
Strong judgment looks like: board communication as staged, evidence-based business argument; clarifying vague executive pressure before answering it; repositioning engineering as the partner that prices options; disagreeing with peers on the merits and committing after the call.
Common pitfalls: defending engineering with indignation instead of evidence; answering "move faster" with either capitulation or a lecture; letting "no" be engineering's public vocabulary; fighting peer-executive battles through subordinates.
Self-check. Associate: why is surfacing bad news early a trust-building move? Professional: you're told to absorb a new product line with no headcount — what does the strong response contain that a yes or a no doesn't? Expert: the board asks why headcount grew without faster output — what makes a response credible?
3.3 Roadmapping — product delivery vs. platform investment
A roadmap is a sequence of bets about where to spend finite capacity, and the perennial tension is shipping features now versus investing in the platform that enables future features. Starve the platform and velocity decays under accumulating debt and toil; over-invest and the business starves for visible value. The competency is balancing deliberately: allocate capacity explicitly (a standing fraction for platform, reliability, and debt so it isn't perpetually deferred), treat the roadmap as a living instrument of trade-offs framed around outcomes, distinguish near-term commitments from directional bets, and say what you are not doing. Investment cases for foundations are strongest in business consequences, not engineering aesthetics.
At Associate — one team's balance
Protect a deliberate share of capacity for foundational work; justify platform investment in business terms; present the roadmap as adaptable bets, not dated promises; be explicit about what's deferred.
Strong judgment looks like: a stated feature/platform balance that survives pressure; foundations argued as business value; a roadmap that names its non-goals.
Common pitfalls: feature pressure consuming 100% until velocity collapses; gold-plating the platform; roadmap-as-promise; infrastructure justified purely on engineering grounds.
At Professional — curating a department portfolio
At department scale the roadmap becomes a portfolio with admission criteria. Initiatives make the roadmap by expected contribution to the department's stated outcomes weighed against cost and risk — not by which team wants them or which stakeholder asked last. The signs of over-commitment are mechanical and worth knowing cold: everything in progress and nothing finishing, no capacity for the unplanned, dates missed in bulk, and zero slack for discovery. Two chronic drains test this competency. Unplanned work: when teams lose 30% of capacity to ad-hoc cross-org requests with little strategic return, the fix is to make the drain visible, put a gate and an owner on intake, and either budget explicit capacity for genuinely valuable interrupts or route the rest into planning — the one wrong answer is pretending the roadmap still holds. Unclear mandates: a long-running internal tools team whose strategic value nobody can state gets assessed against the strategy — given a clear mandate and success measures if the value is real, or redeployed if it isn't; what it must not get is another year of default funding because it has always existed.
Roadmap change is led, not suffered. Sunsetting a product line your teams built and love calls for the honest rationale, respect for the work (celebrate what it achieved), and a deliberate path for the people and the users — not a quiet strangulation by defunding.
Strong judgment looks like: admission to the roadmap by outcome contribution; over-commitment read from flow signals and corrected by cutting, not exhorting; interrupt capacity budgeted explicitly; every standing investment able to state its mandate; sunsets led with honesty and respect.
Common pitfalls: a roadmap that is the union of stakeholder requests; treating chronic unplanned work as weather; legacy teams funded by inertia; sunsets communicated as an afterthought.
At Expert — a portfolio of horizons
The executive's roadmap question is not this quarter's list but the balance of time horizons: how much of the organisation's capacity serves the current business, how much builds the platform the strategy needs in two years, and how much explores what might disrupt everything. The two-year platform versus near-term features trade-off is approached by making it explicit at the executive table — staging the platform to deliver intermediate value where possible, sizing the near-term sacrifice honestly, and getting genuine executive commitment rather than starting a long bet on borrowed patience. That commitment is then defended: when short-term market pressure threatens the long-term investment that is core to your strategy, the executive re-makes the case in current business terms, offers staged options if capacity truly must shift, and refuses the silent nibbling that kills platforms one "temporary" reallocation at a time. Disruptive technology is sized as a bet, not a mood: too small to matter and too big to survive being wrong are both errors — commit enough to build real capability and learn fast, with explicit checkpoints to double down or fold. When a capability is existential and the org lacks expertise and is full of committed work — the AI case — the executive approach is deliberate: clear something out explicitly to fund focused bets and capability-building, rather than sprinkling it on top of everyone's full plate.
Strong judgment looks like: an explicit horizon mix owned at the executive level; long bets staged for intermediate value and protected from erosion; disruption bets sized to teach; existential priorities funded by explicit subtraction.
Common pitfalls: perpetual near-term optimisation while the platform ages into a crisis; long bets launched without secured commitment; token innovation spend; adding the existential priority as everyone's tenth job.
Self-check. Associate: what happens to a team with zero platform/debt capacity? Professional: name three flow signals of an over-committed roadmap and what correcting each requires. Expert: why does a two-year platform bet need staged value and explicit executive commitment before it starts?
3.4 Resource allocation and build-vs-buy
Every allocation is a choice against alternatives. The universal frame is core vs. context: build what differentiates your business and where you need control; buy or adopt the commodity, freeing scarce engineers for differentiating work. Weigh total cost of ownership — buying isn't free (integration, lock-in, ongoing cost) and building is never a one-time cost (maintenance forever). Concentrate effort to finish high-value work rather than spreading thin. And decisions about changing allocations obey the sunk-cost discipline: what has been spent is gone; only the forward-looking comparison counts.
At Associate — a team's leverage
Build the differentiating core, buy commodity context; weigh total cost of ownership, not sticker price; concentrate to finish; revisit allocations as priorities shift.
Strong judgment looks like: core-vs-context reasoning; TCO over sticker price; focus protected; allocations revisited on evidence.
Common pitfalls: building commodity capability ("not invented here"); outsourcing the differentiator; ignoring forever-maintenance; too many simultaneous bets.
At Professional — allocating across teams and charters
Department-scale allocation adds three recurring judgments. Choosing between bets: two strategic bets of similar size are separated by expected outcome and cost of delay, strategic fit, risk, and reversibility — explicitly compared, not decided by advocacy volume. The same discipline guards against the shiny object: abandoning a committed bet partway is justified only if the fundamentals have changed — new information about the bet or the market, not the mere appearance of something newer; novelty is not evidence. Its mirror image is the sunk-cost trap: a year-old migration, half done, over budget, its original justification eroded by shifting priorities, gets reassessed against current goals with a clean continue / descope / stop recommendation — the money already spent argues for nothing. Cutting under constraint: told to cut the department budget by 15%, look first at the work with the lowest strategic value — the initiatives that would not be started today — never the across-the-board shave that degrades everything equally and decides nothing.
Allocation at this altitude also means charters — who owns which capability. When a peer department keeps encroaching on your team's charter, creating duplication and confusion, the move is to clarify ownership explicitly at the level where charters are set — a boundary conversation, not a turf war fought commit by commit. Conversely, when a high-ROI opportunity appears outside your charter, the strong response is to surface it to the owner it belongs to — or propose an explicit charter change — rather than either ignoring it or quietly land-grabbing.
Strong judgment looks like: bets compared on outcomes, delay cost, and reversibility; switching only on changed fundamentals; killing on forward-looking math; cuts targeted at the lowest-value work; charter disputes settled explicitly at the right level.
Common pitfalls: finishing doomed work to honour its sunk cost; chasing novelty mid-bet; peanut-butter budget cuts; fighting charter wars through duplicated engineering.
At Expert — bets that shape the company
Executive allocation decisions carry strategic externalities the lower altitudes rarely see. Build-vs-partner for a strategic capability, where the potential partner could become an acquirer or competitor: the primary weight is not cost or speed but strategic control and dependency risk — what position you are in if the relationship sours, and who ends up owning the capability that matters. Funding one of two compelling bets: beyond expected value, weigh asymmetry — which failure is survivable, which success compounds — and which bet builds capability the strategy needs anyway; then fund the chosen one properly instead of splitting resources to avoid the decision. The discipline is hardest when the underperforming bet is one you personally championed: executive integrity means applying the same forward-looking math to your own advocacy — redirecting from a two-year-old bet you argued for, when a more promising direction has emerged, is exactly the behaviour that makes your next recommendation believable. Acquisitions hand the executive an allocation problem wearing a people problem: a redundant engineering org with its own stack and culture requires deliberate integration choices — which platform consolidates, which teams merge, on what timeline, with the retention of the people you actually bought priced in — because "let both stacks live" is a decision too, and usually the most expensive one.
Strong judgment looks like: partnership decisions weighed on control and dependency, not just cost; funding decisively rather than hedging into mediocrity; acquisition integration treated as an explicit strategy with a bill.
Common pitfalls: partnering your crown jewels to a future competitor; splitting funding to avoid choosing; letting acquired stacks and orgs drift unintegrated; optimising acquisition cost while the acquired talent walks out.
Self-check. Associate: how does core-vs-context guide build-vs-buy? Professional: a half-done migration is over budget and its justification has weakened — what does the recommendation weigh, and what does it ignore? Expert: in a build-vs-partner call where the partner could become a competitor, what weighs most and why?
3.5 Engineering metrics that mean something
Metrics make engineering legible and improvable — but the wrong metrics actively harm. The strongest validated delivery measures are the DORA metrics: deployment frequency and change lead time (throughput), change failure rate and failed-deployment recovery time (stability), plus rework rate (added 2024). They are deliberately team-level, outcome-oriented measures of the delivery system, never individual productivity scores. Goodhart's Law governs everything here: when a measure becomes a target, it ceases to be a good measure — activity metrics (lines of code, commit counts, story points per engineer) are easiest to game and most destructive to weaponise. Use a small balanced set so improving one doesn't quietly wreck another; pair numbers with qualitative context; treat metrics as conversation starters, not verdicts.
At Associate — measuring one team honestly
Measure team-level delivery outcomes; pair throughput with stability; use metrics to find problems, not rank people; stay alert to gaming.
Strong judgment looks like: DORA-style system measures; balance across throughput and stability; metrics in service of learning.
Common pitfalls: individual output as "productivity"; chasing one metric until another breaks; metrics as surveillance; numbers without context.
At Professional — measuring across teams without breaking them
Department-scale measurement adds a temptation the Associate never faced: comparing teams. Resist ranking teams by velocity or output — story points aren't a currency, contexts differ, and the ranking teaches teams to optimise the number (Goodhart, again, at department scale). What genuinely informs a manager-of-managers is each team's trend against itself — cycle time and its direction, predictability (committed versus delivered), and change failure rate — plus the health signals that predict trouble before delivery shows it. Metrics at this altitude also become the language of the trade-off conversations in 3.2 and 3.3: capacity drains, over-commitment, and platform decay are all arguments you win with measured evidence, not adjectives. The discipline is to keep measurement wholesale, not retail: instrument the system between teams (queues, handoffs, dependencies), because that — not any team's internals — is what you uniquely own.
Strong judgment looks like: teams trended against themselves, never leaderboarded; predictability and stability alongside speed; the between-teams system instrumented; evidence carried into every capacity argument.
Common pitfalls: cross-team velocity leaderboards; normalising story points into a fake currency; measuring team internals while the queues between them go dark; discovering drains and decay by anecdote.
At Expert — measuring whether the strategy works
The executive's measurement question is not "how fast are the teams?" but "is the strategy working?" — and the honest answer comes from outcome measures tied to the strategy's own claims: the business results the investment was meant to move, leading indicators chosen in advance, and the delivery-health trends that show whether the machine is improving. Judging a strategy by activity — initiatives launched, headcount deployed, teams "busy on it" — is the executive-scale Goodhart failure, and its public form is the board conversation from 3.2: growth without measured outcomes reads as bloat, because unmeasured it is indistinguishable from bloat. The executive therefore owns a small, stable scorecard: strategic outcomes, delivery system health (DORA-class trends at org level), and organisational health (retention, engagement in the leadership pipeline) — reviewed on a cadence, revised when the strategy is revised, and never allowed to swell into a dashboard nobody reads.
Strong judgment looks like: success criteria declared when the strategy is set; outcomes and leading indicators over activity; one stable scorecard reviewed on a cadence; measurement that can prove the strategy wrong.
Common pitfalls: declaring victory by effort expended; a strategy with no falsifiable success measure; dashboard sprawl; discovering at the board meeting that "working" was never defined.
Self-check. Associate: why are DORA metrics team-level rather than individual? Professional: why is trending a team against itself sound where ranking teams against each other is not? Expert: what does it mean for a strategy to have a falsifiable success measure, and what happens at the board when it doesn't?
Key takeaways
- Translation scales from outcome-framing a team's work, to a department thesis that lets teams decide locally, to treating org design itself as the strategy's implementation — and telling the company what engineering can't yet do.
- Stakeholder communication becomes negotiation: every ask answered with its trade-off at Professional; evidence-based business argument to boards, CEOs, and peers at Expert — engineering as the partner that prices options, not the department of no.
- Roadmapping grows from one team's feature/platform balance to a portfolio with admission criteria to an explicit mix of time horizons — with long bets staged, protected, and funded by subtraction.
- Allocation keeps its core-vs-context, TCO, and sunk-cost disciplines while the stakes rise to charters, budget cuts, build-vs-partner control, and acquisition integration.
- Measurement stays Goodhart-aware at every altitude: team systems (never individuals), teams trended (never ranked), and at the top a falsifiable scorecard for whether the strategy itself is working.