The Meeting Exists Because an Interface Is Missing

Thursday, three o’clock. Six people join the same call they joined last week. Someone shares a spreadsheet; someone else shares a different one. The next forty minutes go to working out which one is right.

Nobody would call this meeting a failure. It has an agenda, it starts on time, and it usually ends with everyone aligned. Two teams are building one feature: Checkout owns the screen where a customer pays, and Payments owns the service that actually charges the card. Every week, the sync answers the same questions. Is the new version of the payment service running in the test environment yet? Who is fixing the bug where a declined card shows a success message? Does “done” mean the code is merged, or that it is live in production? Which spreadsheet is current?

The meeting answers every one of those questions. That is the problem. Next Thursday it will answer them again, because nothing it settles is kept anywhere that would make the question unnecessary. A recurring meeting like this is not evidence of a collaborative culture. It is evidence of an interface nobody built, and of an organization that has made people the integration layer instead.

What an interface actually is

Think about a busy restaurant. The dining room and the kitchen are two teams with different jobs, different pressures, and different vocabularies. They do not hold a meeting before every table is served. The server writes an order ticket – table number, dishes, changes, allergies – in a format the kitchen already knows how to read. Nobody in the kitchen needs to ask what “no onions” means or who will carry the plate out. Those questions were answered once, when the restaurant decided how a ticket works.

That ticket is an interface: an agreement about what crosses the boundary between two parties, in what shape, and what each side can count on once it does. In software, the familiar version is an API, a published way for one program to ask another for something without knowing how the other works inside. A payment service might promise: send me an amount, a currency, and a card reference, and I will answer within two seconds with approved, declined, or error, never anything else. The team calling it can build on that promise without a meeting.

Organizations need the same thing between people, and most of the interfaces they lack are not technical. An interface can be a named owner for the space between two teams, a written definition of “done” that both sides use, or a rule that says which releases need human approval and which do not. It can be a service-level expectation for how fast a request gets answered, an escalation path for when it does not, or one agreed place where the current status lives. What they share is the property that matters: once the contract exists, one side can rely on the other without reopening the conversation.

Take the ticket away and the restaurant does not stop serving food. Servers walk into the kitchen and explain each order out loud. It works, slowly, until the dinner rush. That is what many recurring coordination meetings are: the kitchen conversation that replaced a ticket nobody designed.

The meeting as middleware

Software has a name for the layer that connects systems never designed to talk to each other: middleware. It moves data from one side to the other, translates formats, and absorbs mismatches so each side can behave as if the connection were native. Look at Thursday’s agenda again with that word in mind. Reporting status from a tool only one team can see is data transport. Translating one team’s “done” into the other’s is format conversion. Reconciling two spreadsheets is conflict resolution between two copies of the truth. Deciding who owns the declined-card bug is routing. Strip away the greetings and the screen sharing, and what remains is an integration layer whose runtime is six people.

Seen that way, the meeting can be judged the way an engineer would judge any integration. It does not score well on any of these five counts:

• It polls instead of reacting. A well-built interface pushes a change when it happens: the build fails, the status updates, the owner is notified. A weekly meeting checks once every seven days. Anything that changes on Friday waits until next Thursday, so the organization’s reaction time is set by a calendar recurrence rather than by the work.
• It is lossy. Information travels by speech, gets summarized from memory, and lands in notes nobody reads twice. There is no schema, no agreed shape for the data, so the same word arrives meaning different things on each side. “Ready” when Checkout says it and “ready” when Payments hears it are not the same state.
• It keeps no reliable record. Real middleware keeps a log of what was sent, when, and whether it arrived. The meeting keeps whatever someone remembered to write down. Three weeks later, nobody can say with confidence when a decision was made, or whether it was made at all.
• It depends on a single node. Many of these meetings rest on one person who actually understands how both sides fit together. When that person is on vacation, the meeting is cancelled, and the integration quietly goes down with it.
• It does not scale. Every new team that depends on the same boundary adds attendees, not capacity. The meeting gets longer. Then it gets a pre-meeting.

None of this appears as a line item. Six people for an hour a week is more than three hundred person-hours a year, before preparation, follow-ups, and the context switch on either side of the call. The larger cost has no invoice at all: every decision that could have been made on Monday waits for Thursday, and every fact the meeting carries is up to a week old by the time it arrives.

Why the workaround outlives its welcome

If the meeting is such a poor interface, why does it survive for years? Because it is the cheapest thing to start and the most expensive thing to stop.

Creating a meeting costs one calendar invitation and nobody’s permission. Building the interface costs negotiation. Someone has to agree what “done” means, accept ownership of the gap, fund the shared status page, or write the rule that removes a human approval. That work sits on the same boundary the meeting sits on, which is exactly why nobody owns it. Meanwhile the meeting does real work, visibly. People leave it feeling informed and aligned, and the feeling is not false. It is simply being bought again every week.

There is an older idea underneath this. In 1968, Melvin Conway argued that the systems an organization designs tend to copy its communication structure. Read in reverse, recurring meetings become a map. A standing sync between two teams marks a place where the shape of the organization and the shape of its systems disagree: the architecture diagram shows a clean boundary, and the people know there is not one. The meeting is where that disagreement gets paid for.

Team Topologies offers a sharper vocabulary for the same gap. It treats close collaboration between teams as a deliberate mode, valuable while two teams are still discovering how their work fits, and best kept temporary. It contrasts that with consuming something as a service, where one team provides a capability and the other relies on a clear boundary. Seen through that lens, a collaboration that never ends is often a service boundary nobody finished defining.

Not every meeting is a missing interface

The lazy version of this argument says meetings are waste and an empty calendar is the goal. That is nonsense, and it fails in practice the first time something genuinely new happens.

Some meetings do work no interface can absorb. Deliberation, negotiation, and real creative work require people to think together. Decisions under genuine uncertainty need judgment, not lookup. An incident nobody anticipated needs the fast, flexible exchange only a live conversation provides. A risk review may recur because conditions keep changing, not because a contract is missing. Meetings also do things no interface should try to do: they build trust between people who will need each other under pressure, and they surface the problem nobody thought to put in a field.

The useful distinction is between a meeting that creates something and one that carries something. One produces a decision, a plan, or an understanding that did not exist before people gathered. The other moves information that already existed, or settles an ambiguity that should have been settled once and written down. There is a simple way to tell them apart: read the notes. If last month’s notes could be pasted into this week’s with only the dates changed, the meeting is carrying state. If every set records a different decision, the meeting is doing what meetings are for.

Decision aid

Sorting a standing meeting

Cancelling meetings indiscriminately only moves the coordination into chat threads and hallway conversations. Instead, take each recurring agenda item and walk it through these questions in order. Stop at the first one that applies:

1. Does it produce a decision that did not exist before? Keep it, and give it what a decision needs: defined inputs, someone with the authority to decide, and a cadence matched to how fast the situation actually changes.
2. Does it carry a fact that already exists somewhere? Make the fact visible where it lives, in the tracker, the deployment log, or a status page both teams trust, so nobody has to read it aloud. The missing interface is a single source of truth.
3. Does it settle the same question it settled last time? Write the answer down once, as a definition, a rule, or a named owner. The missing interface is a policy.
4. Does it wait on another team’s commitment? Turn the commitment into a contract: what will be delivered, in what form, by when, and what happens when it slips. The missing interface is a service agreement.
5. Still unsure? Pause the item for two cycles and log what breaks. Operations teams call this a scream test: switch something off and see who complains. Whatever breaks names the interface the meeting was standing in for.

Run Thursday’s agenda through it. The question about the test environment disappears once the deployment pipeline posts what is running where. The spreadsheet reconciliation disappears when one spreadsheet is retired and the other is declared the authority. The definition of “done” gets written once and linked from both teams’ boards. The declined-card bug exposes the real gap: nobody owns failures that cross from one service into the other, and that calls for a named owner and an escalation path, not a weekly discussion. What remains – whether to change how failed payments are retried before the holiday season – is a genuine decision that needs both teams in the room. It deserves a meeting. Probably a shorter one.

The replacement can be built badly, too

An interface is not automatically better than the meeting it replaces. Automating an ambiguity does not remove it; it only makes it run faster. A rigid rule applied to a decision that genuinely needs judgment produces worse decisions and sends everyone back into a meeting to override the rule. A dashboard nobody trusts becomes one more tab opened before the status call begins. A contract nobody can meet simply relocates the meeting: the weekly sync becomes a weekly exception review.

The work is to separate two things the meeting has been bundling together. The information it transports should move into a system that carries it reliably, continuously, and with a record. The judgment it legitimately exercises should stay with named people, who can now spend their attention on that judgment instead of on reconstructing the state of things. Moving the first while protecting the second is the whole job.

Back to Thursday at three. If the interfaces exist, the call does not have to vanish. It can become twenty minutes about the one question that actually needs both teams, with everyone arriving already knowing where things stand, because the current state is no longer something people have to carry from one side to the other by hand. That is the test for any standing meeting: does it create something, or does it compensate for something the organization should have built once? Protect the first kind. The second is not collaboration. It is a design decision postponed one calendar invitation at a time.

Source notes

These sources support the organizational-boundary concepts. The Thursday meeting between Checkout and Payments and the restaurant ticket are hypothetical illustrations. The “human middleware” framing, the integration comparison, and the decision aid are this article’s synthesis and are not attributed to either source.

• Team interaction modes and boundaries. Skelton and Pais describe explicit modes of interaction between teams, including collaboration and consuming a capability as a service, and treat sustained collaboration as costly and best suited to discovery. Source: Matthew Skelton and Manuel Pais, Team Topologies.
• Systems mirror communication structures. Conway argues that organizations designing systems produce designs that copy their own communication structures. Source: Melvin E. Conway, “How Do Committees Invent?”, 1968.