Team

Origin & evolution

The cross-functional product team displaced the older model of separate design, engineering, and QA departments passing work between them. Amazon's "two-pizza team" rule, the idea that a team should be small enough to feed with two pizzas, became the most quoted heuristic for keeping a group small enough to move fast and stay coordinated. The principle is about communication overhead: every person added multiplies the lines of coordination, and past a point the team spends more energy syncing than shipping.

The sharpest current model is Team Topologies, by Matthew Skelton and Manuel Pais (2019), which names four team types: stream-aligned, platform, enabling, and complicated-subsystem (Team Topologies). A stream-aligned team owns a value stream🌊Value StreamStrategyAn end-to-end flow delivering value to the customerView reference → end to end with no hand-offs; a platform team builds self-service capability💪CapabilityStrategyAn ability that enables value deliveryView reference → that lightens the load on the others; an enabling team boosts a skill and then moves on; a complicated-subsystem team holds deep specialist knowledge (IT Revolution).

The organising idea beneath those types is cognitive load. Skelton and Pais argue you should size and bound a team so the system it owns fits within what the team can actually hold, and use the platform and enabling types to keep stream-aligned teams from drowning. That reframes team design from an org-chart exercise into a question of how much complexity any group can carry, which is where the discipline has landed.

How it works in practice

A fifty-engineer product organisation keeps shipping late, and the diagnosis is overload: three stream-aligned teams each own a customer-facing area but also maintain the shared deployment📤DeploymentEngineeringA deployment eventView reference → pipeline, the auth system, and the data platform between them. Every team carries extraneous load that has nothing to do with its value stream.

They reorganise on Team Topologies lines. A platform team forms to own deployment and auth, exposing them as self-service so the stream teams stop maintaining infrastructure. An enabling team spends a quarter raising the stream teams' testing practice, then disbands. The data platform, genuinely specialist, becomes a complicated-subsystem team. The stream-aligned teams shed the load that was not theirs, and lead time on customer features⭐FeatureProduct SpecificationA product capability or featureView reference → drops because each team now reasons about a system that fits inside its head.

Team vs. its neighbours

• Department is the functional grouping by discipline (engineering, design, marketing), often a reporting line and a budget. A team is cross-functional and outcome-owning. A department🏬DepartmentTeam & OrganisationAn organisational departmentView reference → may contain many teams via department_contains_teamDepartmentcontainsTeamhierarchy, but a department ships nothing on its own; a team does.
• Role is a function a person performs within a team (engineer, designer, product manager). The team is the unit that delivers; the role is a slot inside it. One person may hold a role across more than one team.
• Dependency⛓️DependencyTeam & OrganisationA cross-team or system dependencyView reference → is a thing one team needs🫀NeedUserA user need, pain, desire, or constraintView reference → from another to make progress. It is the relationship that exposes coupling between teams; a team overloaded with dependencies is rarely the autonomous, end-to-end unit the model intends.

In the graph

In the Unified Product Graph, a team is a container in the Operations & Quality region, within the team and organisation domain. A product connects to its team via product_staffed_by_teamProductstaffed byTeamhierarchy, and a department holds teams through department_contains_teamDepartmentcontainsTeamhierarchy. Coupling shows through two dependency edges: dependency_depends_on_teamDependencydepends onTeamcross-domain names a team a piece of work relies on, and dependency_blocks_teamDependencyblocksTeamcross-domain names a team held up by an unmet need. Modelling those dependency edges on the team is what surfaces the cognitive-load problem structurally: a team tangled in inbound and outbound dependencies is visibly not the autonomous, stream-aligned unit Team Topologies argues for, and the graph makes that coupling queryable.