Delivery Is a Discipline, Not a Date

Ask most organisations what delivery means and you will be shown a date. A milestone on a plan, a quarter on a roadmap, a countdown that engineering either hits or misses — delivery as a calendar outcome, something that happens to a team rather than something a team is skilled at. In part 2 I unpacked the technical quarter of my competency framework; this part covers the discipline I weighted second-highest, at 18 points — and the first thing the weight asserts is that the calendar view is wrong. Delivery is not a date. It is a set of four trainable skills, and engineers who lack them miss dates for reasons no deadline can fix.

Eighteen points for a verb

Delivery, as the framework defines it, is the discipline of converting engineering capability into shipped value. It is the difference between an engineer who can build and an engineer who does build — reliably, incrementally, in a way that creates value at every step rather than only at the end. The 18 points make it the second-largest discipline in the model, behind only Engineering Craft's 25, and the gap between the two numbers is smaller than most competency models would dare make it.

The reason is blunt. Organisations do not hire developers to write code; they hire developers to deliver outcomes. An engineer who writes excellent code but cannot break a project into shippable increments, cannot order work against its dependencies, and stalls whenever requirements are unclear is — in the only sense the organisation cares about — ineffective. The craft quarter measures what you can build. This discipline measures whether anyone ever benefits.

Four sub-disciplines, weighted across their own 100 points:

Notice what is absent. There is no sub-discipline for estimation accuracy, none for velocity, none for hitting dates. That is deliberate: those are outputs. When the four skills above are strong, the dates take care of themselves; when they are weak, no amount of date-pressure produces anything but overtime and apology.

Increments are the outcome, not a habit

Incremental Value Delivery takes the largest share, 30 points, because it is the ultimate measure of delivery effectiveness — the thing the other three skills exist to make possible. The principle behind it is the one the Agile Manifesto put at the centre of its thinking in 2001: working software, delivered frequently, is the primary measure of progress. Two decades on, the industry has absorbed the vocabulary and kept the batch sizes.

Because the skill is not “commit often”. It is structuring work so that each increment is independently valuable — a thin vertical slice a user can touch, not a horizontal layer that only pays off when the last layer lands on top of it. The distinction shows up the moment something goes wrong. A team three weeks into a six-week horizontal build has nothing; a team three weeks into vertically sliced work has half the feature live and feedback already arriving. Engineers who batch work into large releases are not just slower to deliver value — they carry more risk per release, wait longer for feedback, and lose the ability to change direction cheaply. Engineers who slice thinly keep all three under control at once.

I rate this skill by looking at what an engineer does with a piece of work too big to ship whole — which, conveniently, is the next sub-discipline.

Breakdown is where delivery is won

Work Breakdown carries 25 points, and it is the delivery skill I probe hardest when assessing, because it is where good delivery is actually won or lost — weeks before any date is at risk. The skill is looking at a feature or a project and producing the concrete steps to build it: each one well-defined enough to hand over, small enough to estimate honestly, and sequenced so that risk is confronted early rather than discovered late.

Take an invented but recognisable project: replacing a home-grown notification system with a managed service. A weak breakdown produces four tasks — “build adapter, migrate templates, switch over, decommission” — each of which is secretly a fortnight of unknowns. A strong breakdown looks different: prove the managed service can deliver the one template with tricky formatting first, because that is the assumption the whole migration rests on; run the two systems in shadow mode next, because that converts an irreversible cutover into a comparison you can watch; migrate the low-traffic notifications before the critical ones; keep the rollback path alive until the numbers have held for a fortnight. Same project, same effort — but the second version surfaces the killer risk in week one and ships observable value at every step.

A good breakdown is a risk argument disguised as a task list. That is why it is a competency and not a ceremony: two engineers given the same feature will produce breakdowns of wildly different quality, and the difference compounds through everything that follows.

Prioritisation is a dependency problem

Prioritisation and Dependency shares the 25-point tier, and the pairing of the two words in its name is the insight. Prioritisation without dependency awareness is just preference — a ranked wish list that collapses the first time item three turns out to block item one. The real skill is seeing the graph: which tasks sit on the critical path, which are free to move, where a blocking dependency on another team needs to be raised now because its lead time is longer than yours.

It is also a skill of revision. Priorities set at the start of a piece of work are hypotheses, and new information — a spike that comes back ugly, a stakeholder who reveals the actual deadline, a dependency that slips — should move them. Engineers weak in this sub-discipline treat the original ordering as a commitment and ride it into the ground; engineers strong in it re-plan cheaply and visibly, and can always tell you why the current top item is the top item. Trade-off decisions about scope and sequence live here too: knowing what to cut, and cutting it early enough for the cut to buy anything.

Ambiguity is the weather

Dealing with Ambiguity carries the final 20 points, and I think of it as the resilience skill of the discipline — the one that keeps the other three moving when conditions are poor. And conditions are usually poor. Requirements are incomplete more often than they are complete; priorities conflict whenever more than one stakeholder exists; the technical path is unclear on precisely the projects that matter most. Ambiguity is not an exceptional condition to be escalated and waited out. It is the weather, and this sub-discipline is the ability to work in it.

The skill has a concrete shape. Asking clarifying questions early, and asking the sharp ones — “what should happen to in-flight notifications during cutover” — rather than generic requests for more detail. Making reasonable assumptions explicitly and writing them down, so a wrong assumption is a fast correction instead of a buried defect. Time-boxing exploration so that not-knowing has a budget. And the judgement call that sits underneath all of it: knowing when you have enough information to decide, and when another day of investigation is worth more than another day of progress. Engineers weak here oscillate between the two failure modes — paralysis in the fog, or confident sprinting in the wrong direction. Engineers strong here are the ones your hardest projects quietly get routed to.

Why the weights fall 30-25-25-20

The internal ordering tells the discipline's story in four numbers. Incremental Value Delivery leads because it is the outcome — the observable, user-facing result the discipline exists to produce. Work Breakdown and Prioritisation share the second tier because they are the two operational skills that make increments possible: one creates the pieces, the other orders them. Dealing with Ambiguity anchors the set because it is a condition on the other three rather than a producer of value in itself — nothing ships because you handled ambiguity well, but everything stalls when you handle it badly.

Weighted together with the craft quarter, the model now covers 43 of its 100 points, and every one of them is about work: building it and shipping it. The next 25 belong to something else entirely — the two disciplines that determine whether a group of individually capable engineers is actually a team. Next: The Human Disciplines — Feedback and Collaboration.