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. These are the things I have learned to look for when those boundaries are drawn, with the chapters of Organizational Flow and the insights where each one is developed.
Size a team by what it must understand
Count the separate domains a team has to 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 than hiring three.
In the paper: How Much Can One Team Hold · Drawing the Line Around a Team
Insight: Capability is not Competence
Draw the line around a capability
A boundary drawn around a system, a technology or a reporting line inherits whatever unrelated concerns happened to land in that box. Drawn around a capability — an enduring business area that owns an outcome — it gets a natural edge, and it survives the next change of systems and the next reorganization.
In the paper: What a Capability Is, and Is Not · What Survives the Reorg
Insight: Capability before Technology
Every interaction is a choice about friction
Collaboration between two teams 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; it is never noticing there was a choice, and improving the teams while the transitions between them go unowned.
In the paper: You Have to Know a Guy · An Interface Nobody Can Find
Insight: Flow Breaks at the Joints
A team that has to ask is not yet a team
A team can have every competence it needs in the room and still wait weeks, because the decision sits somewhere else. A team diagram shows who works with whom; it does not show who may decide. And a team whose work depends on interrupting someone outside it is a queue with a name, however it is drawn.
In the paper: The Team That Has to Ask · A Meeting Grew Here
Insight: A Queue With a Name · Governance Grows in the Gap
Shared infrastructure, shared friction
A platform reduces load only while it behaves like a service, with an owner who may decide and a way in that does not require knowing anyone. When every team has to wait for it, shared infrastructure becomes shared friction — and an organization that never planned the exit has quietly given away its freedom to change.
In the paper: When Shared Infrastructure Becomes Shared Friction · Funding What Doesn't End
Insight: None of This Is a Software Concern
Teams with people and AI agents
The same questions apply when 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 — what 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
Two sources stand behind parts of this page. The idea of cognitive load as the constraint that should shape a team comes from Team Topologies by Matthew Skelton and Manuel Pais, which anyone designing teams should read. The observation that systems copy the organization that builds them is Melvin Conway's. I have no affiliation with either, and nothing here speaks for them.
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.