Organization structure

The People View looks at the “soft-practices” involved in communication techniques, team building, decision making, leadership and team forming.

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.

Every organization is different, it’s culture and people will want or need different structures to be effective. Applying a structure without understanding the aims, work and most importantly, the people, in an organization will only cause problems.

Conway’s Law

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:

  1. 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.
  2. 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.

Team Models

There are a number of ways of forming teams:
 Discipline Teams
Discipline Teams are formed by making teams around technical specialists.
This approach leads to requirements teams, testing teams, development teams, management teams etc. We strongly recommend against this approach as there is significant cross-team coordination required to deliver anything. We’ve observed that most integration problems are caused by team-of-teams working, and this approach forces team of teams working. Typical problems include:
  • Cross-team conflicts caused by abdication of responsibility for quality
  • Cross-team conflicts caused by unclear Definitions of Done
  • Discipline teams begin to care more about discipline maturity than business value delivery
  • Discipline teams begin a process scope-creep to other areas (e.g. test teams trying to control defect lifecycles within development teams)
  • Discipline teams become increasingly abstract talking shops, they don’t actually deliver anything
Component/Service Teams
Component/Service Teams are formed by making teams around architectural components.
This approach leads to GUI teams, middleware teams, database teams etc. We generally recommend against his approach for entire systems as user facing changes require the coordination of multiple teams. Along with many of the problems of Discipline Teams we also see Component Teams caring more about the purity and architectural separation of their component more than Business Value delivery.
Feature Teams
Feature Teams are formed by making teams around significant areas of user facing functionality. Feature teams are cross-functional in the sense that they can work across the entire architecture, and all components or services to deliver an end to end user requirement.
This approach can be implemented in 2 ways:
  • Requirements based – Feature teams are created to deliver a particular end to end requirement (e.g. an Integration Scenario)
  • Stable team – Feature teams are created to be enduring. The teams then pick end to end requirements, such as Integration Scenarios, off a backlog one by one
Feature teams also have disadvantages in that there is often overlap between Integration level requirements within system architecture and delivery, and so a mechanism for conflict resolution needs to be put in place (e.g. a Product Forum). This approach can also lead to no one team doing the “common good” work that’s general enough to not be considered part of an end to end requirements but still necessary to achieve good quality.
Platform vs. Application Teams
A mix of Component and Feature approaches is to build:
  • Platform teams that are organized around an enabling architecture, common services and APIs. A platform team is essentially a multi-component team that is focused on “common good” work at all times.
  • Application teams that are organized around end to end requirements, building applications or services on top of a Platform. The work of various Application teams will drive priorities on Platform teams.
Although this model provides the best of both worlds it frequently leads to conflict between application/service teams and platform teams and so we recommend using the Product Forum practice to coordinate.
Holistic Teams
We recommend that teams include a mix of people with all of the skills needed to take a business requirement from an initial problem, through candidate approaches and eventually to a deployed live product.  In tune with DevOps philosophy Holistic Product teams support what they make, incentivizing to make high quality products and foster good relationships with their customers.
Every case is different but in the general case we’ve had significant success with a combination of Holistic Product teams for single products and Holistic Platform & Application Teams for Product Family development.

Structural Models


Hierarchy is a system in which members of an organization or society are ranked according to relative status or authority.

Generally, hierarchy is instantiated in structural relationships within an organization where people report to a layer above and those people to a smaller layer above and so on in a rough triangle shape. “Hierarchy” is often thought of as a negative because a number of dysfunctions have their root in hierarchy:

  • Excessive layers – hierarchy can lead to many intermediary layers between Delivery Teams and Business Leaders obscuring communication and causing transactional and transformational behavior between layers (Vertical Conway’s Law)
  • Top-Heavy delivery – even minimal layers of hierarchy can introduce management around a delivery team, looking at the people involved as a whole we sometimes see a high ratio of “managers” to “doers” sometimes we even have seen more “managers” than “doers”. A Delivery Team of 5 probably needs no managers and yet sometimes we see small teams surrounded by 10 or more “managers” adding inertia and causing confusion. This form of organizational bloat is pure waste, cut it. In HSD we measure this using the Workforce Shape metric.
  • Value fragmentation – Because hierarchy encourages decomposition it can lead to functional decomposition through team structures (Horizontal Conway’s Law)

However, not all hierarchy is inherently bad. Indeed, some form of hierarchy always exists in human social structures – even when they try to suppress it (e.g. holocratic groups, communal ownership groups, co-operatives). These groups are always created, funded and supported by Leaders. Leaders may try to abdicate control and ownership but it implicitly remains with them since they’ve given control to the group. This is the difference between empowerment and autonomy. Since successful revolution is unusual in business we always see a small amount of hierarchy remain.

Holacratic groups in particular tend to organize into a set of “circles” that aggregate to a “higher level” circle. Since it isn’t cost effective for everyone to be in every circle, membership is normally limited meaning that circles report to “higher” circles who in turn report to the next circle etc. Essentially a standard hierarchy. Even the flattest, most transparent, companies have an implicit hierarchy – unless every employee is a shareholding director with equal voting rights.

Excessive hierarchy causes negative behaviors but some level of hierarchy is practically unavoidable, especially when more than one team is involved and/or people are working for other people. However, we explicitly encourage organizations to minimize layers and reduce hierarchy, ensuring that resourcing across layers is sensible. Every team must be able to express their value proposition to the business, and not in terms of handing over a slightly transformed product of another team.

Even when a hierarchical structure is well intentioned, over time portfolios are likely to overlap, as are programmes, projects and other delivery groups meaning that communication lines are multiplied across the hierarchy in a mess. The following structure is a real team structure taken from a large software organization:

Initially, the organization’s business was split into 4 vertical business lines.  However over time these concerns converged onto common IT platforms as storage and processing became commodities. This led to overlapping requirements in programmes that were part of each portfolio. As a result, Delivery Teams had often conflicting requirements from multiple programmes. Because many of the Products were large the organization formed “Projects” containing multiple teams. Due to this structure being the standard approach to work in the organization even an isolated Product also had to fit into this structure (as shown on the far right of the diagram) which meant that there were 3 layers of management above the Product Team.

You’ll notice that “Customers” are nowhere to be seen on this diagram, in fact customers created an orthogonal management structure that caused more confusion:

This is more similar to a matrix organization (described below) than a simple hierarchical organization. Clearly this mess of communication lines causes problems, and is only exacerbated by introduction of more structure or more layers. The Workforce Shape metric looked fairly bad when applied against this structure, but because no one was looking at software holistically in the organization the problem hadn’t been spotted.
Individuals were all trying to do a good job, and be professional in their roles but didn’t recognize they were actually part of the systemic problem of over-management that had evolved over time. Obviously that was a difficult message for the organization to accept.
We strongly recommend that organizational structures are kept as simple and unstructured as possible so that people are free to collaborate in whatever forms are necessary to deliver as a holistic team. Separation into roles, layers, functional groups and other common “ivory towers”, even with the best intentions, cause significant problems in delivery.
There are a number of structural patterns organizations use to deal with scale of resources, each has its advantages and disadvantages.

Matrix organizations have more than one reporting line. Typically, in software based organizations personal management (line management) is de-coupled from technical management. Matrix structures imply flexibility by allowing technical groups to be re-organized without affecting line management structures. However, because of the fragmentation of concerns we often hear the complaint:

My line manager doesn’t know anything about my day job

The intended flexibility of such models is in practice difficult to achieve and hindered by bureaucratic processes around career development that are introduced to recombine the de-coupled aspects of technical and line management. These structures tend to mean that everyone has at least two managers, which in itself can be a problem and cause conflicts if those two managers are not aligned. We challenge the idea that professional skilled people need a manager at all and encourage individuals to take ownership of their own careers rather than abdicate responsibility to an appointed manager.

The diagram we show here is of course a simplistic version of matrix management, in real organizations it tends to be more complicated. We have found that matrix organization tends to lead to a lack of clarity on priorities between orthogonal structures and power struggles between orthogonal parts of the split hierarchy.

Value Stream / Product Families / Vertical Business Lines

We consider organization by Value Stream, Product Families and Vertical Business Lines to be essentially the same thing. They are examples of Conway’s Law applied horizontally as mentioned above. As Product Families that are part of separate Value Streams are Vertical Business Lines.

Although this is a tempting structure that looks quite clear it has some dangers. Typically, over time business value will move to cross the vertical lines as technologies converge and new opportunities arise. As a result, even when an organization in a period of stability has well separated portfolios as periods of disruption occur they tend to turn into less well structured hierarchies.

Common technologies (which are continuously created by the commoditization of technology) mean that separated portfolios will cross over where they meet common services. Note that the diagram above shows simplistic communication lines, if we increased the multiplicity to include every team it would look a lot messier, and as programmes start to overlap it quickly turns into the previously described dysfunctional hierarchical mess.

This mess can be avoided however, at a large scale, if the portfolios are truly separate and operate in different market segments in large corporations. Alternatively, such a structure may even be desired if duplication of products is required (e.g. to provide resilient capability). We only recommend structure by Value Stream for stable, well understood businesses. However, such structures must be carefully managed to avoid classic management pitfalls, empire building, hierarchical problems and management inertia as occurred above.

Hybrid Dynamic Model

The Hybrid Dynamic Model is a modern approach to structuring an organisations portfolio that allows for multiple ways of working to co-exist from innovation to utility work and for that work to change which processes, cultures and practices it uses over time.

An “Operating Model” describes how an organisation does its business in terms of both its structure and its behaviour – it is the business architecture. An “Operating Model” exists in every organisation, whether it is explicitly written down or simply a collection of processes and practices. The Operating Model includes how strategy flows through planning and delivery, how money is spent and controlled, how governance works, how people are organised and how quality is assured. If the Operating Model is inefficient or unable to react well to change, everything else suffers.

Many organisations evolve an Operating Model that fits their stable way of working, allowing for a focus on efficiency and improvement, driving out variation. This approach can work well in periods of stability but makes organisations brittle and unable to react well to change because the only way the organisation knows how to deal with events is to apply its tried and tested approaches. When the environment is less stable, or the variety of work types increases a Hybrid Dynamic Model is more appropriate.

As organizations recognize that their types of work are different they frequently evolve a Bi-Modal paradigm that involves treating New Investment differently from legacy operations. This creates a two-speed organization, often correlating with the use of Project Management for new work and managing out variance (e.g. with ITIL) for operations/support work. Bi-Modal IT is short sighted, as it doesn’t account for evolution and change. Instead we recommend considering Commoditization as a way of thinking about types of work.

Bi-Modal IT is an example of the black-or-white logical fallacy

A useful mechanism for understanding different types of work, and the different approaches that may be applicable to delivering them within a portfolio is the “Commoditization Scale”. The Commoditization Scale describes a range of types of work from innovation (undefined, rare, speculative and high risk) to more commodity/utility (well defined, ubiquitous, and less differentiated with lower risk).

These different types of work require different ways of working, contractual models, technologies, supply chains, cultures, processes etc. More well understood work is more predictable and manageable by its nature, whereas the opposite is true for less well-understood work.

Commoditization scale originally inspired by Simon Wardley, LEF CSC

As organisations begin to understand their work in terms of a hybrid model they can then look to actively apply a commoditization pressure where possible moving work across this scale. Because commodity solutions (often bought in) are typically cheaper than in-house development, maintenance and hosting commoditizing work earns a “Commoditization Dividend” which can then be used to reinvest into the Innovation parts of a business.

As mentioned in Build or Buy we generally recommend against building utility or commodity components, systems or product (unless disrupting a service industry) – these kind of products are best bought (COTS) or provided by open source alternatives. However, in terms of inventing/innovating and specialist products we see that different processes, working practices, teams and cultures may be necessary. Innovation work is typically riskier and more speculative than more mainstream specialist product development and so will be less tolerant of up front planning. “Failing fast” is particularly important in innovative/inventive work and this type of work is often very unpredictable. As a result, building significant structure (in terms of project, programme and Solution Architecture) around innovation work is unlikely to be productive – this work may also be unconstrained, thought informed, by Enterprise Architecture (and indeed “standard” ways of working).

Unless explicitly necessary we recommend that innovative work is treated as self-organized Product Delivery teams that are directly part of the Portfolio, with no programme structure. This (Small Picture) model is preferred for small, simple projects or organizations generally. Small organizations can often outperform large monolithic organizations due to their lack of process, management and architectural inertia – they are free to innovate. Since the relentless commoditization of technology forces all organizations to innovate to survive we strongly recommend freeing people to innovate in whatever manner they need.

There’s nothing worse for innovation than an ideas process

Similarly, and perhaps counter intuitively, there is also less structure required in the Utility and Commodity areas of the commoditisation scale (because the products built are often well-understood, predictable and frequently COTS, much of this work is system integration). This type of very predictable work often benefits from workflow management techniques such as Lean, Kanban or service management processes.

Products that are more Specialist may need a “bigger engineering” approach depending on their scale or risk factors. Many large organizations will adopt more formal processes in this area as they seek to find economies of scale, especially around reuse. However, over time reusable platforms and architectures can become a hindrance rather than a help. Technically skilled people will notice this point and are encouraged to Bubble Up their concerns. Organizations with significant effort in more than one of these areas of the scale above tend to gravitate towards a hybrid model with a structure embedded in the Specialist, Commodity or Utility part of the business. Applying the same structures, architectures, processes and working practices across all of these work types, ignoring their differences, can cause serious problems so a hybrid model is likely to be required for large/complex organizations.

We recommend using a hybrid, dynamic model for organising a large/complex portfolio. Large, complex organisations have significant effort and coverage across the commoditisation scale. Implementation of a hybrid model caters for this variance using unstructured and structured models where necessary. Structure is introduced only by exception when explicitly needed to orchestrate effort across divergent teams and portfolio(s) not as the default approach. Importantly as pieces of work become more understood, or product sets evolve they will likely begin to move on the commoditisation scale and so may need to dynamically change their ways of working.

Any problem or piece of work, including running a business and software development, can be considered in terms of its complexity. Problems range from the simple to the complicated and complex.

 Read more: Simple, Complicated and Complex

The Hybrid Dynamic Model allows for significantly different ways of working, within the cohesive governance of the H-Model of Holistic Software Development. Using the hybrid dynamic model organisations can have multiple ways of working, cultures and practices co-existing peacefully within a single enterprise portfolio. Using different ways of working, practices and techniques across the portfolio helps bring together the otherwise extremely different extremes of innovation and research work with predictable project delivery. Other business models, such as Incubation, can also be used to help bridge the gaps between areas such as innovation and mainstream engineering practices.

Many organisations evolve a Portfolio → Programme → Project → Team model which is then applied to all work in the portfolio due to its past success at delivering large predictable technology projects. However, this model is wasteful when complexity is low and can actually inhibit communication and feedback cycles in high complexity work that is more speculative. The traditional programme/project model can work for mid-complexity predictable work.

Programme and project structures cause layers of separation, which result in emergent transactional behaviour, effort duplication and confusion over roles and responsibilities. As a result, programmes should only be used when there is a genuine requirement for co-ordinating multiple projects that must be integrated for a cohesive product family or business capability. In other cases, programme structures should be condensed – removing programmes that are simply funding lines; Portfolio Management can and should manage funding lines. Stand-alone projects can simply be part of the portfolio.

Reduction in structural complexity will reduce costs, increase flexibility and adaptability while simultaneously improving an organisations ability to react in a rapidly changing environment. Additionally, simplifying structure will reduce the sheer numbers of people involved in project management and supporting work, removing unnecessary barriers between delivery teams and their customers.

This kind of hybrid structure is similar to using the Small Picture of HSD for the pieces of work in the Commodity Portfolio, the team-of-teams delivery elements of the Big Picture for the Specialist Portfolio (and other small team structures) and the Small Picture again for the Research and Innovation portfolio – sharing the same Strategy and Governance layer of the Big Picture.

COTS implementation may be a signficant piece of work by itself. The COTS Implementation article describes a variant of the Big Picture for use with COTS.

Adoption of the Hybrid Dynamic Model is actually relatively easy, as you simply add it to what you’re currently doing. Regardless of your current structure and operating model, allow variants that are approved ways of working for different types of work. Over time organizations can adjust the amount of work in each part of the model to suit the work, people and disruptive change.