Intentionally Limiting Communication Bandwidth

I used to treat open communication as an unalloyed good. If something mattered, it belonged in the biggest room. If people were confused, the fix was another forum, another channel, another all-hands where everyone could “align.”

I do not believe that anymore.

What I am practicing instead looks closer to what Matthew Skelton and Manuel Pais describe in Team Topologies: intentionally limiting the communication bandwidth between teams so the organization can move. Not silence. Not secrecy. Deliberate constraints on who talks to whom about what, so cognitive load stays inside a team that can actually finish work.

More collaboration is often the disease

The default startup reflex is to add a meeting when something feels sticky. Culture feels fuzzy, so schedule a workshop. Delivery feels cross-cutting, so create a standing multi-team sync. Someone is curious about an open-source corner of the industry, so paste it into the main engineering channel and hope the right people notice.

Each of those moves increases communication bandwidth. Skelton and Pais argue that high bandwidth between every team is not a sign of health. It is often a sign that team boundaries are wrong, or that platform and enabling paths are missing, or that we are asking every group to hold every concern. Fast flow needs teams that can operate with less continuous coordination, not more.

I am not citing a meeting where someone said “Team Topologies” out loud this week. I am using their lens on practices I already run.

Culture as a narrow channel

This month I reopened Company Ethos conversations as 1:1s on purpose. Not a workshop. Not a group call. Not a forum to redesign the ethos in public. A quiet thread about how the ethos holds when the work shifts, booked by DM, no prep required.

That shape is a bandwidth decision. A group redesign forum would maximize airtime and minimize candor. A 1:1 maximizes signal. The calendar this week has those culture conversations back to back with engineering and people-ops teammates. Same topic family, different rooms, intentionally not a broadcast.

People ops can still diffuse work ethics through training spaces and defined attributes for effective developers. That is a platform-shaped path for culture: durable materials and focused sessions, not every value debate in every Slack thread.

CoP as bounded shared load

Community of Practice is the other half of the pattern.

We run short, scheduled sessions: a Go release deep dive one week, an AI-assisted path from ticket to production the next. The point is shared cognitive load with a container. Forty minutes on the calendar. A topic. A room. Then people go back to their teams.

That is different from continuous cross-team ping. Continuous ping feels collaborative. It also means every team partially owns every concern, which is how you get polite thrash and no ownership. A bounded CoP lets specialists teach and ask without turning the whole company into one overloaded group chat.

Curiosity still has a place. An interesting NSA open-source note can be a personal rabbit hole or a hallway pointer. It should not automatically become the week’s mandatory cross-team thread. Curiosity without a container is how bandwidth gets stolen from the work that ships.

Platforms beat pings

The part of Team Topologies I keep coming back to is not the team-type diagram on a slide. It is the claim that you should design interaction modes on purpose: collaboration for a bounded time, X-as-a-Service when a platform can absorb the dependency, facilitating when an enabling team is teaching.

Most companies skip that design step and default to permanent collaboration. Permanent collaboration feels kind. It is also how senior people become human routers. Every unclear interface becomes a meeting. Every missing platform capability becomes a Slack mention. Bandwidth rises until the only people who can finish deep work are the ones who learned to ignore the channels.

I would rather invest in a clearer interface, a short enabling engagement, or a 1:1 that removes a blocker than in another standing sync that exists because we never named the dependency.

What I am changing

I write this from Omarchy, which has been my daily driver for about eight months. Mail still lives in Gmail in the browser across a few accounts. Calendar still lives in Notion Calendar. The boring substrate is not the thesis. It is a reminder that I will change defaults when they stop matching the job. Communication defaults are the same kind of change.

What I am holding:

1. Prefer 1:1 or small rooms for culture and conflict. Broadcast is for decisions already made, not for discovering what people actually think.
2. Put shared learning in a scheduled CoP, not in infinite threads. If it matters enough to teach, it matters enough to time-box.
3. Treat “everyone should know” as a smell. Often it means the platform or the enabling path is missing, and we are using human bandwidth as a workaround.
4. Protect team focus as a product feature. Inter-team communication should be deliberate interfaces, not ambient noise.
5. Stop scoring health on message volume. A quiet week with clear ownership beats a loud week where every team was in every conversation.

The point is flow, not vibes

Team Topologies is easy to misread as an excuse to silo. That is not the move. The move is to make the remaining communication high-signal: APIs between teams, enabling help that arrives with a mission, platform paths that remove the need to ask, 1:1s where candor fits, CoP sessions where teaching fits.

I used to think the generous leader opened every channel. I now think the generous leader chooses the channel. Intentionally limiting communication bandwidth is how people get their attention back, and how teams get fast enough to deserve the trust we keep talking about.