Structuring the Organization: Product and Function

Melvin Conway is a computer programmer who worked on early compilers and programming languages. In 1968, he proposed the thesis that: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure” [Conway 1968].

What does this mean? If we establish two teams, each team will build a piece of functionality (a feature or component). They will think in terms of “our stuff” and “their stuff” and the interactions (or interface) between the two. Perhaps this seems obvious, but as you scale up, it is critical to keep in mind. In particular, as you segment your organization along the AKF y-axis, you will need to keep in mind the difference between features and components. You are on a path to have dozens or hundreds of such teams. The decisions you make today on how to divide functionality and work will determine your operating model far into the future.

Ultimately, Conway’s law tells us that to design a product is also to design an organization and vice versa. This is important for designers and architects to remember.

There are many different ways we can apply these ideas of traditional functional organizing versus product-oriented organizing, and features versus components. How do we begin to decide these questions? As a Digital Practitioner in a scaling organization, you need to be able to lead these conversations. The cross-functional, diverse, collaborative team is a key unit of value in the digital enterprise, and its performance needs to be nurtured and protected.

Abbott and Fisher suggest the following criteria when considering organizational structures [Abbott & Fisher 2015]:

Team persistence is a key question. The practice in project-centric organizations has been temporary teams, that are created and broken down on an annual or more frequent basis. People “rolled on” and “rolled off” projects regularly in the common heavyweight project management model. Often, contention for resources resulted in fractional project allocation, as in “you are 50% on Project A and 25% on Project B” which could be challenging for individual contributors to manage. With team members constantly coming and going, developing a deep, collective understanding of the work was difficult. Hard problems benefit from team stability. Teams develop both a deeper rational understanding of the problem, as well as emotional assets such as psychological safety. Both are disrupted when even one person on a team changes. Persistent teams of committed individuals also (in theory) reduce destructive multi-tasking and context-switching.

There is a fundamental tension between functional specialization and end-to-end value delivery – the tendency for specialist teams start to identify with their specialty and not the overall mission. The tension may go by different names:

As we saw previously, there are three major concepts used to achieve an end-to-end flow across functional specialties:

These are not mutually-exclusive models and may interact with each other in complex ways; see the scaling discussion in the Context III introduction.

For example, some manufacturing can be represented as a very simple, sequential process model; see Simple Sequential Manufacturing.

The product is already defined, and the need to generate information (i.e., through feedback) is at an absolute minimum.

(Review Agile Software Development on waterfall development and Agile history.) Functional, or practice, areas can continually increase their efficiency and economies of scale through deep specialization.

A “practice” is synonymous with “discipline” – it is a set of interrelated precepts, concerns, and techniques, often with a distinct professional identity. “Java programming”, “security”, or “capacity management” are practices. When an organization is closely identified with a practice, it tends to act as a functional silo (more on this to come). For example, in a traditional IT organization, the Java developers might be a separate team from the HTML, CSS, and JavaScript specialists. The DBAs might have their own team, and also the architects, business analysts, and quality assurance groups. Each practice or functional group develops a strong professional identity as the custodians of “best practices” in their area. They may also develop a strong set of criteria for when they will accept work, which tends to slow down product discovery.

There are two primary disadvantages to the model of projects flowing in a waterfall sequence across functional areas:

Go back and review: the waterfall model falls into the “original sin” of IT management, confusing production with product development. As a repeatable production model, it may work, assuming that there is little or no information left to generate regarding the production process (an increasingly questionable assumption in and of itself). But when applied to product development, where the primary goal is the experiment-driven generation of information, the model is inappropriate and has led to innumerable failures. This includes software development, and even implementing purchased packages in complex environments.

There is a spectrum of alternatives in structuring organizations for flow across functional concerns. First, a lightweight “matrix” project structure may be implemented, in which the project manager has limited power to influence the activity-based work, where people sit, etc.; see Lightweight Project Management Across Functions.

Work flows across the functions, perhaps called “centers of excellence”, and there may be contention for resources within each center. Often, simple “first in, first out” queuing approaches are used to manage the ticketed work, rather than more sophisticated approaches such as cost of delay. It is the above model that Reinertsen was thinking of when he said: “The danger in using specialists lies in their low involvement in individual projects and the multitude of tasks competing for their time”. Traditional 2-context:06_operations-basics.adoc#tbl-i-o-matrix organizations, when they implemented defined Service Catalogs, can be seen as attempting this model. (More on this in the discussion of ITIL and shared services).

Second, a heavyweight project structure may specify much more, including dedicated time assignment, modes of work, standards, and so forth; see Heavyweight Project Management Across Functions. The vertical function still sets some standards and maintains reporting authority over the team member. Team members may be frequently “rolled on and off” projects, and sometimes fractionally allocated to multiple projects. This has been the most frequent operating model in the traditional CIO organization.

If even more focus is needed – the now-minimized influence of the functional areas is still deemed too strong – the organization may move to a product-based model; see Product Team, Virtual Functions. Team members are dedicated for longer periods and usually not fractionally assigned. Line reporting, however, is still through the functional area. There still may be standards for technical choices. Managing the product team may be based on an “X in a box” strategy; e.g., where the product, engineering, and design leads on that product team must seek consensus on an ongoing basis.

Finally, in the skunkworks model, all functional influence is deliberately blocked, as distracting or destructive to the product team’s success; see Skunkworks Model. Line reporting at this point is to the product team, which may raise issues when specialists in a given area need to report to someone else with a different specialist background (e.g., an engineer reporting to a product manager).

The product team has complete autonomy and can move at great speed. It is also free to:

Early e-commerce sites were often set up as skunkworks to keep the interference of the traditional CIO to a minimum, and this was arguably necessary. However, ultimately, skunkworks is not scalable. Research by the Corporate Executive Board suggests that: “Once more than about 15% of projects go through the fast [skunkworks] team, productivity starts to fall away dramatically”. It also causes issues with morale, as a two-tier organization starts to emerge with elite and non-elite segments [Goodwin 2015]. Because of these issues, Don Reinertsen observes that: “Companies that experiment with autonomous teams learn their lessons, and conclude that the disadvantages are significant. Then they try to combine the advantages of the functional form with those of the autonomous team” [Reinertsen 1997].

The Agile movement is an important correction to dominant IT management approaches employing open-loop delivery across centralized functional centers of excellence. However, the ultimate extreme of the skunkworks approach cannot be the basis for organization across the enterprise. While functionally specialized organizations have their challenges, they do promote understanding and common standards for technical areas. In a product-centric organization, communities of interest or practice provide an important counterbalancing platform for coordination strategies to maintain common understandings.

The functional organization scales well. Just keep hiring more Java programmers, or DBAs, or security engineers and assign them to projects as needed. However, scaling product organizations requires more thought. The most advanced thinking in this area is found in the work of Scrum authors such as Ken Schwaber, Mike Cohn, Craig Larman, and Roman Pichler. Scrum, as we have discussed, is a strict, prescriptive framework calling for self-managing teams with:

Let us accept Scrum and the two-pizza team as our organizing approach. A large-scale Scrum effort is based on multiple small teams; e.g., representing AKF scaling cube partitions; see Product Owner Hierarchy (similar to Pichler 2010 and Schwaber 2007). If we want to minimize multi-tasking and context-switching, we need to ask: “How many product teams can a given product owner handle?”. In Agile Product Management with Scrum, Roman Pichler says: “My experience suggests that a product owner usually cannot look after more than two teams in a sustainable manner” [Pichler 2010]. Scrum authors, therefore, suggest that larger-scale products be managed as aggregates of smaller teams. We will discuss how the product structure is defined in Investment and Portfolio.

We have previously discussed feature versus component teams. As a reminder, features are functional aspects of software (things people find directly valuable) while components are how software is organized (e.g., shared services and platforms such as data management).

As an organization grows, we see both the feature and component sides scale. Feature teams start to diverge into multiple products, while component teams continue to grow in the guise of shared services and platforms. Their concerns continue to differentiate, and communication friction may start to emerge between the teams. How an organization handles this is critical.

In a world of digital products delivered as services, both feature and component teams may be the recipients of ongoing investment. An ongoing objection in discussions of Agile is: “We cannot put a specialist on every team!”. This objection reflects the increasing depth of specialization seen in the evolving digital organization. Ultimately, it seems there are two alternatives to handling deep functional specialization in the modern digital organization:

We have discussed the first option above (split the specialty across teams). But for the second option consider, for example, the traditional role of server engineer (a common infrastructure function). Such engineers historically have had a consultative, order-taking relationship to application teams:

Such processes might take months to complete, and often caused dissatisfaction. With the rise of cloud computing, however, we see the transition from a consultative, order-taking model to an automated, always-on, self-service model. Infrastructure organizations move their activities from consulting on particular applications to designing and sustaining the shared, self-service platform. At that point, are they a function or a product?

Formal organizational structures determine, to a great extent, how work gets done. But enterprise value requires that organizational units – whether product or functional – collaborate and coordinate effectively. Communications structures and interfaces, as covered in Coordination and Process, are therefore an essential part of organizational design.

And of course, an empty structure is meaningless. You need to fill it with real people, which brings us to the topic of human resource management in the digital organization.

Evidence of Notability

Debates over organizational form are frequent of late. The years between 2010 and 2020 have seen a massive shift in many IT and digital organizations, from a focus on deep functional specialization to broader, cross-functional teams. Best practices and lessons, at the time of writing, are still unformed. Works such as Narayam’s Agile Organization Design [Narayam 2015] as well as coverage of the topic in other literature and industry guidance provide evidence of notability.

Limitations

Organization design influences, but does not completely determine, organizational results.

Related Topics