Organization Structure refers to the way people in a business or department are organized. Organization Structure significantly affects culture, ways of working and decision making.
As businesses grow beyond single isolated teams they tend to seek ways to structure themselves in an attempt to make work and people more “manageable”. This is based on the mistaken belief that structure is organization, whereas structure is only one part of organization. Structure can be useful when it reflects desired cultural models and isolates truly separate concerns (e.g. ethical divides in different parts of a business such as tax advice vs. audit assurance) or completely separate brands/business lines. However, by its nature, structure can be divisive.
Every team boundary, or other structural boundary, typically causes a team inbox, backlog or other form of work queue adding to the total Lead Time for work unnecessarily. As a result, structure increases the impedance in the organization to doing a piece of work.
The People View looks at the “soft-practices” involved in communication techniques, team building, decision making, leadership and team forming.
Conway’s Law (1968) states that:
organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations
We have seen this Law reflected in many businesses and organizations across a broad range of activities.
Vertical Conway’s Law: Layering
Where planning processes impose a structure of Portfolio → Programme → Project → Team (even when a Programme only has one project!) we see at least two sets of planning, requirements, architecture, testing effort and artifacts. Typically, we’ve seen a set at Programme and Project layer, but sometimes there’s other sets founded in structural organization within Programmes.
Although this may not be a problem when working on a relatively predictable Product Family where the higher layer represents a common view of integration, architecture and completion in the form of Integration Stories, Solution Architecture and a high Definition of Done unfortunately this often isn’t the case.
When groups of people are structured into layers which stack up vertically to operate on the same piece of work they will create translational layers of work with transactional boundaries between them – typically leading to large amounts of waste and confusion. The Big Picture of HSD implies this sort of structure for big organizations that need to co-ordinate related product family development efforts however we do not recommend this structure is used for all work. We’ve seen many programmes with detailed requirements and architecture work that is in conflict with project level, and even team level views of requirements and architecture. It should come as no surprise that the end result of this confusion of decomposition is a failure to integrate leading to failed projects. Reducing these layers reduces the amount of translation and transactional hand-offs, improving communication.
In contrast we recommend minimizing the middle (programme/controlling) layer and not using the programme structure wherever possible (when a business requires a single product – even a big complex one). As mentioned in Portfolio and Programme Management, Projects and other delivery methods can, and should, exist as stand-alone projects within the Portfolio. This means that the boundaries of a Project will be different if it is part of a programme structure or a stand-alone project.
For small organizations who have a simple set of projects that do not need cohesive formal governance (e.g. most startups) we can also dispense with the Portfolio layer. In this case we recommend the Small Picture of HSD and simply excluding elements of HSD that are not necessary or can be done implicitly in the smaller, simpler organization.
Horizontal Conway’s Law: Structuring
As well as vertical structure we can consider horizontal structure in two ways:
- Structure teams aligned to HSD views (requirements, delivery, metrics, operations etc.) – This is a terrible idea that leads to stove-piped empire building specialisms with transactional hand-offs between them removing a “whole team” mentality to product delivery, quality and delivery of business value. This approach is organizing based on how we deliver value.
- Structuring segments of the business into parallel delivery organizations such as departments, groups, business lines etc. This is a very common model which has a number of variants. This model can lead to a duplication of development effort and so is often augmented with a common base layer as dictated by Enterprise Architecture or Operations concerns. This approach is organizing based on the value we deliver.
Naturally this model has numerous variants based on multiplicity: structured portfolios can sometimes not have programme structures, or a mix of programmes and stand-alone projects etc. Some complex/large organizations may have multiple strategies and so further multiply this kind of structure. Any increase in multiplicity will increase the complexity and introduce risks that need careful attention:
- Duplication of development effort in separate teams
- Duplication of support and improvement effort in silos
- Division of culture into sets of sub-cultures
- Possible fragmentation of Business Value (and Enterprise Architecture) to the point that delivery teams can’t understand how they contribute to business value
- A fragmented business that struggles to create cross-team value streams or even common interest groups
- Fragmented inertia against corporate level decision making and change (leading to an inability to innovate and react to disruption)
Conway’s Law in other areas
As well as thinking about structure and team dynamics, Conway’s Law has a significant affect on culture, as each structurally separated group will develop a separated sub-culture.
Similarly, Conway’s Law has a significant effect on architecture. If an organization is structured into major departments then all must be coordinated to deliver a corporate response to a new challenge. This tends to lead to a number of components or products reflecting the organization structure. Such presupposed architectural division is not necessarily the best architectural response to a problem.
This management and architectural inertia is one of the reasons that small new organizations can out-innovate established businesses in a market. The reinforcement of existing structure by the system is called the Homomorphic Force. This force acts to preserve the structure of system even as the system itself moves from one technology to another, from one platform to another, or tries to change its nature and culture.. Both forms of Conway’s Law and the Homomorphic Force pose a dilemma for any organisation. Should they work with the force or try to break it?
We recommend against trying to fight Conway’s Law, instead design to take advantage of the Law.
Conway’s Law as a Design Principle in HSD
HSD is designed with Conway’s Law in mind. Instead of creating separations between strategy, portfolio, programmes and projects we emphasize the information flow through a holistic team of teams. We use common de-conflicted language throughout an organization, using social practices such as the Product Forum and applying a pull towards Business Value throughout the entire model.
On the various maps such as the Big Picture, we deliberately fade out the differences between areas of concern, either vertically or horizontally mixing roles, activities, dynamics, artifacts and concepts on a single blended diagram to encourage a consideration of holistic cohesion rather than separation and isolation. Some elements on the Big Picture diagram are in between “views” to encourage our readers to think about how these concepts have multiple purposes and perspectives.
There is no point in a team developing quickly if it is building the wrong thing. There is no point in directing the right things if the development teams can’t deliver due to poor organizational structure.
Using Conway’s Law to your advantage
Organize teams in a structure that resonates with the solutions you are trying to create. If you want a single large system/culture, then create a large team. If you want a very modular system/culture, then create many small teams. If you are trying to merge two teams then leaving them as two separate teams with different names and identities, in different locations, will actually reinforce the separation. We recommend building holistic teams that can work on delivering business value across the various concerns involved in software engineering.