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 every exam (12 questions on EMA-I, 15 on EMP-II, 18 on EME-III).
The altitude arc: at Associate you run a team's delivery; at Professional you run the system between teams — dependencies, shared bottlenecks, cross-team commitments, and the truthfulness of status; at Expert you build the organisation's execution operating system — the portfolio, cadence, and information flows that let dozens of teams deliver without you in the room. The throughline is managing under uncertainty: strong leaders do not promise certainty they cannot deliver, but create predictability through sequencing, honest forecasting, risk management, and the lightest structure that works. The exams consistently reward 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 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 framing helps make trade-offs explicit and defensible: impact against effort, urgent against important (the Eisenhower distinction). The specific tool matters less than the habit of reasoning explicitly rather than reacting. Saying no is a core skill at every altitude, and the strong move is never flat refusal but trade-off transparency: "we can do X, but it means Y slips — which do you want?" Two facts about flow underpin the higher bands: work in progress trades against throughput — the more that is started, the slower everything finishes — and a system loaded to 100% has no capacity to absorb variance, so full-looking is not the same as effective.
At Associate — sequencing the team's work
The first-line version is protecting a single team's focus: sequencing by value and cost of delay, making trade-offs explicit to stakeholders, saying no by surfacing the cost of yes, and resisting the churn of constant reprioritisation that leaves everything started and nothing finished.
Strong judgment looks like: an explicitly reasoned queue; trade-offs surfaced, not absorbed; focus defended against noise.
Common pitfalls: loudest-voice prioritisation; saying yes to everything and quietly missing everything; treating every "urgent" as important; reprioritising so often nothing ships.
At Professional — one portfolio across teams
A manager of managers prioritises between teams, where local optimisation quietly destroys global outcomes. When three of your teams all depend on a shared platform team and each manager escalates their own request separately, the job is not to forward three escalations — it is to set a single prioritisation across your teams and represent it once, ending the internal competition. The same logic governs the general case: every team maximising its own local velocity misaligns the whole, so cross-team priorities, limited work in progress across the group (which makes the most important things finish sooner), and deliberate slack are the levers that move department-level throughput. A team that is busy 100% of the time is not at peak effectiveness; it is one surprise away from missing everything.
Two recurring Professional situations live here. Staffing a cross-team initiative when all three managers resist lending people: this is your trade-off to own, not a negotiation to referee — decide against the department's priorities, name what slips in consequence, and own that cost rather than letting the initiative starve politely. And intake discipline: when stakeholders bypass the front door and go straight to engineers, the fix is the system, not the people — a single visible intake path, stakeholders redirected to it consistently, and engineers backed when they redirect.
Strong judgment looks like: one ranked view of demand across your teams; representing your group's priorities to shared dependencies with one voice; limiting org WIP so things finish; owning staffing trade-offs explicitly.
Common pitfalls: letting each team fight its own escalation war; measuring health by how busy every team is; refereeing lending disputes instead of deciding; punishing engineers for accepting work the intake system failed to catch.
At Expert — portfolio governance
At organisational scale, prioritisation becomes portfolio governance. The pathology is universal: twelve teams, thirty initiatives, everything labelled priority one, nothing finishing cleanly. The executive intervention is to force real prioritisation — fewer concurrent initiatives, explicitly ranked, sequenced to finish — because at org scale adding parallel initiatives does not increase throughput; it increases only the appearance of progress while everything decelerates. An explicit ranking also resolves resource contention by strategy instead of politics: when two strategic programs compete for the same scarce senior talent, the answer comes from the portfolio's stated priorities, made once and communicated — not from whichever program's sponsor shouts loudest.
Two Expert-grade tests of nerve: an initiative that is clearly failing but has powerful executive sponsorship still gets the honest recommendation — surface the evidence and recommend stop or descope; sponsorship is not a reason to keep burning the org's capacity. And in a genuine crisis requiring overnight reallocation of capacity, the executive makes the priority call cleanly, delegates the execution of the shuffle to their leaders, and over-communicates the reasoning — clarity and speed over consensus and committees.
Strong judgment looks like: a portfolio small enough to finish; ranking that makes scarce-resource decisions for you; killing failing bets regardless of their sponsors; crisis reallocation led by explicit priorities, executed through leaders.
Common pitfalls: thirty priority-ones; measuring the org by initiatives started; letting sponsorship immunise failing work; personally micromanaging a crisis shuffle instead of leading it.
Self-check. Associate: why is "X or Y slips — which do you prefer?" stronger than a flat no? Professional: three teams escalate competing requests to a shared bottleneck — what does strong judgment do that forwarding the escalations doesn't? Expert: why does adding parallel initiatives reduce org throughput, and what does that imply for portfolio size?
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 hidden work often dominates. The competency is not producing accurate estimates; it is managing the uncertainty honestly.
The practical toolkit holds at every altitude: estimate ranges, not points; slice work small, because small estimates are more accurate and the error compounds less; de-risk before committing with time-boxed spikes; and prefer historical cycle time to hope. The most important distinction is 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. And the moment reality diverges from forecast, re-forecast openly — surprises sprung at the deadline are how trust dies.
At Associate — honest forecasting for a team
The first-line version: ranges and assumptions communicated, estimate separated from commitment, work sliced to reduce error, and the slip conversation had early rather than never.
Strong judgment looks like: ranges with named assumptions; commitment as a deliberate buffer over estimate; early, open re-forecasting.
Common pitfalls: treating an estimate as a promise; silent padding; committing to the optimistic number to dodge a hard conversation; going quiet as the timeline slips.
At Professional — commitments across teams
A department's commitment to stakeholders is not a promise to hit a date no matter what; it is a shared understanding of scope, known risks, and how variance will be communicated. Guarding that definition is the Professional's job — including under pressure. When a VP asks you, on the spot, to commit your org to a date for an unestimated initiative, the credible response is to commit to a date by which you will deliver a credible estimate, name the key unknowns, and then commit to scope — decisiveness about the process, not a guess dressed as a plan. When leadership wants a firm deadline and your estimate carries wide uncertainty, give the range with its drivers and a de-risking plan with checkpoints, not a falsely precise date.
Forecast calibration is a system you manage across teams. One team consistently over-commits and misses; another quietly sandbags and always hits. Both are the same failure — forecasts that don't carry information — and both get the same treatment: recalibrate against historical data, not motivational speeches for one and congratulations for the other. (An org that delivers exactly to plan every quarter with zero misses is most likely sandbagging, not excelling.) A team producing wildly inconsistent estimates gets engineering, not exhortation: smaller slices, historical cycle-time data, and estimation reviews that compare forecasts to actuals. Across teams, the most effective predictability lever is flow mechanics — smaller batches and limited WIP — because predictability is a property of the system, not of how hard people try.
Strong judgment looks like: commitments defined as scope + risks + variance protocol; refusing on-the-spot dates while still being decisive; treating over-commitment and sandbagging as the same calibration failure; improving predictability through batch size and WIP, not pressure.
Common pitfalls: letting a commitment mean "guaranteed date"; guessing under executive pressure; praising the sandbagger's streak; demanding better estimates without changing how work is sliced or measured.
At Expert — credibility at the board level
Executive commitments trade in credibility. Asked by the board for a delivery date on a transformational program full of unknowns, the credible answer is staged: near-term milestones committed firmly, later phases as ranges that tighten at named checkpoints, unknowns stated plainly. This is not hedging — it is the only forecast a sophisticated audience should believe. When your org has missed its commitments three quarters running, the credible response is not a better excuse or a bolder promise: diagnose the systemic cause, fix the forecasting machine, and rebuild trust through smaller, verifiable commitments delivered in sequence. And when a major commitment is clearly going to miss, the executive move is early disclosure with options — date, scope, or resourcing — while choices still exist; late surprise converts a delivery problem into a trust problem.
The hardest version is the flagship trade-off: slip the launch date, or hold it by cutting quality. Make the call on total cost over time, not on this quarter's optics — a launch that fails at scale costs more than a slip — decide explicitly, and communicate the reasoning. Relatedly, the most meaningful indicator of execution health at org scale is not activity or velocity but whether the org reliably converts commitments into delivered outcomes — predictability of finished, valuable work.
Strong judgment looks like: staged commitments with checkpoints; credibility repair through verifiable delivery, not rhetoric; early miss-disclosure with options; date-vs-quality calls made on long-term cost and owned publicly.
Common pitfalls: giving the board false precision because it asked for a date; re-promising bigger after each miss; sitting on a known miss until it's undeniable; holding a date by shipping something that will fail at scale.
Self-check. Associate: what's the difference between an estimate and a commitment, and why name it? Professional: one team over-commits, another sandbags — why are these the same problem, and what fixes both? Expert: what makes a staged commitment more credible than a single date, and what does repeated re-promising cost?
2.3 Incident response and operational ownership
When systems fail, priorities invert: 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. Afterwards, the deeper competency is a blameless culture: treating incidents as failures of the system rather than of people is what allows problems to surface at all. A good blameless post-mortem asks how the system allowed the error and what to change — and it is only effective if the changes it produces are tracked to completion; a post-mortem whose actions die in a backlog is a ritual, not a fix. Operational ownership means the team lives with what it ships ("you build it, you run it"), aligning incentives toward reliability. One of DORA's delivery metrics — failed-deployment recovery time — improves precisely where honesty about failure is safe.
At Associate — running the team's incidents
Mitigate first while customers are down; establish who is coordinating; run the post-mortem blamelessly and fix the system; treat reliability as a first-class deliverable rather than an interruption to "real work."
Strong judgment looks like: mitigation before diagnosis; clear incident command; post-mortems that change the system; reliability owned by the team that ships.
Common pitfalls: root-causing during the outage; "who broke it?" reviews; treating recurring incidents as bad luck; building teams that throw code over a wall.
At Professional — incidents and operations across teams
Cross-team incidents fail in a characteristic way: three teams debugging, no one in charge. What the situation needs from you is structure, not heroics — establish or confirm a single incident commander with authority across the teams, then get out of the way of the fix. The department-level version of blamelessness is holding the norm under pressure: when a launch slips badly and a senior stakeholder demands a post-mortem that names who is at fault, you run it blamelessly anyway — focused on how the system failed — while being clear that blamelessness is not the absence of accountability; it is what makes real accountability (fixing the system, honestly) possible.
Professional operational ownership is also about the map: after a reorg, when a fragile area causes recurring incidents and no team clearly owns it, the fix is to assign explicit ownership and fund the stabilisation — orphaned systems do not heal, and every incident in one is an ownership decision deferred.
Strong judgment looks like: installing cross-team incident command rather than joining the debugging; defending blameless reviews against blame-hungry stakeholders; closing ownership gaps the org chart created; tracking post-mortem actions to completion.
Common pitfalls: becoming the de-facto incident commander for every incident; letting a powerful stakeholder turn a review into a trial; leaving fragile systems orphaned because reassignment is awkward; measuring post-mortems by documents produced rather than recurrences prevented.
At Expert — reliability as an organisational property
At scale, reliability stops being a sum of team behaviours and becomes a property of the organisation — and it degrades silently when no one owns the trend. When on-call load and reliability are quietly worsening across a scaled org, the executive move is to make the trend visible and owned: org-level reliability signals someone is accountable for, and deliberate investment (platform, standards, capacity) rather than exhortation to try harder. The executive's other irreplaceable role is protecting the culture at maximum stakes: when a flagship launch fails publicly at scale and the review threatens to become a blame exercise, executive leadership means modelling blamelessness precisely when the pressure to find a culprit is strongest — including owning the executive-level decisions that contributed. Everyone watches what happens after the worst incident; that moment sets the culture more than any policy.
Strong judgment looks like: org-level ownership of reliability trends with real investment behind it; visibly blameless leadership after the biggest failures; sustainable on-call as a stated organisational commitment.
Common pitfalls: discovering reliability decay only when customers do; letting the worst incident become the moment blamelessness died; treating operational load as each team's private problem; funding features while reliability debt compounds.
Self-check. Associate: why mitigation before root cause? Professional: a stakeholder demands names in the post-mortem — how do you hold the line, and how is blamelessness different from no accountability? Expert: why does the executive's behaviour after a public failure matter more than the incident policy?
2.4 Managing scope, risk, and dependencies
Most delivery slips come not from slow coding but from unmanaged scope, surprise risks, and dependencies — and, at altitude, from status that stops being true. The universal disciplines: defend scope by naming additions and trading them against the date; make risk explicit and attack the highest-uncertainty items first; treat a dependency the other party hasn't confirmed as not-a-plan; and match deliberation to reversibility (one-way vs. two-way doors). What altitude adds is that the facts themselves arrive filtered: the higher you sit, the more your risk management is really information-system management.
At Associate — the team's scope, risks, and dependencies
Scope creep is the silent accumulation of small additions that sink a timeline — name them and trade them. Keep a lightweight, explicit view of what could go wrong and de-risk the biggest unknowns first. Confirm cross-team dependencies with the other team, early, and track them.
Strong judgment looks like: scope traded, not absorbed; biggest unknowns attacked first; dependencies confirmed explicitly; deliberation matched to reversibility.
Common pitfalls: silently absorbing additions; keeping risks in your head until they materialise; assuming another team will deliver on your timeline; agonising over reversible calls while rushing irreversible ones.
At Professional — the system between teams
The Professional's first job is ground truth. When a program spanning four teams is three weeks from a committed launch and you learn one team is two months behind and has been masking it in status reports, the first move is to get ground truth directly, then re-baseline the plan and take a revised commitment with options to stakeholders. The masking is a real problem — but it is addressed after the delivery reality is stabilised, and addressed as a question about why the truth felt unsafe to report. Cross-team delivery reviews exist for exactly this: their purpose is to surface risks and dependencies while they are still cheap, not to perform status.
The second job is boundaries. When two teams repeatedly block each other — releases breaking integrations, blame flowing in both directions — the root-level fix is ownership and contract at the boundary: explicit interfaces, contract tests, clear responsibility, not mandated goodwill. The same instinct generalises: coordination cost is genuinely reduced by clearer ownership and interfaces, decoupled architectures, and fewer shared surfaces — not by adding coordination meetings, which mostly convert engineering time into calendar time. Duplicated work discovered late (two teams unknowingly building overlapping solutions) is not a communication moral failure; it is a missing shared view of what is being built — fix the portfolio visibility. Dependencies across teams become manageable when they are visible: a shared, maintained map reviewed on a cadence. And key-person risk is a dependency like any other: a critical project resting entirely on one engineer's context is a plan to be surprised — spread the context deliberately (pairing, documentation, rotation) before, not after, it hurts. External vendors get the same treatment as internal teams, with less trust: when a vendor slip blocks two of your teams, first establish impact and mitigation options, then escalate with the vendor and communicate the revised picture — hoping is not a strategy.
Strong judgment looks like: going to ground truth when status smells wrong; fixing boundaries with contracts rather than meetings; a maintained cross-team dependency map; treating concentration of context in one head as a risk to engineer away.
Common pitfalls: managing by status report; punishing the masked slip before stabilising the delivery; prescribing "more communication" for boundary failures; discovering vendor risk at the deadline; celebrating the hero who is also the single point of failure.
At Expert — managing the information system
At organisational scale, the executive's scarcest commodity is true information, and the characteristic failure is structural: every team reports green while the flagship program is visibly late — and the truth surfaces first in an exec review. The broken thing is not the teams; it is the reporting system, which has learned to optimise for reassurance. The fix is systemic: status defined by objective criteria rather than sentiment, reviews that examine evidence rather than colour, and — above all — visible safety for bad news. The same disease has a chronic form: when too many initiatives are "yellow" and you cannot tell which are genuinely at risk, the underlying fix is explicit, shared risk criteria — what yellow means, what triggers red, what escalation each state demands. And it has an interpersonal form: a critical program is in trouble by every indirect signal, but the responsible VP keeps reassuring you. Respect the VP; verify anyway — go look at the evidence, because reassurance is not data. An executive ensures bad news arrives in time by rewarding its bearers, asking for it explicitly, and maintaining more than one channel to reality.
Expert dependency management is organisational. A company-wide initiative spanning your org and two peer orgs that has no single owner will drift indefinitely — the move is to force the ownership question: one named, accountable owner with authority across the boundary. When two directors' organisations must integrate but their incentives and timelines conflict, the executive unblocks it at the level where the conflict actually lives — aligning the incentives and priorities you control — rather than urging the directors to cooperate harder against their own goals. And when delivery friction keeps recurring at the same boundaries despite process fixes, consider that the structure is the problem: chronic boundary friction is often Conway's Law presenting a bill, and the durable fix may be organisational design, not another working group.
Strong judgment looks like: engineering the reporting system so green means green; verifying critical programs against evidence, not reassurance; forcing single ownership onto cross-org work; fixing incentive conflicts at the level that owns them; reading chronic friction as a structural signal.
Common pitfalls: running the org on watermelon status (green outside, red inside); accepting a confident VP's word for a program you have independent reasons to doubt; letting cross-org initiatives drift ownerless; process-patching a boundary the org chart itself created.
Self-check. Associate: why is an unconfirmed dependency not a plan? Professional: a team masked a two-month slip — what do you do first, second, and why in that order? Expert: all teams report green but the program is late — what exactly is broken, and why won't better dashboards alone fix it?
2.5 Process selection — the lightest structure that works
Process exists to serve delivery, not the reverse. The universal competency is choosing the minimum structure that solves the actual problem — enough to coordinate and create predictability, not so much that it becomes ceremony. The diagnostic question at every altitude is "what problem is this process solving, and is it still solving it?" Adding process is easy and removing it is hard, so the bias runs light — and structure should scale with the situation, not with fashion.
At Associate — the team's process
Treat practices — standups, retros, estimation rituals, frameworks — as tools to adopt, adapt, or drop based on whether they help this team now. Prune zombie ceremonies. A two-person prototype and a fifty-person platform need different amounts of structure.
Strong judgment looks like: process adopted to solve a named problem; rituals pruned when they stop earning their cost; practices adapted, not followed dogmatically.
Common pitfalls: heavyweight frameworks adopted because they're standard; zombie ceremonies; equating more process with more rigour; big-company process on a tiny team.
At Professional — standards where teams meet
At department scale the question becomes what to standardise and what to leave alone. The durable answer: standardise where teams meet — interfaces, an org-level quality bar or definition of done (whose purpose is a consistent floor where work crosses team boundaries, so one team's "done" doesn't become another team's incident), shared reporting language — and leave team internals to teams. Cross-team cadences must earn their cost like any process: a department delivery review that surfaces risks and dependencies is worth its hour; one that performs status is not. More coordination meetings do not reliably improve throughput — past a point they consume the capacity they were meant to protect.
Strong judgment looks like: a small set of standards at the boundaries; team autonomy inside them; cross-team rituals judged by the risks they surface, not the attendance they command.
Common pitfalls: standardising team internals (tools, ceremonies, style) while boundaries stay chaotic; meeting inflation as the answer to every coordination failure; a "definition of done" nobody enforces at the seams where it matters.
At Expert — the operating cadence
The Expert owns the org's operating system: the rhythm of planning, review, and escalation through which the whole organisation senses and responds. When quarterly planning consumes weeks and produces a plan that is stale within a month, the cadence is inverted — fix it with lighter, rolling planning against stable priorities and frequent small corrections, rather than a bigger annual ceremony. A sound executive cadence includes a regular, evidence-based review of the portfolio, explicit escalation paths with known triggers, and time actually reserved for correction — because at organisational scale, more detailed central planning does not improve execution; responsiveness does. The balance to strike is aligned autonomy: direction, priorities, and boundary standards set centrally; methods left to teams.
Two truths discipline the Expert band. First, the executive does not personally drive even the most critical program — the moment they do, they stop running the system that runs everything else; their role is to set direction, keep the environment unblocked, and hold directors accountable for execution. Second, measure outcomes, not motion: when velocity metrics look healthy but customer outcomes are flat, the metrics are measuring activity — Goodhart's Law in action — and the fix is to point measurement (and the cadence built on it) at outcomes. What makes execution resilient at scale is none of the artifacts and all of the system: clear owners, real priorities, early-warning information flows, and enough slack to absorb the surprise that is always coming.
Strong judgment looks like: a light, rolling cadence that stays current; central direction with local method-freedom; measuring delivered outcomes; building the system that executes rather than executing personally.
Common pitfalls: planning theatre — weeks of ceremony for a stale artifact; centralising methods instead of direction; dashboards of healthy activity over flat outcomes; the executive as the org's most senior program manager.
Self-check. Associate: what question should you ask of any ritual? Professional: what belongs in an org-wide standard and what should stay team-local — and why is the boundary the answer? Expert: why does more detailed central planning fail at scale, and what should an operating cadence optimise for instead?
Key takeaways
- Prioritisation scales from protecting one team's focus to a single ranked view across teams to portfolio governance — at every altitude, fewer things finished beats many things started, and the trade-off is surfaced, never absorbed.
- Honest commitments keep their anatomy at scale: estimate ≠ commitment, ranges over false precision, re-forecast early — from a team's sprint to a staged, checkpointed commitment to the board. Over-commitment and sandbagging are the same calibration failure.
- Incidents need command, then blameless system-fixing; at altitude the job becomes defending that norm under stakeholder pressure and modelling it after the org's most public failures, with reliability owned as an org-level trend.
- Scope/risk/dependency management becomes information-system management: ground truth over status reports, contracts over coordination meetings, single owners for cross-org work, and structural fixes for chronic boundary friction.
- Process stays minimal at every altitude: team-level pruning, department standards only at the boundaries, and an executive cadence built for responsiveness — aligned autonomy, outcomes over motion.