Interaction Mode Decay
A collaboration between two teams that was never time-boxed hardening into permanent coupling - with the interface living in a recurring meeting instead of in a contract that can be tested.
Two teams begin working closely because the interface between them is genuinely unknown. A weekly 90-minute sync is set up, and it works. A year later the sync is still running, every interface question is "agreed in the sync", and nothing about the boundary is written down anywhere a test could check it.
That is interaction mode decay: a collaboration mode, which is supposed to be temporary, becoming the organisation's integration layer. The teams are no longer independent, the architecture has a coupling nobody designed, and the interface will leave the company when the two most senior attendees do.
Why it matters
The time is the visible cost and the smaller one. Nine teams can form 36 pairs; fourteen standing weekly collaborations at about 3 hours of senior time each is roughly 42 hours a week, about one full-time engineer before preparation and context switching.
The structural cost is that a decision made by calendar invitation leaves no artefact, so there is nothing to version, nothing to deprecate and nothing to test. Lead time for a change crossing those two teams stays several times longer than for a change inside one, which is the number that moves executives.
Implementation patterns
- Give every collaboration an end date and an exit artefact at the moment it starts: an interface document, a consumer-driven contract test in the provider's pipeline, or a service the consumer can call without asking.
- Delete the meeting on the day the test lands, not when someone remembers.
- Cap standing collaborations per team at about two, so exceeding the cap is a decision rather than an accumulation.
- Review modes quarterly: which pairs are collaborating, which are consuming a service, which are being facilitated, and when each was last reviewed.
- Convert to X-as-a-service as the default end state, with a published change calendar — the point of the service mode is that the consumer stops needing the provider's attention.
Industry example
The vocabulary comes from Skelton and Pais's Team Topologies (2019), which is explicit that collaboration is expensive and intended to be temporary, and that the expected end state for a discovered interface is X-as-a-service. The widely copied published team models from large product companies carry the same lesson from the other direction: those diagrams are snapshots, and what decays in practice is rarely the team shape — it is the interaction mode left running in production after its purpose ended.
Failure scenarios
- Fourteen standing syncs and 9 to 11 hours a week of cross-team meetings, reported by engineers as the reason nothing ships.
- An interface that cannot be changed without both teams in a room, so a one-line change takes two weeks.
- Key-person dependency: one engineer each side holds the contract, and a departure causes an outage.
- A reorganisation used as the fix. The interfaces stay unwritten, the shared memory resets, and the result is worse for roughly two quarters.
Trade-offs
Converting a collaboration to a service costs real work: the contract has to be written, the test built, the change calendar maintained, and the provider must now support an interface they previously renegotiated weekly. For a volatile boundary that is a bad trade — a contract rewritten every fortnight is worse than a conversation.
| Mode | Gains | Pays |
|---|---|---|
| Collaboration | Fast discovery of an unknown interface | Permanent senior time and no artefact |
| X-as-a-service | Consumer independence and testable change | Contract maintenance and provider obligation |
| Facilitating | Capability transferred rather than supplied | Only works with a stated end date |
When not to use it
Do not convert a collaboration that is genuinely mid-discovery: a new regulatory flow, a novel product shape, a joint incident class with no established pattern. Those need bandwidth, and forcing a contract early freezes a boundary you do not yet understand. The test is whether the last four weeks of the meeting produced any decisions at all — when the meeting has become status reporting against a stable interface, convert it; while it is still producing design decisions, keep it and set a date.
Interview question
Q: Two teams have held a weekly sync about the same interface for a year and every engineer on both teams says it is essential. How do you tell whether that is a healthy collaboration or a coupling problem, and what would you change first?
What a strong answer covers: check for an artefact — is there a contract, a test, a change calendar; measure the lead time for a change crossing the pair against one inside a team; count the standing pairs in the whole organisation and the hours; then convert the pair with a written contract and a contract test before touching the meeting, and explicitly reject a reorganisation as the first move.
Quick check
Quiz: What is the exit artefact that lets a standing cross-team sync be deleted safely? A written interface plus a consumer-driven contract test in the provider's pipeline and a published change calendar.
Flashcard: A weekly sync between two teams has run for a year. What has the organisation actually built? A human integration layer standing in for an unwritten interface — permanent coupling at about 3 hours of senior time a week, with nothing to version, test or deprecate.