How to Build a Multi-Investigator Team Plan that Reviewers Actually Trust

Some of the most consequential projects I've been part of had to operate across locations to access the data and populations that actually mattered, including veterans, children, and communities that don't fit neatly within a single institution's catchment area. That kind of reach is often the science. And it's also where teams come apart.

You have the science. You have the collaborators and the institutional support letters. But somewhere between your aims page and the review panel, the team stopped being convincing. Not because the science was weak. Because the team didn't look like it could actually execute together.

Reviewers read collaboration plans for one thing: evidence that these people have figured out how to work across boundaries. Not just that they're willing to. That they've done the structural work to make it possible.

Most teams haven't. Reviewers know it the moment they see the plan.

THE REAL PROBLEM UNDERNEATH

Working across disparate labs and locations creates blind spots that assembled teams rarely name in advance. Having explicit conversations about data sharing, cost structures, and ownership across sites gets complicated fast — especially when your populations are vulnerable, and your IRB agreements pull in different directions. Funders can tell when those conversations haven't happened. The plan reads like coordination was assumed rather than designed.

That's often when teams come to me, surprised at the initial score, trying to figure out what went wrong.

What the research on team science consistently shows is that planning for interdependencies — and actually discussing how coordination across distance and disciplines will work — changes what becomes visible to study sections. Needs like shared dashboards, or funds for postdocs to travel between sites, or a shared data governance agreement: when these integrating practices are named in the proposal rather than implied, reviewers can see and weigh the effort. The absence of that specificity reads as a team that hasn't done that thinking yet.

ASSEMBLED VS. INTEGRATED

There's a difference between a team that is assembled and one that is integrated, and it's the difference that moves scores.

An assembled team has the right people. An integrated team has built the shared language, the decision architecture, and enough trust infrastructure to move science forward when disciplines collide — which they will.

Reviewers can't always name what they're responding to. But they feel it in the proposal. It shows up in small things: how the team describes handling disagreement, whether authorship is addressed directly, whether the management plan reads like a real operating system or a compliance document written the week before the deadline.

The signal isn't the credentials. It's the evidence that the team has already done the work of becoming a team.

WHAT INTEGRATIVE LEADERSHIP LOOKS LIKE ON THE PAGE

A scientific and management plan changes when Integrative Leadership is actually practiced rather than listed as an intention. The difference is legible to reviewers even when they can't articulate why.

Capacity Within is what the PI brings: the individual leadership capacity to hold the vision and manage relationships when the science gets complicated.

Capacity Across is what the team has built, the integration infrastructure that makes genuine collaboration possible rather than assumed.

Both have to show up in the plan. A strong PI without an integration infrastructure reads as a single-investigator grant with extra names. Integration infrastructure without a PI who can actually carry it out reads as governance that nobody will use under pressure.

WHAT THIS MEANS FOR YOUR REVISION

Building reviewer trust isn't about adding more credentials or more pages. It's about demonstrating that your team has already done the work of becoming a team — before the funding arrives.

That work has a few specific components: a decision architecture that names who owns what, a conflict protocol that anticipates friction, a credit and authorship framework that reflects how work actually flows, and a shared scientific language that bridges disciplines without flattening them.

None of this is soft. All of it is about initial conditions, including what the team has already put in place, rather than what they intend to figure out later.

If your multi-site proposal is coming up, this is where the score moves. No more pilot data. Not stronger biosketches alone. What will matter is evidence that your team is prepped to operate as an integrated unit.

That's what reviewers are looking for. And it's buildable before you submit.