Department

Origin & evolution

Functional departmentalisation is the oldest move in organisation design: group people by what they know, so that expertise compounds and managers can manage like-for-like. The cost is the silo. When delivering one unit of customer value requires Engineering, Design, and Product to coordinate across departmental walls, the dependencies⛓️DependencyTeam & OrganisationA cross-team or system dependencyView reference → multiply and throughput drops (LogRocket).

The sharpest claim about why department boundaries matter came from Melvin Conway. In "How Do Committees Invent?", published in Datamation in April 1968 after Harvard Business Review rejected it, he argued that "organisations which design systems🧰Design SystemDesign SystemThe root design system entityView reference → are constrained to produce designs which are copies of the communication structures of these organisations" (Conway, 1968; Wikipedia). Fred Brooks cited it in The Mythical Man-Month and gave it the name Conway's Law. The modern reading, the "inverse Conway manoeuvre", is that you can shape the system you want by first shaping the org chart that will mirror it.

Skelton and Pais codified this move in Team Topologies (2019), naming it the "inverse Conway manoeuvre" and placing it at the centre of their argument: decide first what team-interaction model you need🫀NeedUserA user need, pain, desire, or constraintView reference →, then reshape departments and reporting lines to make that model possible. Their four team types — stream-aligned, enabling, complicated-subsystem, and platform — each carry different cognitive load profiles and different expectations of how much cross-department coordination is required. By that reading, a department boundary is not merely an HR artefact; it is an active constraint🔒ConstraintStrategyA limit, requirement, or ceiling the product must respect, whether a self-imposed principle or an externally imposed boundaryView reference → on which team types are sustainable and how quickly those teams can deliver.

The field's response to functional silos was the cross-functional team: people grouped around a product or mission🧭MissionStrategyThe purpose and reason the product existsView reference → for all of their time, rather than by discipline (Wikipedia). This is why department and team are separate concepts in any serious model. A person belongs to one department for their career and one team for their mission, and the two memberships are often orthogonal.

How it works in practice

A 120-person company runs four departments: Engineering, Product, Design, Operations. Its eight delivery teams are cross-functional, each pulling an engineer or three, a designer, and a PM from across those departments. An engineer reports to the Engineering department for her ladder, pay, and craft, and sits on the Checkout team for her daily work. When Conway's Law is taken seriously, leadership notices that a planned monolith-to-services split keeps stalling because two services are owned by one department; they move the boundary, give each service its own cross-functional team, and the architecture follows. Department defines the home; team defines the mission; the product mirrors whichever boundary is real.

Will Larson's An Elegant Puzzle (2019) addresses exactly this dual-membership tension from the engineering manager's perspective. Larson argues that the functional department (Engineering, in his framing) is the right home for hiring bars, performance calibration, and technical career ladders, while the delivery team is the right unit for prioritisation and daily work — and that conflating the two creates managers who are either too far from craft or too far from product outcomes🏆OutcomeStrategyA desired business or user outcomeView reference →. His treatment of team sizing and when to split or consolidate teams also bears on department design: departments that grow without splitting their delivery teams tend to accumulate coordination overhead until throughput collapses.

Department vs. its neighbours

• Team is a working group assembled to deliver something, often cross-functional and re-formed as missions change. A department is a standing functional home that owns headcount and the career ladder. A person typically belongs to one department and one team, and those are different memberships.
• Organisation is the whole entity; the department is a functional slice of it. One organisation contains many departments, and the product itself is organised into departments through a direct edge.
• Stakeholder🧑‍💼StakeholderTeam & OrganisationA person with influence over the productView reference → is a position of interest in the product. A department includes stakeholders (a department head who must sign off, for instance), which is how a functional unit attaches to the decisions⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → it cares about without being reduced to them.

In the graph

In the Unified Product Graph, department🏬DepartmentTeam & OrganisationAn organisational department is a container in the Operations & Quality region, team_org domain. Three edges define its place: the product is product_organised_into_departmentProductorganised intoDepartmenthierarchy, a department holds its working groups through department_contains_teamDepartmentcontainsTeamhierarchy, and it attaches interested parties through department_includes_stakeholderDepartmentincludesStakeholderhierarchy. Modelling the product as organised into departments, with teams nested beneath, makes Conway's Law queryable: you can compare the department-and-team structure against the service architecture and see, directly, where the org chart and the system have drifted out of alignment.