Delivery Manager

With one team, nobody needs this job. Everyone can see who is stuck on what from across the room, and a single meeting settles the schedule.

The trouble starts around the fourth or fifth team. Each team runs fine inside its own board — items get picked up, finished work moves across, the cycle ends with a look back. But work doesn't stall inside a team. It stalls between teams. The frontend team waits on an API, the API team waits on a security review, and the security review is pinned to an outside vendor's calendar. None of that waiting appears on anybody's board, because from each team's point of view it isn't their item.

The result shows up three days before launch. One side says they finished and handed it off last week; the other says they were told to expect the result today. Both worked in good faith. Nobody had looked at the two schedules side by side. A delivery manager exists to fill that gap. Instead of making one team faster, the job spends its hours finding and removing the waiting and mismatch that collect between teams.

Half the day goes into assembling many teams' states into one picture, and the other half into untangling the places where that picture doesn't line up.

1. Skim the team boards in the morning, looking only at columns that changed since yesterday. Anything sitting in the same place for three days gets flagged on the spot.
2. Clear blockers — work that can't move because of some other condition. Most of them are a decision nobody made, an access permission nobody granted, or a handoff from another team that hasn't arrived. The move is to connect it to whoever can resolve it and pin down a deadline for the answer, rather than fixing it personally.
3. Update the schedule. Fold in whatever changed today and compare the work remaining against the days remaining before the next milestone, which is a checkpoint set partway through to verify progress.
4. Surface slippage early. If the math says a date two weeks out will land four days late at the current pace, say so that day. Being late costs less than being told late.
5. Send stakeholders a written status — the people affected by the outcome or able to affect it, which here means leadership, sales and support. Split it into what is on track and what is at risk.

The mix shifts as launch approaches. On deploy day, the whole day goes to sequencing: which team ships first, and how far each step can be rolled back if something breaks, written down in advance and followed in that order.

Almost nothing in this job is decided alone. It's mostly pulling other people's decisions out of them on time, so the question changes with who is across the table.

With the product manager the subject is scope. When a schedule gets tight there are only two moves — push the date or cut the scope — and choosing what to cut belongs to the product manager. The delivery manager supplies the numbers: drop this and four days come back. When that conversation happens too late you get scope creep, where the boundaries expand without anyone agreeing to it until the plan is twice what it started as.

With engineering leads the subject is remaining capacity. The output of capacity planning — how much the team can actually absorb next cycle — feeds straight into the schedule. Five people for two weeks looks like 50 person-days, but subtract vacation, interviews and time on loan to another team and 41 is what's left. A schedule built without that number is already wrong on day one.

With quality assurance the subject is verification time. Squeezing testing from two days to half a day because development ran late keeps the launch date and returns as an incident the following week.

Coordinating with outside parties lands here too. Customer security reviews, external audits and app store reviews all move at a pace nobody internally controls, which is why they have to be started ahead of the internal work rather than alongside it.

"Two teams have deploys scheduled on the same day in week three. Can one of them move a week out?"

A proposal to spread out work that piled onto one date, so the risk spreads with it.

"We can hold the date. Localization comes out of this release and goes into the next one."

Putting the trade — what gets given up to keep the date — on the table before it's forced.

"The only thing blocking us is one reply from the payments team. If it isn't in by this afternoon I'm escalating."

A single wait is holding the whole schedule, so it goes up the chain through the agreed process.

Pagedeck has no delivery manager yet. When there were two teams, Mia covered product decisions and schedule coordination together and that was enough. The quarter the enterprise permissions feature shipped showed the limit. Backend, frontend, quality assurance and security documentation were all sequenced differently, the customer's contract date was fixed so the launch couldn't move, and while Mia was buried in product decisions and opening the schedule every third day, the security review slipped a week on the vendor's side without anyone flagging it.

What Grace decided afterward wasn't to hire someone. It was an order of operations: twice a week, the four teams' states go into one table, and anything marked red gets an owner assigned that same day. The dedicated role appears later, once launches are frequent enough to occupy someone full time.

The most common reading is that this is the person who nags about dates. Asking about progress daily and pointing at slipped items makes that easy to believe. Nagging pulls no schedule forward, though. Tell a team already working at capacity to go faster and what comes back is optimistic reporting, not speed. The actual work runs the other way: find what's stuck and clear it, remove the points where two teams wait on each other, and get undeliverable dates admitted early. Run the role as a nagging seat and the reports look better than reality while the real state surfaces only just before launch.

Treating a slipped date as this person's failure is the other one. Slippage itself comes from development difficulty, outside calendars, an incident that arrived without warning — causes this seat doesn't control. The measure of the role isn't that nothing slips but how early the slip was made visible. Four days of delay known two weeks out can be absorbed by cutting scope or moving people. One day of delay known the night before is simply an accident.