Structuring the Organization: Product and Function
There are two major models that Digital Practitioners may encounter in their career:
The traditional centralized back-office IT organization
Digital technology as a component of market-facing product management
The traditional IT organization started decades ago, with “back-office” goals like replacing file clerks and filing cabinets. At that time, computers were not flexible or reliable, business did not move as fast, and there was a lot of value to be gained in relatively simple efforts like converting massive paper filing systems into digital systems. As these kinds of efforts grew and became critical operational dependencies for companies, the role of Chief Information Officer (CIO) was created, to head up increasingly large organizations of application developers, infrastructure engineers, and operations staff.
The business objectives for such organizations centered on stability and efficiency. Replacing 300 file clerks with a system that did not work, or that wound up costing more was obviously not a good business outcome! On the other hand, it was generally accepted that designing and implementing these systems would take some time. They were complex, and many times the problem had never been solved before. New systems might take years – including delays – to come online, and while executives might be unhappy, oftentimes the competition was not doing much better. CIOs were conditioned to be risk-averse; if systems were running, changing them was scrutinized with great care and rarely rushed.
The culture and practices of the modern IT organization became more established, and while it retained a reputation for being slow, expensive, and inflexible, no-one seemed to have any better ideas. It did not hurt that the end customer was not interested in computers.
Then along came the personal computer, and the dot-com boom. Suddenly, everyone had personal computers at home and was on the Internet. Buying things! Computers continued to become more reliable and powerful as well. Companies realized that their back-office IT organizations were not able to move fast enough to keep up with the new e-commerce challenge, and in many cases organized their Internet team outside of the CIO’s control (which sometimes made the traditional IT organization very unhappy). Silicon Valley startups, such as Google and Facebook, in general did not even have a separate “CIO” organization, because for them (and this is a critical point) the digital systems were the product. Going to market against tough competitors (AltaVista™ and Yahoo® against Google, Friendster™ and MySpace™ against Facebook) was not a question of maximizing efficiency. It was about product innovation and effectiveness and taking appropriate risks in the quest for these rapidly growing new markets.
Let us go back to our example of the traditional CIO organization. A typical structure under the CIO might look as shown in Classic IT Organization.
(We had some related discussion in 2-context:06_operations-basics.adoc#tbl-i-o-matrix. Such a structure was perceived to be “efficient” because all the server engineers would be in one organization, while all the Java developers would be in another, and their utilization could be managed for efficiency. Overall, having all the “IT” people together was also considered efficient, and the general idea was that “the business” (sales, marketing, operations, and back-office functions like finance and human resources) would define their “requirements” and the IT organization would deliver systems in response. It was believed that organizing into “centers of excellence” (sometimes called organizing by function) would make the practices of each center more and more effective, and therefore more valuable to the organization as a whole. However, the new digital organizations perceived that there was too much friction between the different functions on the organization chart. Skepticism also started to emerge that “centers of excellence” were living up to their promise. Instead, what was too often seen was the emergence of an “us versus them” mentality, as developers argued with the server and network engineers.
One of the first companies to try a completely different approach was Intuit. As Intuit started selling its products increasingly as services, it re-organized and assigned individual infrastructure contributors (e.g., storage engineers and DBAs) to the product teams with which they worked [Abbott & Fisher 2015].
This model is also called the “Spotify model”; see New IT Organization. The dotted line boxes (Developers, Quality Assurance, and Engineering) are no longer dedicated “centers of excellence” with executives leading them. Instead, they are lighter-weight “communities of interest” or “communities of practice” organized into chapters and guilds [Smite 2020]. The cross-functional product teams are the primary way work is organized and understood, and the chapters, while still the basis of line reporting, play a supporting role. Henrik Kniberg and Anders Ivarsson provided one of the first descriptions of how Spotify organizes along product lines [Kniberg & Ivarsson 2012]. (Attentive readers will ask: “What happened to the PMO? And what about security?”. There are various answers to these questions, which we will continue to explore in Context III.)
One important note: human resources management lines of authority in this model is still generally by functional center, not product line. This is the case at Spotify. However, the overall power structure shifts in favor of product focus decisively.
The consequences of this transition in organizational style are still being felt and debated. Sriram Narayan is in general an advocate of product organization. However, in his book Agile Organization Design, [Narayam 2015] he points out that “IT work is labor-intensive and highly specialized” and, therefore, managing IT talent is a particular organizational capability it may not make sense to distribute. Furthermore, he observes that IT work is performed on medium to long time scales, and “IT culture” differs from “business culture”, concluding that “although a merger of business and IT is desirable, for the vast majority of big organizations it is not going to happen anytime soon”.
Conversely, Abbott and Fisher in The Art of Scalability [Abbott & Fisher 2015] argue that: “The difference in mindset, organization, metrics, and approach between the IT and product models is vast. Corporate technology governance tends to significantly slow time-to-market for critical projects … IT mindsets are great for internal technology development, but disastrous for external product development”. However, it is possible that Abbott and Fisher are overlooking the decline of traditional IT. Hybrid models exist, with “product” teams reporting up under “business” executives, and the CIO still controlling the delivery staff who may be co-located with those teams. We will discuss the alternative models in more detail below.
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]:
How easily can I add or remove people to/from this organization, and do I need to add them in groups, or can I add individual people?
Does the organizational structure help or hinder the development of metrics that will help measure productivity?
Does the organizational structure allow teams to own goals and feel empowered and capable of meeting them?
Which types of conflict will arise, and will that conflict help or hinder the mission of the organization?
How does this organizational structure help or hinder innovation within my company?
Does this organizational structure help or hinder the time-to-market for my products?
How does this organizational structure increase or decrease the cost per unit of value created?
Does work flow easily through the organization, or is it easily contained within a portion of the organization?
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:
Product versus function
Value stream versus activity
Process versus silo
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.
|Even in this simplest model, feedback is important. Much of the evolution of 20th century manufacturing has been in challenging this naive, open-loop model. (Remember our brief discussion of open-loop?) The original, open-loop waterfall model of IT systems implementation (see Waterfall) was arguably based on just such a naive concept.|
(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.
There are two primary disadvantages to the model of projects flowing in a waterfall sequence across functional areas:
It discourages closed-loop feedback
There is transactional friction at each hand-off
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.
|The following discussion and accompanying set of diagrams is derived from Preston Smith and Don Reinertsen’s thought regarding this problem in Developing Products in Half the Time [Smith & Reinertsen 1997] and Managing the Design Factory [Reinertsen 1997]. Similar discussions are found in the Guide to the Project Management Body of Knowledge [PMBOK 2013] and Abbott and Fisher’s The Art of Scalability [Abbott & Fisher 2015].|
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:
Re-invent the wheel, developing new solutions to old and well-understood problems
Bring in new components on a whim (regardless of whether they are truly necessary) adding to sourcing and long-term support complexity
Ignore safety and security standards, resulting in risk and expensive retrofits
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:
Split it across teams
Turn it into an internal product
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:
An application team would identify a need for computing capacity (“we need four servers”)
The infrastructure engineers would get involved and provide recommendations on make, model, and capacity
Physical servers would be acquired, perhaps after some debate and further approval cycles
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.
Organization design influences, but does not completely determine, organizational results.