Driving Cross-Team Projects

The project that earns someone a staff promotion is usually a cross-team one: a migration, a new platform, a reliability push, something that needed five teams to move together and would have failed without someone holding it together. Leading these is a distinct skill, and the surprising thing engineers discover the first time is that the engineering is the easy part. The hard part is people: getting teams who don’t report to you, with their own priorities, to commit and deliver in a coordinated way, with no authority to make them. This lesson is about doing that well.

Start With a One-Pager, Before Any Code

The biggest lever on a cross-team project is a document written before the work starts: a one-pager (or brief) that acts as the contract keeping everyone pointed the same way.

The sections that matter:

• Problem & why now: the one-paragraph case. Why this, why now, and what happens if you don’t do it. This is what gets teams to care enough to prioritise it.
• Success criteria: measurable outcomes. “p99 checkout latency under 500ms”, not “make checkout faster”. Vague success criteria guarantee disputes at the end about whether you succeeded.
• Scope & non-scope: what’s in, and explicitly what’s out. The non-scope is your single best defence against a cross-team project quietly doubling in size as every team adds “while we’re at it, can you also…“.
• Teams & owners (RACI): who is Responsible (does the work), Accountable (owns the outcome, exactly one per area), Consulted (gives input), Informed (kept in the loop). The most important rule: one Accountable owner per area. When two people are accountable for the same thing, nobody is.
• Milestones & sequence: the few real checkpoints, in order, with rough dates, and the dependencies between them called out. Not a Gantt chart with 200 tasks, the handful of milestones that matter.
• Risks & unknowns: the top three risks, each with an owner and a mitigation. Naming the scary things early is a sign of a serious plan, not a weak one.
• Decisions needed: what you need from leadership now to unblock the project, with a date. This turns “we’re blocked” into a specific, answerable ask.

A good one-pager prevents something like 90% of cross-team confusion, because most confusion comes from people having different mental models of the goal, the scope, or who owns what. Write it down, circulate it for explicit agreement (not just silence, actual “yes, my team is in”), and keep it updated as the single source of truth as the project evolves.

A reusable project one-pager template

# [Project name] — one-pager

**Driver:** you · **Status:** ... · **Last updated:** ...

## Problem & why now
One paragraph: the problem, why it matters, why now, and the cost of not doing it.

## Success criteria
- Measurable outcome 1 (with a number and a date).
- Measurable outcome 2.

## Scope
- In: ...
## Non-scope
- Explicitly out: ... (this is what stops the project doubling)

## Teams & owners (RACI)
| Area | Responsible | Accountable (one!) | Consulted | Informed |
|------|-------------|--------------------|-----------|----------|
| ...  | team/person | one owner          | ...       | ...      |

## Milestones (the few that matter)
1. [Milestone] — target date — depends on: ...
2. ...

## Top risks
| Risk | Owner | Mitigation | How we'll detect it |
|------|-------|-----------|---------------------|
| ...  | ...   | ...       | ...                 |

## Decisions needed from leadership
- [Decision] — needed by [date] — because [blocks what].

The Critical Path Is People, Not Code

Here’s the mental shift that separates engineers who lead cross-team projects from those who just contribute to them. When you plan a project, your instinct is to estimate the engineering. But on a multi-team effort, the engineering is rarely where the time goes:

The time sinks on cross-team work, roughly in order:

1. Waiting on another team’s priorities. Your project needs team B to do a piece, but it’s not on their roadmap this quarter, so you wait. This is the single biggest source of delay, and it’s invisible on an engineering estimate.
2. Unclear ownership. “Who decides this?” “Whose job is that?” Ambiguity about ownership stalls work while everyone waits for someone else to move.
3. Mismatched assumptions discovered late. Two teams each assumed the other was handling the auth piece. You find out in integration, at the worst time.
4. Review and sign-off cycles. Security review, architecture review, legal, each a round-trip of days.
5. The actual engineering. Often the smallest chunk, and the one everyone focused on when planning.

The implication for how you spend your time as the driver is profound: your real job is to attack the people-and-dependency problems, not to write the code. Specifically:

• Surface dependencies early. Map out who needs to do what for whom, and find the cross-team dependencies before they become blockers. The one-pager’s milestone/dependency section is where you do this. A dependency found in week one is a conversation; found in week eight it’s a crisis.
• Get commitments in writing. “Sure, we’ll help” in a hallway is not a commitment. A commitment is their lead agreeing, in writing, that the piece is on their roadmap for a specific time. Get it, kindly but explicitly. Vague verbal agreement is how projects slip.
• Keep ownership unambiguous. One accountable owner per area (from the RACI). When something falls in a gap between teams, assign it to someone explicitly rather than hoping it gets picked up.
• Unblock relentlessly. This is the day-to-day of driving: notice what’s stuck, find out why, and clear it, chase the decision, broker the conversation between two teams, escalate the dependency that’s slipping. Much of a staff engineer’s value on a project is being the person who will not let things quietly stall.

The code, by comparison, mostly takes care of itself, the teams are capable engineers. What they can’t do without you is the cross-team coordination, because no single team has the context or the standing to do it. That’s your job.

Running It: Lightweight and Relentless

A few practices for the running of a cross-team project:

• A short, regular sync of the key owners (not everyone), focused on blockers and decisions, not status theatre. “What’s stuck and who can unstick it?”
• A living status doc (the one-pager, updated) so anyone can see the real state without a meeting. Honest status, including slippage, builds trust; rosy status that later collapses destroys it.
• Escalate early and cleanly (Lesson 7): when a dependency is slipping and you can’t fix it peer-to-peer, raise it to the managers who can, in writing, calmly, with a specific ask. Escalation isn’t failure; letting a project die silently is.
• Celebrate and credit widely. When it ships, make sure every team that helped gets visible credit. You’ll need them next time, and generous credit is how you build the relationships that make the next cross-team project easier.

Pitfalls to Avoid

1. Starting to code before writing the one-pager. The alignment doc prevents most cross-team confusion; write it first.
2. Vague success criteria. “Make it faster” guarantees an argument at the end. Use measurable outcomes.
3. No clear non-scope. Without it, every team adds “while we’re at it” and the project doubles.
4. Two accountable owners (or none). One Accountable per area, or things fall in the gaps.
5. Estimating only the engineering. The critical path is people and dependencies; the code is the small part.
6. Accepting verbal “sure, we’ll help.” Get commitments in writing, on a real roadmap, with a date.
7. Letting blockers sit. Your core job is to unblock relentlessly and escalate early when you can’t.

Quick Recap

• Before any code, write a one-pager: problem/why-now, measurable success, scope/non-scope, RACI (one Accountable each), milestones, risks, decisions needed.
• Circulate it for explicit agreement and keep it as the living source of truth.
• The critical path on cross-team work is people and dependencies, not engineering; the code is the easy part.
• Your real job: surface dependencies early, get commitments in writing, keep ownership unambiguous, unblock relentlessly.
• Run it with a short blocker-focused sync, honest living status, early clean escalation, and wide credit when it ships.

Next lesson: the skill underneath all of this, getting people who don’t report to you to move, influence without authority.