Remote work takes the blame for a lot of problems it did not cause. Teams that suddenly cannot coordinate, decisions that stall, dependencies that turn into finger-pointing, and the reflexive conclusion is always the same: this is because we are not in the same room anymore.
I do not buy it. Most of those problems were already there. The office was just hiding them, and remote work turned off the lights.
I recently went through the Remote Team Interactions Workbook by Matthew Skelton and Manuel Pais, the Team Topologies people, and it put a clean frame around something I had felt for years without having the words for it. So this is part book reaction, part what I have learned leading a platform team and working across distributed, high-performing teams that do not share a timezone, let alone a room.
Table of contents
Open Table of contents
- The short version
- The office was a giant implicit API
- Team Topologies, in one paragraph
- Collaboration is expensive, and remote sends you the bill
- Give your team an interface, not just a boundary
- Leading high performers when you cannot see them
- What changes when you make interactions explicit
- Final takeaway
The short version
- Remote work gets blamed for problems the office was quietly hiding.
- Team Topologies (Skelton and Pais) names three ways teams interact: collaboration, x-as-a-service, and facilitating.
- Remote makes defining the interaction mode mandatory, because it removes the ambient signals the office gave you for free.
- Collaboration is expensive. Time-box it, then move to a clean service boundary.
- High performers do not need supervision. They need a clear team interface and protected cognitive load.
The office was a giant implicit API
In an office, team boundaries can be vague and things still work, because the office is constantly leaking information you never had to design for. You overhear the problem before it reaches you. You catch someone at the coffee machine and settle in ninety seconds what would have been a three-day email thread. You read the room, literally, and adjust. The interaction between two teams was never really defined. It was improvised, continuously, on ambient signal.
Take that away and the improvisation has nothing to run on. The undefined interaction that “worked fine” in the office now produces a message into a channel that nobody owns, a request with no expected response time, and two teams each assuming the other is handling it. Then remote gets blamed for a boundary that was never drawn in the first place.
The uncomfortable truth is that remote did not lower the quality of your team interactions. It just stopped subsidizing the ones that were badly defined.
Team Topologies, in one paragraph
The whole Team Topologies idea, from Skelton and Pais, is that you should design teams and the ways they interact on purpose, instead of letting an org chart do it by accident. It describes a few durable team shapes, the most important being the stream-aligned team that owns a flow of work end to end, supported by platform teams that reduce its cognitive load, enabling teams that help it level up, and complicated-subsystem teams that hold deep specialist knowledge. Cognitive load is treated as a real constraint, not a personality flaw. A team can only hold so much in its head, and good structure respects that.
The part that matters most for remote is the interaction modes. There are three, and naming them is half the battle.
| Interaction mode | What it is | Best for | Remote failure if left undefined |
|---|---|---|---|
| Collaboration | Two teams work closely, high bandwidth, shared responsibility for a while | Discovery, designing a new interface, hard unknowns | Endless meetings, blurred ownership, nobody actually accountable |
| X-as-a-Service | One team consumes what another provides, minimal contact, clear boundary | Predictable delivery at scale | A silent dependency, tickets into the void, zero expectations set |
| Facilitating | One team helps another learn or get unblocked, temporary and coaching-shaped | Raising capability, clearing obstacles | Help that never ends, or help that never arrives |
The workbook’s core move is to make you state, out loud and in writing, which mode two teams are in and for how long. In an office you can skip that and let proximity paper over it. Remote, skipping it is how you end up with the failure column.
Collaboration is expensive, and remote sends you the bill
Collaboration mode feels like the good one. Two teams, working closely, lots of communication, everyone engaged. It is genuinely powerful for hard, fuzzy problems where you are still discovering the shape of the interface.
It is also the most expensive mode there is, and it is meant to be temporary. High bandwidth between teams means high cognitive load and blurred lines of ownership. In an office, permanent low-grade collaboration hides in the hallways and nobody notices the cost. Remote, that same permanent collaboration shows up as a calendar that is 60% meetings, because the only way to sustain undefined closeness at a distance is to schedule it.
The discipline the book pushes, and I agree with hard, is to treat collaboration as a phase with an exit. You collaborate to design the boundary, then you move to x-as-a-service and let the boundary do the work. Here is the difference in plain terms:
Vague remote interaction:
Hey, can your team help us with the pipeline sometime?
Clear remote interaction:
We need Collaboration mode with the platform team for two weeks to design the ingestion interface. After that we switch to X-as-a-Service: we consume the pipeline, you own it, requests go through the queue with a two-day response expectation.
The second version is not more bureaucratic. It is more humane. Everyone knows what mode they are in, how long it lasts, and what “done” looks like. That clarity is a gift, especially across timezones where a misunderstanding costs you a full day of round-trip.
Give your team an interface, not just a boundary
A boundary tells people where your team ends. An interface tells them how to work with you. Remote teams need the second one, written down.
A team interface is unglamorous, and it is the highest-leverage document a lead can produce: what we own and what we explicitly do not, how to make a request of us, what response you can expect and in what window, where the docs and runbooks live, and how to reach us for something genuinely urgent versus something that can wait for our morning. It is the human version of an API contract, and like a good API, its main job is to let people depend on you without having to interrupt you.
Once that exists, most of the “remote is hard” friction quietly disappears, because the thing people were missing was never presence. It was predictability. And predictability is exactly what your best people are looking for.
Leading high performers when you cannot see them
There is a specific fear that drives a lot of bad remote management: if I cannot see them, how do I know they are working. It leads to status theater, calendar surveillance, and the slow insult of being asked to prove you are busy. High performers feel that instantly, and it is the fastest way to lose them.
Here is what high performers actually need, and it is almost the opposite of supervision.
They need clarity of interface. What are we solving, who owns it after it ships, what does success look like, what are we choosing not to do. Ambiguity is what wastes strong people, not lack of oversight. A high performer given a fuzzy goal will build the wrong thing beautifully.
They need their cognitive load protected. The platform, the docs, the guardrails, the paved paths exist so that talented people spend their attention on the actual problem, not on rediscovering how the deploy works for the fortieth time. Protecting focus is a leadership act, not a nice-to-have.
And they need trust expressed as autonomy, not absence. Define the interface, agree the interaction mode, set the expectation, then get out of the way and let them work through it. Async-first, decisions written down, outcomes over hours. The manager who does this well becomes almost invisible in the day to day, which feels wrong to people who confuse activity with value, and is exactly right.
What changes when you make interactions explicit
None of this requires more tooling or another platform. It requires deciding, in writing, how teams interact, and then honoring it. When you do, the payoff is concrete: fewer meetings, because closeness is time-boxed instead of permanent. Less ambiguity, because the mode and the expectations are stated. Teams that ship without waiting on one person, because the interface replaced the shoulder tap. And lower cognitive load, because nobody is holding a mental map of who probably owns what this week.
That is the same thread that runs through everything I believe about senior work: the job is to reduce ambiguity, and remote just raised the price of leaving it in place.
Final takeaway
Remote work did not make your teams worse. It turned off the lights that were hiding the wiring, and now you can see which interactions were never actually designed.
The teams that thrive at a distance are not the ones with the best video setup or the most check-ins. They are the ones that made their interactions explicit on purpose: which mode we are in, for how long, what we own, how to reach us, what to expect. Team Topologies gives you the map. Remote is the forcing function that finally makes you draw it.
Draw it. Then trust people to work through the interface you built, which is the whole point of building one.