Cross-functional collaboration: where it breaks, and what fixes it

The definition is unremarkable: a group of people with different functional expertise working toward a common goal. What makes it a distinct management problem is that the members report elsewhere, are measured elsewhere, and speak different professional dialects, so every coordinating act costs more than it would inside a function.

The origin story usually told involves Northwestern Mutual in the 1950s, whose chief executive convened financial, investment and actuarial staff to study what the arrival of computers would do to the business. Two cautions are worth attaching. The company is frequently corrupted into Northwest Airlines in secondary retellings, and even the correct version rests on a business encyclopaedia rather than a primary document. Treat it as a nice anecdote rather than a fact.

The defensible lineage runs elsewhere: through concurrent engineering in late-1980s industrial practice, and in the research literature through Deborah Ancona and David Caldwell's study of 38 new-product team managers in high-technology firms, which identified the boundary-spanning activities that actually predict team performance. Those turn out to be three: vertical communication that shapes how senior management sees the work, horizontal communication that coordinates and gathers feedback, and scanning the environment outside the team. Note what is absent from that list. Internal team cohesion is not one of the predictors.

Behnam Tabrizi's Harvard Business Review piece from June 2015 is the most quoted thing in this field. It studied 95 teams across 25 leading corporations, selected by an independent panel, and found that nearly 75 per cent were dysfunctional, defined as failing on at least three of five criteria: budget, schedule, specifications, customer expectations and alignment with corporate goals. His diagnosis is worth quoting rather than paraphrasing: teams are hurt by unclear governance, by a lack of accountability, by goals that lack specificity, and by organisations' failure to prioritise the success of cross-functional projects.

The 75 per cent is the number everyone repeats and it is the less interesting one. Underneath it is a gradient. Projects with strong governance support, meaning either a higher-level cross-functional oversight team or a single high-level executive champion, had a 76 per cent success rate. Projects with only moderate governance support had 19 per cent. That is a four-fold difference attributable to one structural choice, and it is a choice made before the team is assembled rather than something the team can fix from inside.

The caveat belongs on the page rather than in a footnote, because the field pretends otherwise. This is a practitioner study with no published methodology, no stated selection procedure for the 25 corporations, and no confidence interval. The most-cited statistic in cross-functional management rests on 95 teams described in a short article. Use it as a direction, not a measurement.

For a real measurement, the paper to read is Manuel Sosa, Steven Eppinger and Craig Rowles in Management Science in 2004. They took Pratt & Whitney's PW4098 aircraft engine, decomposed it into 54 components that mapped one to one onto 54 design teams, and built two matrices. The first recorded which components technically depend on each other. The second recorded which teams actually talked to each other. Then they overlaid them.

On 220 of the 569 real design interfaces, some 39 per cent, the two responsible teams were not interacting. In the other direction, 74 of 423 team interactions, about 17 per cent, corresponded to no technical dependency at all: conversation that cost time and coordinated nothing.

The distribution is the finding. Misalignment concentrated significantly across organisational and system boundaries rather than within them. And the mechanism the authors identified is the part worth carrying away: strong interfaces were more likely to be matched by an actual interaction than weak ones, but not across boundaries, because many strong cross-boundary design interfaces were perceived as weak and therefore no planning mechanism was put in place for them. In plain words, the handoffs that break are the ones each side thinks are minor.

Their organisational fix did not work either. Dependencies explicitly written into the programme's Component Requirements Document were still, in the authors' phrase, left unchecked. Their conclusion is the operating instruction for anyone running a boundary: identify and manage critical cross-boundary interfaces without relying on their apparent level of importance as the mechanism for deciding which ones get attention. If you triage interfaces by how important they look, you will systematically miss the ones that break you.

Engineers will recognise the shape of that result immediately. Conway's law says that organisations design systems that mirror their own communication structures, and it is usually invoked as an argument for organising teams around the architecture you want.

Sosa and colleagues measured the same relationship from the other end and found where the mirror cracks. The architecture and the organisation matched well inside boundaries and poorly across them. So the practical version of Conway's law is not that structure determines architecture in general; it is that structure determines architecture at the seams, and the seams are exactly where nobody is looking.

That has a design consequence. If a dependency crosses an organisational boundary, it needs an explicit mechanism, because the informal channel that would have caught it inside a function does not exist across one.

Most advice on this topic reaches for a tool. The research points at conditions instead, and one of them dominates.

Amy Edmondson's 1999 study of 51 work teams in a manufacturing company established psychological safety, a shared belief that the team is safe for interpersonal risk taking, as a predictor of learning behaviour, with learning behaviour in turn mediating the path to performance. Team efficacy did not predict learning once safety was controlled for. Confidence that the team is capable is not the same thing as safety to say something awkward, and only the second one produces the question that surfaces a missing dependency.

For the cross-functional case specifically, Edmondson and Jean-François Harvey's later work on cross-boundary teaming is the better citation, because the boundary changes the problem. Inside a function, the risk of asking a naive question is looking uninformed to peers. Across one, it is looking uninformed to another function, on behalf of your own, which is a materially larger cost and reliably suppresses exactly the clarifying questions the interface needs.

Ancona and Caldwell's three activities are the behavioural half of the same answer. A boundary spanner's job is mostly outward: shaping how the work is seen upward, coordinating sideways, and scanning what is coming. Teams that invested in internal cohesion instead performed worse, which is a useful corrective to the instinct to fix a cross-functional problem with an offsite.

The single most common structural cause in Tabrizi's list is unclear governance, and the cheapest available fix is naming decision roles. Three conventions compete, and they are not interchangeable.

Be accurate about the history, since every page on this topic implies otherwise: RACI has no inventor and no founding document. The lineage runs from linear responsibility charts in the 1950s, through the responsibility assignment matrix of the 1970s, into a labelling convention that PMI's PMBOK Guide eventually codified. What is verifiable is the structure, not the origin story.

RAPID is the one with a real primary source, Paul Rogers and Marcia Blenko's Who Has the D? in Harvard Business Review in 2006, and it is the right choice here for two design reasons. It separates veto rights from advisory input, which RACI's single consulted letter conflates, and it insists on a single decider. Its diagnostic frame also maps directly onto this topic: it names four decision bottlenecks, being global against local, centre against business unit, function against function, and inside against outside partners. The third of those is the whole subject of this page.

The wider question of how much participation a decision needs in the first place, and the models for reaching one, is in collaborative decision making.

Coordination is not free, and the standard remedy for a cross-functional problem, more forums and more people in them, has a measured cost.

Rob Cross, Reb Rebele and Adam Grant reported in Harvard Business Review that time spent in collaborative activities has ballooned by 50 per cent or more over roughly two decades, and that at many companies people spend about 80 per cent of their time in meetings or answering colleagues' requests.

Their concentration finding is the one that gets garbled in retellings, and the real sentence is more interesting than the garble: in most cases, 20 to 35 per cent of value-added collaborations come from only 3 to 5 per cent of employees. A small minority carries between a fifth and a third of the useful collaboration in an organisation. Those are exactly the people you are about to add to another standing forum, and they are the reason the forum will slow down. The general case, and what to do about a calendar in that state, is in meeting overload.

So the fix has to be cheap per interface, or it will not survive contact with the calendars of the people it depends on.

Three mechanisms, chosen because each costs little and each attacks a specific finding above.

Name an owner per interface, not per team. For each dependency that crosses a boundary, one named person on each side who is expected to know its current state. This attacks the Sosa finding directly: an interface with two owners is an interface somebody is looking at, regardless of whether it appears important.

Keep a standing cross-functional decision log. One per programme, not per team, recording what was decided, by whom, and what was rejected. Cross-boundary decisions are the ones most likely to be relitigated, because each function remembers the version that suited it. The fields and the reasoning are in decision log.

Ask the weekly question that surfaces a silent dependency. Not "any blockers", which selects for problems people have already recognised. Something closer to: what did your function decide this week that another function has not heard about yet? That is aimed squarely at the interface both sides think is minor, and it is the cheapest instrument on this page.

Add one more at the end of a programme: a debrief that asks specifically which interfaces were missed. A misaligned interface caught in a debrief is caught before the next programme repeats it, and the alternative is discovering the same seam three programmes running.

There is a version of this problem that is yours alone, and it is worth separating from the team problem, because the fixes are different.

Sosa and colleagues described a coordination failure: the conversation never happened. The version a product manager or a project manager lives is narrower. The conversation did happen, in the engineering sync on Tuesday, and by the time it matters on Thursday in the design review, nobody can reconstruct what was said. That is a retrieval failure sitting on top of a coordination one, and it is the part a personal record actually addresses.

This is where Earkeep fits. It records your day continuously on your own device, transcribes it there, and writes plain files you own, one per day. A boundary spanner's day file therefore spans every function they sat with: the 09:30 with engineering, the 11:00 with sales and the 14:00 with design are in the same file, in order, on disk. Running grep across a quarter of those files finds every time a component, a customer or a deadline was mentioned, whichever function's meeting it came up in. That is a claim about plain files, and it is the same claim made in private by design and from what was said to what you know. An agent working against a marked meeting can draft the decision log entry from the meeting it was decided in, which is the one piece of standing overhead this page recommends.

Two things it is not. There is no sharing, no team workspace and no sync between devices, so this is your record of the boundary you span, not a shared one. And the record does not identify speakers, so which function said a given line is not a question it answers. Telling the room you are recording is yours to do, and there is a page on how to say it.

The ceremonies where cross-functional work is coordinated, and where it silently is not, are in Agile, Scrum and Kanban and standup and retrospective formats. The prioritisation argument that most cross-functional forums are actually having, dressed as a scheduling one, is in MoSCoW and RICE. And the moment to establish the decision path, the interface owners and the log, is the kickoff, not the first time an interface fails.