The project management team

When to call this team

Project management is the team for the distance between "we agreed to build it" and "it shipped," which is where most plans quietly go to die. Reach for it when:

• A spec exists but nobody has turned it into tasks anyone can start on Monday.
• Three functions are building one launch and each is working to a different date.
• Estimates keep doubling mid-flight and the retros never explain why.
• Your commit history and your ticket tracker have stopped agreeing with each other.

Each is a coordination failure rather than a work failure. The work is happening. What is missing is the structure that turns it into something that lands on time.

Who shows up

A deliberately small bench, because process is pure overhead right up until the moment it is not, and this team is sized to add only the structure a given job needs:

• Senior project manager, who converts specs into tasks with realistic scope, no gold-plating and no fantasy estimates.
• Project shepherd, who herds cross-functional work to on-time, on-scope delivery.
• Workflow steward, who enforces traceable commits, structured pull requests, and release-safe branching for teams shipping software.

Three worked examples

"Break this spec down." The senior project manager reads the spec and returns a task breakdown with dependencies mapped and effort given as ranges. More usefully, it flags the two or three spots where the spec is silently ambiguous, because that ambiguity is where most overruns are actually born. You get those back as questions now, while they are cheap, instead of as surprises in week three.

"Get this launch over the line." The project shepherd builds the delivery picture across everyone involved: the critical path, who is blocking whom, and the weekly checkpoint that keeps it honest. As the work moves, it catches slippage early, while a slip is still a one-day scope decision rather than a lost weekend for the whole team.

"Our repo history is chaos." The workflow steward audits how changes flow from branch to release, then hands back a branching and PR discipline sized to your team rather than copied from a textbook. Three engineers get three rules, not thirty, because rules nobody follows are worse than none.

What they need from you

The spec or plan as it actually stands, the people involved, and the real deadline with its real flexibility, not the aspirational one. Connecting Linear moves delivery tracking from MEDIUM to HIGH evidence, since the shepherd then reads live ticket state. Connecting Notion or Drive lets the plans live where your team already looks instead of in a chat log.

Hand-offs

This team takes priorities from product (chapter 12) and turns them into delivered work. The status of everything it runs surfaces through /marg:status (chapter 6). And when the real question is whether something should be built at all, that goes back to advisory (chapter 9), because a scope argument is a strategy decision wearing a schedule's clothes.