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). Even a first-line manager operates here: translating goals into work, communicating with non-engineers, balancing today's features against tomorrow's foundations, and choosing where to spend finite resources. This domain carries 20% of the EMA-I exam (12 questions).
The throughline is reasoning about outcomes, not output. Strong managers 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 exam favours options that tie engineering decisions to outcomes and stakeholder value over those that optimise purely for engineering preference.
3.1 Translating business goals into technical direction
The strategy arrives in business language (grow revenue, reduce churn, enter a segment) and must be translated into engineering work the team 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 the team 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: pick any item on the plan and ask an engineer why it's there. If the answer ties to a business outcome, the translation worked; if it's "because it's on the roadmap," it failed.
Strong judgment looks like: framing work as outcomes; deriving features from the conditions for success; ensuring every engineer can explain why their work matters; re-deriving the plan when circumstances change.
Common pitfalls: turning strategy into a literal feature list with no impact theory; staying so abstract the team can't act; building things because they're on the roadmap rather than because they advance a goal.
Self-check: What's the difference between output and outcome framing, and why does outcome framing give teams more freedom? What question tests whether a goal has been translated well?
3.2 Communicating with non-engineering stakeholders
A manager is the interface between their team and the rest of the organisation — product, sales, leadership, customers. The competency is communicating in the listener's language and at their altitude, not in engineering detail. Executives want outcomes, trade-offs, and risks; they do not want an architecture lecture.
Effective stakeholder communication is proactive and outcome-framed: translate technical realities into business consequences ("this refactor lets us add enterprise customers without the outages that lost us two deals"), and surface bad news early rather than hoping it resolves. Tailor the message — the same update is framed differently for a CFO (cost, risk), a product lead (timeline, scope), and a customer (impact, resolution).
Managing expectations is central: under-promising and over-delivering builds trust; the reverse destroys it. When you must say no or deliver disappointing news, lead with the trade-off and the reasoning, not just the verdict.
Strong judgment looks like: pitching the message to the audience's altitude and concerns; translating technical facts into business impact; raising risks and bad news early; setting expectations you can beat.
Common pitfalls: drowning non-engineers in technical detail; going silent on problems until they explode; one-size-fits-all updates; over-promising to avoid a hard conversation in the moment.
Self-check: Why must the same status be framed differently for a CFO versus a product lead? Why is surfacing bad news early a trust-building move rather than an admission of failure?
3.3 Roadmapping — product delivery vs. platform investment
A roadmap is a sequence of bets about where to spend the team's 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 in it and the business starves for visible value. The competency is balancing the two deliberately rather than letting feature pressure crowd out all foundational work.
A practical approach is to allocate capacity explicitly — for example, reserving a standing fraction for platform, reliability, and debt work so it isn't perpetually deferred — and to make the roadmap a living instrument of trade-offs, not a fixed list of dated promises. A good roadmap says what you are not doing and why, distinguishes near-term commitments from later directional bets, and is framed around themes and outcomes so it can absorb change.
Investment cases for platform work are strongest when tied to business consequences ("this unlocks the enterprise segment" / "this halves the outage rate that's costing us renewals") rather than engineering aesthetics.
Strong judgment looks like: protecting a deliberate share of capacity for foundational work; justifying platform investment in business terms; treating the roadmap as adaptable bets; being explicit about what's deferred.
Common pitfalls: letting feature pressure consume 100% of capacity until velocity collapses; gold-plating the platform while the business waits; presenting the roadmap as fixed promises; justifying infrastructure work purely on engineering grounds.
Self-check: What happens to a team that allocates none of its capacity to platform and debt work? Why express a platform investment case in business terms?
3.4 Resource allocation and build-vs-buy
With finite people and budget, every allocation is a choice against alternatives. The competency is deciding where the team's effort creates the most leverage — and, frequently, whether to build, buy, or adopt a capability at all.
The build-vs-buy judgment turns on whether the capability is core or context: build what is differentiating to your business and where you need control; buy or adopt the commodity capabilities where a vendor or open-source solution is good enough and frees your scarce engineers for the differentiating work. Reflexively building everything ("not invented here") wastes your most limited resource; reflexively buying critical, differentiating capability cedes control you may need. Factor in total cost of ownership — buying isn't free (integration, lock-in, ongoing cost), and building isn't a one-time cost (it must be maintained forever).
Allocation also means focus: concentrating effort to finish high-value work beats spreading the team thin across many half-done initiatives, which carries the hidden cost of context-switching.
Strong judgment looks like: building the differentiating core and buying the commodity context; weighing total cost of ownership, not sticker price; concentrating effort to finish; revisiting allocations as priorities shift.
Common pitfalls: building commodity capabilities your engineers shouldn't spend time on; buying or outsourcing the very thing that differentiates you; ignoring the long-term maintenance cost of "just building it"; spreading the team across too many simultaneous bets.
Self-check: How does the core-vs-context distinction guide build-vs-buy? Why is "we'll just build it ourselves" not a cost-free decision?
3.5 Engineering metrics that mean something
Metrics make engineering legible and improvable — but the wrong metrics actively harm. The competency is choosing measures that reflect real outcomes and using them to learn, not to surveil.
The strongest validated delivery measures are the DORA metrics: deployment frequency and change lead time (throughput) plus change failure rate and failed-deployment recovery time (stability), with a 2024 addition of rework rate. Crucially, these are team-level, outcome-oriented measures of the delivery system, not individual productivity scores. Beware metrics that are easy to game and easy to misuse: lines of code, commit counts, or story points per engineer measure activity, not value, and weaponising them destroys trust (a direct illustration of Goodhart's Law — when a measure becomes a target, it stops being a good measure).
Good practice: use a small balanced set so improving one doesn't quietly wreck another (shipping faster while reliability collapses is not a win); pair quantitative signals with qualitative context; and treat metrics as a conversation starter, not a verdict.
Strong judgment looks like: measuring team-level delivery outcomes (e.g., DORA); pairing throughput with stability; using metrics to find problems, not to rank people; staying alert to gaming.
Common pitfalls: measuring individual output (LOC, commits) and calling it productivity; chasing one metric until another breaks; turning metrics into a surveillance or stack-ranking tool; trusting a number without its context.
Self-check: Why are DORA metrics deliberately team-level rather than individual? What does Goodhart's Law warn about using "commits per engineer" as a target?
Key takeaways
- Translate goals into outcomes; ensure every engineer can explain why their work matters.
- Communicate at the listener's altitude in business terms; surface bad news early.
- Balance feature delivery against platform investment deliberately; justify foundations in business terms.
- Build the differentiating core, buy commodity context; weigh total cost of ownership and protect focus.
- Measure team-level outcomes (DORA), balance throughput with stability, and never weaponise activity metrics.