How I Run Delivery, From Request to Done

What this is

The cases on this site describe specific decisions. This one describes the recurring rhythm underneath all of them: what actually happens between a request arriving and work being done.

The context is a platform built as independently-owned microservices — every service with its own team, its own technical lead, and its own priorities, across more than five service teams. No engineering team reported to the program, and I did not own the technical work. What I owned was the cadence that turned requests into committed delivery, and the visibility that kept those commitments honest.

That cadence ran against real throughput, not a quiet roadmap: a major service release every month, near-daily hotfixes and updates on top of it, and one or two customer game launches landing each month against their own separate release dates. The rhythm had to hold while several unrelated delivery streams were in flight at once.

How I operated

• Intake is a conversation about intent, not a ticket queue. Requests arrived from Product, from customer-facing teams, and from customers directly. Before anything was planned, I established what the request was actually for, what problem it solved, and what it was worth relative to work already committed. A request that could not be explained in those terms was not ready to be planned.

• Work was broken down until each piece belonged to exactly one team. A single feature routinely crossed several independently-owned services, so I took each request apart until every piece sat inside one team’s scope, with a clear interface to the pieces on either side. That mapping is what made the work estimable at all — and it is where most of the coordination difficulty actually lived, not in the tracking that followed.

• Estimates came from the engineers doing the work. I worked directly with engineers and their leads on what the work involved, what was uncertain, and what a realistic timeline looked like. I did not accept a date handed down from above and work backwards to justify it, and I did not compress an estimate a team did not believe.

• Commitment meant an owner and a date, in writing. Each piece of estimated work was converted into a committed item with a named owner and an expected finish date, tracked in Jira. A commitment without a named owner was treated as unowned work, not as an assumption that someone had it.

• The rhythm was two-week sprints with daily standups. Sprint planning set what each team was taking on and confirmed the dependencies between them. Daily standups were for reality, not reporting: what moved, what is blocked, and what changed since yesterday. Backlog refinement kept the next sprint plannable, and milestone tracking kept the longer arc visible to everyone whose work depended on it.

• Dependencies and risks lived in one register, not in people’s heads. Each piece of work carried a dependency and risk record — the RAID items: what depended on what, what was assumed, what was already a live problem, and who owned each. Dependencies were named with an owner on both the producing and consuming team and followed until closed, because the interface between two teams was the most likely place for delivery to stall when each team was individually on track.

• I tracked the critical path, and treated a slip on it differently from float elsewhere. Work that sat off the critical path could move without threatening the date; work on it could not. When the gating chain slipped, the response was not to absorb it quietly into the plan — it was to re-sequence, re-estimate with the owning team, and tell whoever’s date had just changed. Reporting rolled up the worst dependency rather than the average, so a single red chain could not be averaged away into a green programme.

• Capacity conflicts were surfaced before they became missed dates. I managed resourcing in Jira across the service teams — which engineers had capacity for committed work, and where a team was overcommitted. The point of watching this continuously was to raise it while it was still a planning conversation, rather than at the end of the sprint when it was already a broken commitment.

• Re-estimation was normal, not a failure. Scope shifted mid-cycle, a team’s capacity changed because of an unrelated priority, or a dependency turned out to be tighter than assumed. The response was always the same: go back to the engineers who owned the affected work, get a real re-estimate, and update the timeline before the gap became a surprise — never after.

• I installed a coordination rail rather than running a personal process. The change-request intake started as something I needed answered — whether a specific item was genuinely reviewed, QA’d, and accounted for before it shipped — and became the standing route every production and infrastructure change went through, including after the flow stopped depending on me chasing it. A mechanic that only works while one person operates it is not a system.

• A risk was only closed when the mitigation actually landed. The sharpest instance was a feature the customer wanted released immediately while one item inside it had not been tested. The risk owner’s answer was no — not “later”, and not a quiet ship-and-hope. What I negotiated instead was a delivery in slices, so each slice could be validated on its own before the next went out, rather than sending everything at once and calling it tested. A register only earns its keep if something reaches the closed state because evidence arrived, not because time passed.

• Status had to mean real validation. A task was not done because development was finished. I coordinated with QA throughout rather than only at the end, so that the status of a piece reflected what had actually been tested, what had not, and what was still open. The recurring failure mode I was working against is the one where a green status turns red on the due date with no warning.

• A short list of artifacts carried the whole thing: the broken-down plan in Jira, the committed item and its owner and date, the dependency list between teams, and — for anything touching a release — the change-request record that confirmed the specific item was reviewed, QA’d, and accounted for before it shipped. Nothing depended on anyone remembering a conversation.

Where it got harder

The rhythm was not the hard part. The hard part was that every team had its own lead, its own priorities, and legitimate reasons for the sequence it chose — and none of them worked for me. When a dependency slipped, or a team’s capacity was consumed by work I had not planned, the commitment did not bend back into place on its own. It had to be renegotiated with the people who owned the work, honestly, and then reflected in the plan the customer and leadership were reading. That is a continuous conversation, not a status report.

Outcome and value

Requests arrived as intent and left as work that engineering had estimated, owned, and dated — visible across teams that had no shared plan to default to. Capacity problems and dependency slippage surfaced during planning and standup rather than at the deadline, which is the difference between adjusting a plan and explaining a miss. Because status tracked real validation rather than ticket state, the picture leadership and customers acted on was the real one.

What this shows about how I operate

Delivery is a rhythm, not a plan document. It looks unremarkable when it works — a request is clarified, broken down, estimated by the people who will do it, committed with a name and a date, and then checked daily until it is genuinely done. What makes it hold inside an organization where nobody reports to the program is that the commitment is real because the people doing the work made it and someone kept verifying it, not because anyone could compel it.