Draw your organisation chart. Every box has a name on it. Now mark the lines between the boxes, and ask who is accountable for each one.
A metropolitan hospital measures its emergency department on time to triage, its imaging unit on scan turnaround, and its wards on length of stay. All three are performing at or above target. Patients, meanwhile, spend hours in corridors, and the executive team cannot work out why the aggregate experience is so much worse than the sum of its parts.
The answer is not hidden. It sits in the gaps. The patient waits between triage and imaging, between the scan being taken and being read, between the bed being ready and the paperwork being signed. Every department is optimised. Every handoff is nobody's job.
This pattern is not peculiar to hospitals, and it is not primarily an operational problem. It is a design problem that executives are unusually poorly positioned to see, because the instruments through which they view the organisation — functions, budgets, reporting lines, performance targets — are all built around boxes rather than the spaces between them.
The Strategic Context
Enterprise value is produced by work and destroyed by handoffs. That statement sounds glib until you look for exceptions, and they are hard to find. Manufacturing loses more to changeover and queue than to machining. Infrastructure loses more to interface between contractors than to any single trade. Software loses more to the gap between a decision and the team that must act on it than to the writing of code.
The practitioner literature on project delivery has a precise vocabulary for this, and it is more useful than most of what has been written on the subject since. It identifies three distinct interfaces a delivery leader must manage.
The personal interface arises wherever two people work on the same thing and conflict is possible. Where they report to the same manager, the delivery leader's authority to resolve it is limited and someone else must be drawn in. Where they report to different parts of the organisation, the delivery leader becomes a mediator without standing.
The organisational interface is, in the literature's own assessment, the most difficult, precisely because it involves more than people. It involves conflicting unit goals and incompatible managerial styles, compounded by the fact that each unit speaks a technical language the others do not read.
The system interface concerns everything that is not a person — schedules, information passed from one task to another, the physical and technical dependencies of the work itself. This is where information arrives late or wrong, and a schedule quietly slips.
All three are real. Only one of them is visible on a dashboard.
What Leaders Commonly Misread
The misreading is not that interfaces matter. It is which interface is being managed.
The literature's diagnosis is blunt: managers with technical backgrounds tend to over-involve themselves in the system interface, to the detriment of the personal and organisational ones. This is not laziness or preference. It is entirely rational behaviour on the part of the individual. The system interface is legible. It has data, it has a schedule, it produces artefacts, and progress on it can be demonstrated. The organisational interface has none of these. Nobody has ever been praised in a steering committee for resolving a semantic mismatch between two departments' definitions of complete.
So the effort flows to where it can be shown, and the expensive interface goes unmanaged.
There is a second misreading, more common at executive level. Leaders tend to assume that interfaces are a coordination problem, solvable by better meetings, clearer RACI charts or a project management office. Coordination helps at the margins. But a coordination mechanism placed across an unowned interface still leaves the interface unowned; it merely creates a forum in which two parties can fail to agree more efficiently. The question is not whether the interface is discussed. It is whether anyone is accountable for what happens there.
A third and subtler error is to confuse this with the problem of information loss up the reporting chain — the way detail is compressed and anomalies discarded as reports travel toward the executive committee. That is a real and serious phenomenon, and it is treated in [Related article: Whose Knowledge Does Your Governance System Actually Hear?]. But it is a vertical loss, and its remedy is a change to how signal travels upward. What this article describes is horizontal loss, between peers at the same level, and no amount of better reporting fixes it.
Reframing the Issue
The reframing worth making is this: the delivery leader's job is not to manage the work. It is to manage the interfaces, and the work is what happens between them.
This is why the most useful description of the role in the literature is integrator — a term that appears in several role inventories alongside more generic labels like communicator, leader and decision maker. Those other labels describe things every manager does. Integration describes the one thing this role exists to do, and the one thing no functional manager is positioned to do, because each of them can see only their own side of the interface.
Once the role is understood that way, several familiar problems reorganise themselves. A delivery leader who is drowning in technical detail is not overworked; they are working on the wrong interface. A program that is on schedule at every workstream and late overall is not suffering from optimistic estimating; it is suffering from unowned dependencies. A team that reports green until the week it reports red is not concealing bad news; it is reporting honestly on its own box while nothing reports on the spaces between boxes.
Strategic Analysis
Why the organisational interface is the expensive one
Consider two utilities merging their field operations. Each has an outage management process that works. Each has a definition of restored. One counts restoration when supply is re-energised; the other counts it when the customer is contacted and confirms. Both definitions are defensible. Neither team regards the difference as significant enough to raise.
The merged organisation then reports a restoration performance figure that is neither true nor false, funds an improvement program against it, and discovers eighteen months later that half the improvement was definitional. No individual failed. No process was broken. The failure was entirely in the interface, and it was invisible because each unit was measuring itself correctly.
The reason this interface is the most expensive is that it fails silently. The personal interface generates visible conflict; someone escalates. The system interface generates missed dates; a schedule turns red. The organisational interface generates agreement — two parties who each believe the matter is settled, and who will not discover otherwise until the consequences arrive.
The vocabulary problem is not a communication problem
It is tempting to treat incompatible technical languages as something a glossary can fix. This underestimates it. Each function's vocabulary encodes its priorities. When engineering says risk it usually means a technical failure mode; when finance says risk it usually means variance against forecast; when clinical staff say risk they mean harm to a patient. These are not translations of one another. They are different questions wearing the same word, and a glossary that maps them to a single definition will destroy the distinction each function needs.
The workable response is not standardisation but explicit interface definition: at this boundary, this term means this, and the party on each side accepts responsibility for translating into and out of it. That is a design decision, and it needs an owner.
Interfaces are where capability is actually tested
The three demands the delivery role places on a person — relinquishing the how, working laterally, and operating without expertise — are all, on inspection, interface demands. Which is why the transition into the role is so difficult, and why it deserves the treatment set out in [Related article: From Specialist to Delivery Leader: The Promotion That Is Actually a Career Change]. A specialist has spent a career inside one box. The role puts them permanently between boxes, with no authority on either side. The third demand — operating credibly without being the expert — has a governance counterpart that closes this series: whether the person receiving a claim across an interface can tell that it does not hold, examined in [Related article: Enough Technical Depth to Test the Answer].
Decision Framework
Interfaces can be managed deliberately. The method is unglamorous and works.
Step one — enumerate. For a given program, list every boundary at which work, information or a decision passes between two parties who do not share a manager. Most organisations find between fifteen and forty on a program of any size. The count itself is usually the first surprise.
Step two — classify. Mark each as personal, organisational or system. The classification matters because the remedies differ: personal interfaces need a named escalation route; organisational interfaces need agreed definitions and reconciled objectives; system interfaces need specified handoff content and timing.
A note on where the boundary runs. Interfaces with parties outside the organisation — communities, regulators, customers — behave differently, because the other side has no obligation to reconcile with you and its exposure is not visible on any internal chart. Reading those correctly is a separate discipline, set out in [Related article: Your Stakeholder Map Measures Attention, Not Exposure].
Step three — assign. Every interface gets one accountable name — not two, not a committee. The accountable party is not necessarily on either side; frequently the right answer is the delivery leader, which is precisely what integration means.
Step four — apply the two tests. For each interface, ask: what does each side believe the other will provide, and have they said it to each other in the same words? And: if this interface failed today, how long before anyone noticed? The second test is the more revealing. An interface with a detection latency measured in months is not being managed regardless of what the plan says.
Step five — instrument the boundary, not the box. Add at least one measure that only fails when the interface fails: elapsed time at a handoff, rework arising from a handoff, or the volume of clarification traffic crossing it.
From Strategy to Execution
Immediate. Take the program that is currently causing the most executive anxiety and run steps one to three on it. This is a two-hour exercise with the right people in the room. The output is a list of boundaries with owners, and it will typically show that the interfaces generating the most trouble are the ones with no owner and no measure.
Medium term. Make interface enumeration a standing requirement at program initiation, and give the delivery leader explicit authority to define handoff content across functional boundaries. Without that authority the role is integration in name only — a point that sits close to the structural problem examined in [Related article: Accountability Without Authority: How Organisations Design Delivery Leadership to Fail].
Long term. Change what the organisation measures. As long as every performance measure sits inside a box, every incentive will point people toward optimising their box, and the interfaces will remain everyone's problem and nobody's job. A small number of boundary measures, owned at executive level, changes the behaviour more than any amount of exhortation about collaboration.
Signals to Monitor
- Clarification traffic. A rising volume of emails and meetings whose purpose is to establish what the other party meant is the clearest early sign of an undefined organisational interface.
- Rework concentrated at handoffs. Track where rework originates. If it clusters at boundaries rather than within tasks, the interface specification is the problem, not the work.
- Green workstreams and an amber program. A persistent gap between component status and aggregate status almost always indicates unowned dependencies.
- Escalations that travel two levels up before they travel sideways. This indicates there is no lateral resolution route, and the personal and organisational interfaces are being managed by the hierarchy rather than by design.
- Handover interfaces with no receiving owner. The largest single interface in most initiatives is the one at the end, where a temporary structure passes its work to a permanent one. Its particular failure mode is examined in [Related article: The Hidden Cost of Putting Work Into Project Form].
- Definitional drift after reorganisation or acquisition. Any structural change creates new interfaces that inherit no definitions. The period immediately after a reorganisation is when this failure mode is most active and least watched.
Questions for the Leadership Team
- Can we name the ten most consequential interfaces in our largest current program, and the person accountable for each?
- Which of our performance measures would deteriorate if an interface failed — and if none would, what are we actually measuring?
- Where in this organisation do two functions use the same word to mean materially different things, and who would be responsible for noticing?
- When an interface fails, how long does it take us to find out, and is that latency a design choice or an accident?
- Do our delivery leaders have the authority to define what crosses a boundary between two functions they do not manage — and if not, what do we imagine integration means?
Closing Perspective
Organisations are designed as collections of capabilities and experienced as sequences of handoffs. The gap between those two facts is where most operational value quietly disappears, and it is structurally invisible to an executive team that manages by function.
The remedy is not a new operating model, a reorganisation, or another coordination layer. It is narrower and harder: deciding that an interface is a thing that can have an owner, and then giving it one. Most organisations have never made that decision — not because they rejected it, but because the question has never been put in a form that requires an answer.
Put it in that form, and the answers arrive quickly. The uncomfortable part is that the list of unowned boundaries is usually long, and every item on it has been costing money for years.
About the author
Kevin Jogin is Founder & Principal Advisor at EraNorth. Meet the Founder.