Organizational Design and Team Types

A fictional insurer with sixty engineers had four teams: web, services, data, and operations. Every change to its claims process passed through all four backlogs, and waiting for agreement took longer than building. Leadership reorganized the four teams into six, with new names and managers. A year later, the same claims changes still passed through four separate decision and implementation steps, with no improvement in waiting time. The reorganization had moved people without addressing that path of work. Organizational design shapes which systems are practical to build, where decisions are made, and how teams interact. This article uses Conway’s 1968 paper, Galbraith’s Star Model, the public Team Topologies vocabulary, and the GOV.UK Service Manual to examine those choices. The insurer and its redesign are invented examples.

Organizing the team is the first design decision

Melvin Conway argued that a design organization’s communication structure constrains the systems it can produce. His mechanism matters more than the familiar slogan: organizing an effort allocates attention and creates some communication paths while making others difficult. A design that depends on a missing path becomes hard to pursue. The organization therefore influences design before anyone chooses a component or interface; it is not a neutral container for technical work.

Delegation narrows the alternatives each group can explore. Conway illustrated this with a research organization that assigned five people to a COBOL compiler and three to an ALGOL compiler: the resulting compilers had five and three phases respectively. He also described two military services whose joint weapon-system design reproduced their organizational divisions. These are illustrations from his paper, not a formula predicting component counts. In the fictional insurer, the functional division had likewise become the default way to divide claims changes, without anyone evaluating whether that division served the work.

The relationship is an observation, not a rule to obey; the entry on Conway’s law covers that distinction. Conway’s practical advice was to organize around necessary communication and preserve the ability to revise the organization as the system concept changes. He also called for incentives that reward lean, flexible design organizations. A structure that supports today’s design can constrain tomorrow’s, so evaluating the communication paths is continuing work.

Design is more than structure

Galbraith’s Star Model makes the scope of organizational design explicit. Strategy sets direction; structure locates decision-making power; processes govern information flows; rewards encourage behavior; and people policies shape selection and development. The consultancy’s account emphasizes alignment among these choices. A new chart can therefore be only one part of a redesign, and a useful redesign need not change the chart at all.

Decision authority is one important test, alongside process, capability, capacity, and incentives. In this case, data and operations retained the same per-change schema and release decisions, and neither their response process nor the stream teams’ ability to act improved. Retaining those authorities would not itself prove failure: faster support or a better approval process could have changed the outcome. The entries on operating models and where decisions are placed cover the business choices behind that distribution. At team level, ask which routine decisions are delegated, which shared or higher-risk decisions require approval, and how those decisions will be reached in time.

Four kinds of team, and what each is aligned to

Matthew Skelton and Manuel Pais’s Team Topologies provides a vocabulary for designing teams and their interactions around flow of value. Its four types describe an intended alignment, rather than classifying every existing team by its job titles. Read them as design choices to test against the work and the load a team can sustain.

• Stream-aligned team: owns outcomes along a flow of work, usually within a business domain. The aim is to reduce routine implementation handoffs so it can deliver and operate changes within an agreed scope. It can still consume shared services and follow necessary risk approvals or shared-contract decisions. The glossary entry explains the alignment and its limits.
• Platform team: develops an internal product that helps stream-aligned teams deliver by reducing repeated complexity. The product framing is covered in platform as a product, and the scope of that responsibility in The Load Has to Land Somewhere.
• Enabling team: helps other teams overcome capability gaps through focused, temporary engagements. The support to a particular team is temporary; the enabling team can remain in place and move to another engagement.
• Complicated subsystem team: holds specialist mathematical or technical expertise, such as an actuarial pricing engine, so consuming teams can work through a supported interface without mastering its implementation.

Functional teams can own outcomes: a database operations team may be accountable for recovery and availability. In the insurer, the problem was the four serial backlogs on ordinary claims changes, not the mere existence of specialist teams. Giving those teams new labels would not resolve it. The design task was to decide which claims work could be delivered within a stream team, which capabilities should remain shared, and how to make the necessary coordination dependable.

The GOV.UK Service Manual complements this vocabulary with roles and skills. It describes multidisciplinary service teams with access to product management, service ownership, delivery management, research, content, design, and development; the required mix changes over a service’s lifecycle. Access to a specialist needs a defined support scope, sufficient capacity, response expectations, and an escalation route. It does not guarantee zero waiting. The manual pairs the service owner’s decision-making authority with responsibility for following necessary project and approval processes. The entry on service owner explains that accountability. Team type and role answer different questions.

Question	Team type answers it	Roles answer it
What is this team aligned to?	A flow of change, an internal product, other teams’ obstacles, or a hard subsystem	—
Who can decide what, inside the team?	—	Service owner, product manager, and the others; each with a stated authority
Which skills must be available, and on what terms?	—	The multidisciplinary skills, with support scope, response expectations, and escalation
How does this team relate to others?	The interaction modes below	—

A team aligned to claims needs clear authority for its routine work and a workable route for decisions beyond that authority. Requiring review for a shared schema or a high-risk release can be compatible with ownership. The failure to look for is a mismatch between the team’s commitment and the decision rights, support capacity, or approval response it can actually rely on.

Three ways to interact, each with a price

Team Topologies describes three interaction modes. Naming a mode helps expose its purpose and coordination cost, provided the description matches what teams actually do.

• Collaboration: teams work closely for a defined period to discover or develop something together, such as an interface or practice. It requires substantial shared attention.
• X-as-a-Service: one team consumes a capability provided by another through a clear service boundary, with limited routine coordination.
• Facilitation: one team helps another build capability through focused, temporary support.

Collaboration and facilitation need a purpose, review point, and exit criteria. That does not prescribe a universal proportion of service relationships. Teams may consume an existing service while collaborating on a new capability. Nor is sequential waiting the same as collaboration: the insurer’s four backlogs were handoffs, not necessarily joint discovery. Examine whether each interaction provides needed learning, a dependable service, or an avoidable delay before changing its mode.

The GOV.UK manual gives a useful enabling example: a quality specialist can join a team temporarily to help it build quality into ordinary development, leaving the team capable of maintaining that practice. The service owner retains final responsibility for quality. An engagement without exit criteria risks becoming indefinite support, but that omission does not make it a functional team by definition. At review, assess the capability achieved and decide whether to finish, change the support, or extend it for a stated reason with another review date.

The CNCF platforms white paper describes reduced coordination as a benefit platforms should provide. A service boundary can support that aim, but a written request path becomes self-service only when fulfillment and controls have actually been implemented and tested. Incidents, exceptions, and changes to the shared service still need human coordination. DORA’s account of its 2024 research reports a 5% productivity improvement at team and individual levels associated with developer independence: the ability to perform tasks without relying on an enabling team. The figure concerns productivity in that research, not a measured percentage of dependencies or handoffs removed, and it is not an effect estimate for this insurer.

Writing the boundary down

A Team API records how other teams can interact with a team. The Team Topologies template makes its purpose and place in the organization explicit through fields for team type, platform membership, services, service level expectations, software ownership, versioning, and contact information. Tables record current and expected interactions, including the other team, purpose, mode, and duration. These fields describe a boundary; they do not implement a service or enforce its rules.

The duration field gives teams a reason to review an engagement, not a deadline that solves a boundary problem by itself. The claims and policy teams could finish their joint work, move suitable work to a service relationship, redesign the boundary, or justify an extension with a new review date. The template describes a snapshot, so teams should check it when responsibilities or services change and periodically confirm whether it remains accurate. Team Topologies encourages adaptable boundaries; the organization must still define who may negotiate a change and how decisions outside that authority are resolved.

A boundary must also fit the team’s cognitive load. End-to-end accountability requires understanding the service contract, failure behavior, and diagnostic path, but not every implementation detail of every dependency. Platforms and other supported abstractions can reduce what the team must carry. Additional responsibility may fit existing headroom, or require staffing, training, simpler tools, narrower scope, or removal of other work. Test that capacity explicitly. The entry on the thinnest viable platform discusses how much shared support to build.

What changes as the organization grows

Growth increases the number of potential communication relationships. For n people, there are n(n − 1)/2 distinct unordered pairs: 105 at fifteen people and 1,770 at sixty, about 16.9 times as many. This is the potential complete graph, not a count of conversations, meetings, or work. Actual coordination depends on the paths used, task frequency, participants, and available capacity. Conway used the growth in possible paths to motivate selective communication structures; it does not by itself explain the insurer’s delays.

Conway discussed a conventional hierarchy with one superior and approximately seven subordinates as one way of restricting communication. It was a historical illustration, not a staffing rule for every organization. The insurer’s evidence came from its claims workflow: decisions and implementation passed through four separately managed backlogs, even when the work was closely coupled. That observed path, rather than the reporting chart alone, justified examining the boundaries.

Clear interfaces can reduce repeated negotiation when work stays within an agreed contract. There is no inverse-square law specifying how many decisions must become self-service as headcount grows. Choose changes from observed demand and delay. A Team API states service expectations; separate tooling and capacity must fulfill them. enabling constraints can define a preauthorized scope, with tested controls and an exception route, rather than removing review merely by writing a rule. Explicit decision rights and an advice process can identify who decides and whom they must consult. Conversation remains necessary for discovery, incidents, exceptions, and shared-contract changes.

Conway also warned that managers can feel pressure to assign all available people to an effort even when the design cannot absorb them. An organization can then search for work to justify its own size. This is a reason to examine a team’s continuing purpose and contribution, not to assume that a larger team is necessarily wasteful. Alongside the boundaries, review the demand and responsibilities each team is expected to support.

Team Topologies emphasizes both stable teams and adaptation as needs change. Shared context takes time to develop, while accumulated boundary problems can make a large reorganization disruptive. Review boundaries regularly, but change them when evidence warrants it. Stability need not mean fixing every responsibility permanently, and frequent review need not mean moving people every time.

Using the organization as a design lever

The inverse Conway maneuver uses organizational structure to encourage a desired architecture.

Three considerations make the maneuver reviewable, without guaranteeing success. First, describe the desired architecture in terms of business flows and dependencies clearly enough to evaluate team boundaries. Second, give teams authority for routine changes within an agreed scope, alongside explicit shared-contract approvals, risk decisions, and escalation routes. Ownership does not require unilateral permission to change every schema or release. Third, treat the structure as a hypothesis to revisit as evidence changes. The maneuver selects organizational constraints; it does not eliminate them.

One misuse is to choose an architecture only because it matches a preferred organization chart, or to copy another company’s teams without examining its business and dependencies. Team Topologies cautions that using team types alone as an org-chart exercise is unlikely to deliver its intended benefits. In the insurer, the naming exercise had left the problematic workflow intact.

The insurer, redesigned

Here is what the second attempt at the fictional insurer looked like, with the reasoning attached to each choice, since the reasoning is the transferable part. The head of engineering began not with the chart but with the flows: the business had two streams of change that mattered, claims and policy administration, and a third, pricing, that changed rarely but required actuarial knowledge nobody else had. She drew the current path of a claims change on a wall, the technique value stream mapping exists for, and found that a change spent most of its calendar time waiting at three of its four handoffs.

The redesign formed claims and policy stream teams with front-end, back-end, and database skills. Each received authority for routine schema and release changes within an agreed scope. The old per-change review was removed only for changes covered by tested compatibility and policy checks; shared contracts and higher-risk changes retained named approval and escalation paths. A complicated-subsystem team offered the pricing engine as a service. The former operations team and two data engineers built database provisioning and migration tooling, with tested fulfillment, service level expectations, and support capacity. Its success would be assessed through task completion, time, failures, and effort on both sides, alongside user feedback. Contact counts could reveal support demand but were not a target to minimize. Finally, two senior engineers undertook a quarter-long enabling assignment for observability, with an exit criterion: both stream teams could instrument and diagnose routine changes within the agreed scope. That quarter was a local staffing choice; an enabling team could instead remain in place across successive engagements.

Every team wrote a Team API. Claims listed platform and pricing consumption as service relationships, observability support as facilitation, and joint work with policy on a shared customer table as an eight-week collaboration. At the review date, the teams would assess migration and compatibility evidence, then finish, change the boundary or mode, or justify an extension with a new review date. Escalation was available where their authority was insufficient. The old standing meeting had not created that decision process. The new date made progress reviewable, but did not itself untangle the table.

After the shared-table migration, the intended routine claims changes within the delegated scope would pass through one implementation team instead of four. This did not remove runtime reliance on platform and pricing services or coordination for shared and higher-risk changes. Whether delivery improved still required measurement, as described in measuring friction. The platform retained a product manager, whose role is explained in a separate article, and was not made mandatory for every task. A quarter-end review would examine outcomes, support load, approval response, and whether the Team APIs still described the work.

Suppose the fictional insurer later adds an AI-assisted claims-triage capability. Before moving staff or expanding the stream team’s mandate, identify who owns each dependency. A data owner agrees the permitted claim population, label meaning, access, and quality contract; a model owner supplies evaluation and monitoring evidence; the AI platform team operates the shared runtime and access controls within its service agreement. The application team owns integration, failure handling, and the route for staff review. The business process owner decides how a recommendation may affect claims work, including overrides and required approvals. The director remains accountable for a feasible allocation of staffing and authority, with named escalation for unresolved risk and funding decisions. Validate those contracts and the receiving teams’ capacity before a wider rollout. If operating evidence shows a boundary mismatch, review the staffing, support, or delegated scope rather than assuming that adding an AI team name resolves it.

What a reviewer should ask

A proposed team structure can be reviewed with a short list of questions, and each traces back to something above.

• For representative changes, which implementation steps and approvals cross team boundaries, and where is time spent? Separate these from runtime service dependencies; unchanged team counts do not prove an ineffective redesign.
• What outcomes and responsibilities does each team own, and does its intended alignment fit the work? Functional teams can own outcomes too; inspect actual handoffs and capability needs.
• Which decisions are delegated, which require shared or risk approval, and how quickly can each be resolved? Also examine process, support capacity, skills, and incentives when authority stays in the same place.
• What purpose does each interaction serve? For collaboration or facilitation, define the review point, exit criteria, and possible next steps. Do not label sequential waiting as joint discovery.
• Can each team sustain its responsibilities with its current headroom and support? Assess abstractions, skills, staffing, and scope before deciding whether work must be removed.
• Is any team present because it has work, or because it exists? Conway’s warning about an organization in need of work applies to teams as much as to design efforts.
• When will boundaries be reviewed, who can change them, and how are proposals beyond that authority resolved? Executive approval can be appropriate; evaluate the clarity and timeliness of the process.

The second proposal answers questions the first had left open, but paper review establishes only a design hypothesis. Delivery time, reliability, support load, and decision response after implementation must show whether it helped. Organizational design is useful when it connects the work to the communication, authority, and capability needed to perform it, and provides a way to revise those arrangements when evidence changes.

References

• Melvin E. Conway, How Do Committees Invent?, Datamation, April 1968, reprinted on the author’s site.
• Matthew Skelton and Manuel Pais, Team Topologies: Key Concepts.
• Team Topologies, Team API template (CC BY-SA 4.0).
• ThoughtWorks Technology Radar, Inverse Conway Maneuver, Trial, 8 July 2014; last updated 28 January 2015. ThoughtWorks included it at Trial in the Technology Radar on 8 July 2014; the entry was last updated on 28 January 2015. Its absence from the current Radar does not establish that the idea became widely adopted or mature. The Radar FAQ explains that items can leave when there is no movement or new discussion and that older entries are not continuously updated. Treat this as a historical recommendation, not a current adoption verdict.
• Galbraith Management Consultants, Star Model.
• GOV.UK Service Manual, What each role does in a service team, updated 6 November 2023.
• CNCF TAG App Delivery, Platforms White Paper.
• DORA, Platform engineering.
• ThoughtWorks Technology Radar, Frequently Asked Questions.