Domain 2 — Delivery & Execution
Delivery & Execution is the work of turning intent into shipped, reliable software — predictably. It is where good intentions meet constraints: limited time, shifting requirements, finite people, and the messy reality that software estimation is hard. This domain carries 20% of the EMA-I exam (12 questions).
The common thread is managing under uncertainty: a strong manager does not promise certainty they cannot deliver, but creates predictability through sequencing, honest forecasting, risk management, and the lightest process that works. The exam consistently rewards options that surface trade-offs and reality over those that optimise for looking good in the short term.
2.1 Prioritisation under constraint
Prioritisation is the discipline of deciding what not to do. There is always more demand than capacity; the manager's job is to sequence work so the most important outcomes happen first and to say no — clearly and early — to the rest.
Effective prioritisation starts from value and cost of delay, not from who asked loudest or most recently. Lightweight frameworks help make trade-offs explicit and defensible: weighing impact against effort, separating the urgent from the important (the Eisenhower distinction), or using a value-vs-effort view to find high-leverage work. The specific tool matters less than the habit of reasoning explicitly rather than reacting.
Saying no is a core skill. The strong move is not refusal but trade-off transparency: "we can do X, but it means Y slips — which do you want?" This turns prioritisation into a shared, informed decision and protects the team from silently absorbing every new request.
Strong judgment looks like: sequencing by value and cost of delay; making trade-offs explicit to stakeholders; saying no by surfacing the cost of yes; protecting focus from constant reprioritisation.
Common pitfalls: prioritising by volume (loudest voice wins); saying yes to everything and quietly missing everything; treating all "urgent" requests as equally important; reprioritising so often the team never finishes anything.
Self-check: Why is "we can do X but Y slips — which do you prefer?" stronger than a flat no? What's the danger of letting urgency alone drive the queue?
2.2 Estimation, planning, and honest commitments
Estimates are unreliable by nature — at the start of work you know the least you ever will (the cone of uncertainty), the happy path is easiest to imagine (optimism bias), and the hidden work (integration, edge cases, review, flaky tests) often dominates. The competency is not producing accurate estimates; it is managing the uncertainty honestly.
Practical techniques: estimate ranges, not points (a single number implies false precision); slice work small, because small estimates are far more accurate and the error compounds less; de-risk before committing by spending a time-boxed spike to turn a fuzzy unknown into a known; and use historical cycle time (how long work actually takes) as a better predictor than hope-based estimates.
The most important judgment is the gap between an estimate and a commitment. "Our best estimate is X; what we can commit to is Y" names the buffer against uncertainty and builds trust. Re-forecasting openly the moment you learn something — rather than springing a surprise near the deadline — is the mark of a manager stakeholders can rely on.
Strong judgment looks like: communicating ranges and assumptions; separating estimate from commitment; re-forecasting early and openly; slicing work to reduce estimation error.
Common pitfalls: treating an estimate as a promise; padding silently instead of naming uncertainty; committing to the optimistic number to avoid a hard conversation; going quiet when the timeline slips.
Self-check: Why does a range communicate more useful information than a single-point estimate? What's the difference between an estimate and a commitment, and why name it?
2.3 Incident response and operational ownership
When systems fail, the manager's role shifts. During an incident, the priorities are, in order: restore service, communicate, then diagnose — mitigation before root cause. A clear incident command structure (someone owning coordination and communication so engineers can focus on the fix) prevents the chaos of everyone debugging and no one coordinating.
The deeper competency is a blameless culture. Treating incidents as failures of people drives problems underground; treating them as failures of the system surfaces them. A good blameless post-mortem asks how the system allowed the error and what to change — process, tooling, guardrails — so the class of failure can't recur. This directly supports stability: one of DORA's four key delivery metrics is failed-deployment recovery time, and teams recover faster when they can talk honestly about what broke.
Operational ownership also means the team lives with what it ships ("you build it, you run it"), which aligns incentives toward reliability rather than throwing code over a wall.
Strong judgment looks like: prioritising mitigation over root-cause during an active incident; establishing clear incident command; running blameless post-mortems that fix the system; treating reliability as a first-class deliverable.
Common pitfalls: hunting for root cause while customers are still down; "who broke it?" post-mortems that punish honesty; treating recurring incidents as bad luck rather than a systems signal; separating those who build from those who operate.
Self-check: Why is mitigation prioritised over diagnosis during an active incident? How does a blameless post-mortem improve future reliability?
2.4 Managing scope, risk, and dependencies
Most delivery slips come not from slow coding but from unmanaged scope, surprise risks, and external dependencies. The competency is seeing these early and acting on them rather than discovering them at the deadline.
Scope must be actively defended — "scope creep" is the silent accumulation of small additions that sink a timeline. Name additions and trade them against the date explicitly. Risk management is mostly about making the implicit explicit: maintaining a lightweight view of what could go wrong, how likely and how damaging, and what would reduce it — and attacking the highest-uncertainty items first, since they carry the most schedule risk. Dependencies on other teams are the most common hidden delay; identify them early, confirm them with the other team (a dependency the other team doesn't know about is not a plan), and track them.
A key distinction is one-way-door vs. two-way-door decisions: spend deliberation on the expensive-to-reverse calls and move fast on the reversible ones.
Strong judgment looks like: defending scope and trading additions against the date; surfacing risks early and de-risking the biggest unknowns first; confirming cross-team dependencies explicitly; matching deliberation to reversibility.
Common pitfalls: absorbing scope additions silently; keeping a risk "in your head" until it materialises; assuming another team will deliver on your timeline without confirming; agonising over reversible decisions while rushing irreversible ones.
Self-check: Why attack the highest-uncertainty risks first? What makes an unconfirmed cross-team dependency dangerous?
2.5 Process selection — the lightest process that works
Process exists to serve delivery, not the reverse. The competency is choosing the minimum process that solves the actual problem — enough structure to coordinate and create predictability, not so much that it becomes ceremony that drains time and morale.
Good managers treat practices (standups, retros, estimation rituals, agile frameworks) as tools to be adopted, adapted, or dropped based on whether they help this team right now — not as doctrine to follow because it's fashionable. The diagnostic question is always "what problem is this process solving, and is it still solving it?" A retro that has become a status meeting, or estimation that produces numbers no one uses, should be changed or removed.
Process should also scale with the situation: a two-person prototype and a fifty-person platform need different amounts of it. Adding process is easy; removing it is hard, so the bias should be toward the lightest version that works and adding more only when a real coordination problem demands it.
Strong judgment looks like: adopting process to solve a named problem; pruning rituals that no longer earn their cost; adapting practices to the team rather than following them dogmatically; scaling process to context.
Common pitfalls: adopting a heavy framework because it's standard, not because it helps; keeping zombie ceremonies long after they've lost purpose; equating more process with more rigour; imposing big-company process on a tiny team (or vice versa).
Self-check: What question should you ask of any existing ritual? Why is the bias toward the lightest process that works?
Key takeaways
- Prioritise by value and cost of delay; say no by making the trade-off explicit.
- Manage estimation uncertainty (ranges, slicing, spikes, cycle time); separate estimate from commitment and re-forecast early.
- In incidents: mitigate first, communicate, then run a blameless post-mortem that fixes the system.
- Defend scope, surface risk early (attack biggest unknowns first), confirm dependencies explicitly.
- Use the lightest process that works; prune rituals that no longer solve a real problem.