Organizational Flow · In context
Team boundaries, cognitive load and capabilities
Where a team boundary goes decides how much the team has to hold, how often it has to ask, and whether anybody chose any of it. This page gathers what Organizational Flow — a working theory of organizational friction by Christoffer Råsten — says about team boundaries. Much of it builds on Team Topologies by Matthew Skelton and Manuel Pais, the clearest published treatment of how to shape teams and the ways they interact; anyone designing team boundaries should read the original.
Where an idea comes from Team Topologies, it says so below. TROi and Organizational Flow have no affiliation with Team Topologies or its authors, and nothing here speaks for them.
Cognitive load as the sizing rule
Team Topologies names cognitive load as the constraint that should shape a team.
Organizational Flow takes that as its sizing rule and makes it countable: count the separate domains a team must understand, not the people in it. Adding people to an overloaded team usually adds coordination rather than capacity; moving one domain out often does more.
In the paper: How Much Can One Team Hold · Drawing the Line Around a Team
What the boundary should follow
Team Topologies argues for boundaries drawn on purpose, around a stream of value.
Organizational Flow answers what to draw them around: the capability — an enduring business area, a bounded context that owns an outcome. A capability is coherent by definition, so cognitive load gets a natural edge. Draw the team around a system, a technology or a reporting line instead, and it inherits whatever unrelated concerns happened to land in that box.
In the paper: What a Capability Is, and Is Not · What Survives the Reorg
Interactions as friction
Team Topologies describes team types and a small set of interaction modes, chosen deliberately.
Organizational Flow reads the same choice in terms of friction: collaboration is a handover you have chosen to keep, ideally for a stated period; consuming something as a service is a handover you have removed. The common failure is not choosing wrongly but never noticing there was a choice.
In the paper: How Much Can One Team Hold · You Have to Know a Guy · An Interface Nobody Can Find
Dependencies, ownership and decisions
A team diagram shows who works with whom, but not who may decide.
Organizational Flow looks at exactly that. A team can have every competence it needs in the room and still wait weeks, because the decision sits somewhere else. Ownership clarity, handoff loss and decision latency are the three indicators that make that visible.
In the paper: The Team That Has to Ask · A Meeting Grew Here · Observing Organizations
Platforms and shared infrastructure
Team Topologies treats a platform as something other teams consume to reduce their load.
Organizational Flow looks at what happens when shared infrastructure turns into shared friction — and at the freedom to change that an organization gives away when it forgets to plan the exit.
In the paper: When Shared Infrastructure Becomes Shared Friction · Funding What Doesn't End
Teams with people and AI agents
Most writing on team design assumes a team made only of people.
Organizational Flow extends the same questions to teams where agents do part of the work: agents hold competence and add to a team’s load, what they may do follows from rules the organization has actually settled, and every outcome still needs a person who answers for it. The work harness — the structure people and agents both need to act — exists to make the organization cheaper to navigate, not to add more of it.
In the paper: The Meter Was Always Running · Owning What AI Can't
Conway’s law and sociotechnical architecture
In 1968 Melvin Conway observed that organizations design systems that copy their own communication structure. More than fifty years later it still holds, and it works in both directions: the systems an organization runs also shape how its people have to talk to each other. A team boundary is therefore an architecture decision, and an architecture decision is also a decision about teams — whether or not anybody made it on purpose.
That is what sociotechnical architecture means in practice: designing the organization and the systems as one thing. Draw a boundary through the middle of a capability and the system will grow an interface there, with a handover and a queue attached. Draw the boundary around the capability and the system has a reason to keep its logic in one place. The reverse move — changing the teams first so that the architecture follows — only works when the new boundaries follow something that lasts longer than the reorganization.
Platform teams
A platform team is Conway’s law used deliberately: a team that owns something many others depend on, offered so that they can consume it without asking. It reduces load when the platform is a clear service with an owner who may decide. It adds friction when it becomes a queue — when every team has to wait for the platform team, and the platform team has to wait for a decision nobody owns. The test is the same as for any boundary: can the teams on either side finish their work without a meeting?
In the paper: It Grew Like That · When Shared Infrastructure Becomes Shared Friction · The Long Way to a Yes
In short
Draw team boundaries around capabilities, size them by what a team must understand rather than by headcount, choose how teams interact instead of inheriting it, and make sure the teams inside the boundaries may actually decide. Otherwise the friction shows up as waiting, rebuilt context and value that is never created.