Project Management for Engineering Projects

A director's question is a different question

A team lead asking "are we on track" is asking about one sprint board, and a good tracker answers that well on its own. An engineering director or VP asking the same question is asking something structurally different: are the eight teams, running eight boards, on eight different cadences, collectively going to land the roadmap the board was told about, and if not, which team is the actual constraint.

That question doesn't get answered by opening eight tabs and eyeballing eight burndown charts, which is roughly how it's still done at most companies past a certain size. It gets answered by treating "how is engineering doing" as its own view, built from the same data every individual team already has, rather than as a manual synthesis exercise someone runs the night before a leadership review.

The failure mode isn't usually that any one team is badly run. It's that eight well-run teams can still add up to a department that's quietly off track, and nobody notices until the rollup that reveals it happens to get built.

It also tends to be a political problem as much as a technical one. Every team lead has a reasonable-sounding explanation for their own numbers, and without a rollup built from consistent, comparable data, leadership is left weighing eight different narratives against each other instead of looking at eight measurements built the same way.

That's not a knock on team leads, it's a structural problem with asking people to self-report on their own performance and then comparing the reports. Even completely honest self-reporting varies in what it counts as "on track," and those small definitional differences compound into a leadership view that's really eight different opinions wearing the same format.

Rollup, not just aggregation

The distinction matters. Aggregation is stacking eight teams' status updates into one document. A rollup is a forecast built from the same measured velocity each team's own board is already tracking, combined into one number for the initiative that spans them, so the answer to "will this land" comes from throughput data, not from whichever team lead's optimism made it into the deck this time.

Each team keeps its own board, its own sprint cadence, its own WIP limits, a platform team and a product team rarely benefit from being forced into identical process. What rolls up is the outcome: cycle time, velocity, and a forecasted date per initiative, visible without anyone leaving their own team's context to go check.

The GitHub sync keeps this honest at the source: cards close on merge across every team's repositories, so the rollup is built from what actually shipped, not from what eight different teams separately reported as done in eight different standups. That's the real change a director gets from ShipSprint: a department-wide "done" that means merged code, not eight optimistic standup updates stitched into one deck.

Finding the actual constraint, not just the loudest team

When a cross-team initiative is behind, the instinct is usually to ask whichever team is complaining loudest what they need. That's often the wrong team to ask, the loudest team is frequently the one downstream of the actual bottleneck, blocked on a dependency from a quieter team that hasn't said anything because nobody's asked them yet.

A rollup built from real throughput data surfaces this directly: if Team A's velocity is fine but their forecast keeps slipping, the constraint is very likely something they're waiting on, not something they're failing to do. Following the dependency chain from there, rather than the volume of complaints, usually finds the actual bottleneck faster.

This is the specific value a department-level view adds over eight individually well-run teams: it makes the relationships between teams visible, not just each team's own internal health, which is the level at which most cross-team initiatives actually go wrong.

It also changes what a leadership review is actually for. Instead of eight teams presenting eight updates in sequence, most of which have nothing to do with each other, the conversation can go straight to the two or three genuine dependencies that determine whether the quarter's cross-team work lands, which is a shorter meeting and a more useful one.

What a department-level rollup should actually tell you

• Which cross-team initiative is behind its forecast, and which specific team's throughput is the constraint
• Whether a slip is new this week or has been quietly compounding for a month under a status update that kept saying "on track"
• How much department capacity is actually going to roadmap work versus production support, across all teams combined
• What shipped this week, department-wide, based on merged code rather than eight separate standup reports

None of this replaces a team lead's judgment about their own team. It just means leadership isn't reconstructing the department's real status from memory and good faith the night before a board update.

The single-team view, still underneath

Nothing here replaces how any one team actually plans and runs its sprints, that's the same mechanics covered in the software development use case, and every team keeps that view for itself. This is the layer above it: what a director or VP sees when the question is about the department, not any one team's board.

Every workspace is an isolated tenant with two-factor authentication and a logged audit trail of admin actions, worth a look on the security page before rolling this out past a single pilot team to the rest of engineering.