“Everything is a lot more hands-on than it used to be,” a person familiar with the situation told Bloomberg about Apple this week. “It’s hectic right now.”1 Bloomberg’s Mark Gurman reported on Tuesday that the company’s new chief executive, John Ternus, wants to overhaul Apple so it will “run faster and leaner,” and that managers in product-development groups are “being pushed to deliver more products, more frequently and on shorter timelines.”1 All of it is Bloomberg’s account, sourced to people familiar with the situation.

Further down, the report says Apple has dismissed “a number of engineering program managers, or EPMs,” in its hardware engineering division over the last two weeks. Bloomberg describes the role as “central to Apple’s product-development process for decades” and responsible for “managing timelines and coordinating work across teams.”1

Whether that works for Apple is not something an outsider can judge from a news report, and I won’t try. I made my case about what flattening takes out of the middle of an organization last week, and I won’t rerun it here. What interests me is the word restructurings keep reaching for, faster, and what actually decides how fast product work moves. My read is that most reorganizations sold on speed assume the speed lives in the org chart.

Where a project’s days go

The October issue of Production and Operations Management carries a study that measured delay inside real product development, one employee at a time. Tuuli Hakkarainen, Anatoli Colicev and Torben Pedersen tracked 526 employees on 42 new product projects over 20 months at a Danish manufacturer of hydraulic pumps with roughly 20,000 employees in more than 50 countries.2 Delay was counted in days, as the gap between the most recent planned completion date for a stage gate and the date it actually finished.2

The study was built to test distance. Employees whose collaborators sat farther away were associated with longer delays, which the authors trace to coordination costs: attention split across far-flung collaborators, including time spent waiting for responses, and the effort of finding, reaching and making sense of information held in other locations.2

The finding for anyone planning a reorganization concerns who those collaborators were. The researchers counted two employees as familiar if they had worked together on other projects, at the same time or before.2 For an employee with no familiar teammates on a project, each step up in distance came with about 29 additional days of delay. For an employee with about two dozen familiar teammates, one standard deviation above the sample average, the added delay shrank to about 5 days, which the authors could not distinguish statistically from zero.2 The paper measures distance on a log scale, so one step is a little under a tripling of a person’s typical distance from collaborators.

In this study, the delay that distance added all but disappeared between people who had already worked together, and shared history is the one asset an org chart has no box for.

What a reshuffle spends

Set that beside the usual restructuring, where teams get recombined and reporting lines move. What follows is my inference and goes past what the paper tested: each of those moves can break up pairs of people who had already worked out how to get things done together, and this study suggests that history is a large part of what keeps coordination from eating the calendar. The authors’ own explanation points the same way. Colleagues who know each other, they argue, need fewer reminders and follow-ups to get a response, and they settle who does what faster.2

The authors report, from discussions with the company, that project staffing is typically set before a project begins and rarely altered along the way, “as mid-course adjustments can spill over to other projects.”2 That reads to me like an organization that treats who works with whom as something expensive to disturb.

The authors also found the distance effect concentrated in later project gates and in high-risk or highly innovative projects.2 I would expect a company trying to ship more often and experiment more to spend a great deal of its time in exactly those stages.

How far to lean on it

The study has real limits. It covers one company with data from January 2015 to August 2016, and the design is observational with careful controls, so it shows association and cannot prove cause. The authors write that their findings “might not directly apply to all settings.”2 Distance was the variable they set out to study, with familiarity as a condition that changed its effect, so I would not quote 29 days as a constant. What I would carry into a planning meeting is the direction: much of the time a project loses is lost between people, and how much depends on whether they have history.

Where staffing allows, the authors suggest giving priority to prior collaboration among team members whose work depends on each other, and where it does not, they point to interface playbooks and shared glossaries to cut down on repeated rounds of clarification.2 For projects where research and production sit in different countries, where the distance penalty nearly doubles from about 16 days to about 31, they suggest designating “a handoff owner with explicit verification authority.”2

So before a chart gets redrawn in the name of speed, add a question that rarely appears on the slide: which working pairs does this break up, and what will do their job once they are gone? Familiarity is one way a team pays for coordination, and it is slow to build. James Wright and I argue in Agile Sucks! that trust should be designed into how work runs, so it holds “even across fast-moving teams or unfamiliar environments,” and the study’s own fallback points the same direction: playbooks, shared glossaries and a named owner for each handoff. A reorganization that breaks the pairs and puts nothing in their place is spending the thing that kept the work moving, and the first place that cost would show up is the gate dates.

When your organization last restructured for speed, did anyone count which teams had already learned to work together? I would like to hear how it went, especially from anyone who designed a replacement for what those pairs had been doing.