- 5.1 Framing the Problem
- 5.2 Activity-oriented Teams
- 5.3 Shared Services
- 5.4 Cross-functional Teams
- 5.5 Cross-functionality in Other Domains
- 5.6 Migrating to Cross-functional Teams
- 5.7 Communities of Practice
- 5.8 Maintenance Teams
- 5.9 Outsourcing
- 5.10 The Matrix: Solve It or Dissolve It
- 5.11 Summary of Insights
- 5.12 Summary of Actions
This chapter is from the book
This chapter is from the book
This chapter is from the book
5.10 The Matrix: Solve It or Dissolve It
- Half the world is so used to matrix management as to take the scheme for granted. The other half just thinks it’s bizarre.
- —Tom DeMarco in Slack,23 p. 15
A matrix structure is one whose members have two bosses—typically a project manager for day-to-day work and a longer-term function lead for performance appraisals and training. In case of IT-B, the project managers work with product owners who either come from the business or liaise with people from the business. Function leads in IT-B have titles like head/VP/director of architecture, development, UX, database, testing, or release management. Function leads own “resources” (e.g., developers, testers) who get assigned to projects as needed. Given that IT is itself a “function,” an IT-matrix represents a functional organization within a functional organization—a near guarantee of pain. From business’s point of view, they are the verticals (lines of business) in the matrix and the different IT functions are horizontals. From IT-B’s point of view, the functions are verticals and the different projects are horizontals. As shown in Figure 5-7, we use the latter frame for our discussion. The verticals in an IT-B matrix are activity oriented whereas the horizontals (projects) are outcome oriented. As work moves through the software delivery value stream, it is handed over from one vertical to the other in the IT-B matrix. As explained in Section 5.2.1, these handoffs present a structural impediment for short cycle times.
)
Figure 5-7 Typical IT-B matrix
Matrix structures are probably okay where the verticals don’t have to engage with each other in a fast-moving value stream; for example, a sales organization may be set up as a matrix with verticals for different product lines and horizontals for different regions. However, a matrix is inappropriate for an IT-B organization that aims for continuous delivery. Continuous delivery requires continuous collaboration—a lot of it unscripted. It is something with which the verticals in a matrix simply can’t cope.
While no matrix structure is suitable for continuous delivery, some are worse than others. In the following section, we’ll explore different types of matrices and contrast them with cross-functional teams.
A handoff between two verticals in a matrix can be represented as a queue; for example, development does its work and puts it in the queue of the testing team. A vertical may have a single queue for all incoming work or one queue per project. In the latter case, specific people may be assigned to handle a given project’s queue or it might just be a capacity allocation without fixed people assignment. The relative merits of various configurations are illustrated in Figure 5-8 and discussed below. Modern business by necessity trades cost-efficiency for responsiveness because business agility is a critical success factor.
)
Figure 5-8 Performance characteristics of various team designs
5.10.1 Matrix of Shared Services
A matrix of shared services allocates both capacity and people just in time i.e. all projects share a single queue for a given function. There is no certainty of available capacity for projects. Wait times are indefinite but resource utilization is maximal. This is the worst possible matrix configuration for continuous delivery.
5.10.2 Matrix with Dedicated Capacity and Fungible People
In this case, every project gets its own queue and a certain number of full-time equivalents (FTEs) to service the queue, but the actual people who make up the FTEs aren’t fixed. Although this makes for flexible work assignment, there is drastic loss of context as people switch tasks.
5.10.3 Matrix with Dedicated Capacity and People
Here, we assign a fixed set of people to a product for an agreed-upon period of time. Product owners still have a tough time getting their work done through the different layers from left to right. Occasional power struggles break out between outcome owners and function leads. It is still bad in the sense that there are too many handoffs. There is a tendency for batch size to go up. It does not encourage continuous collaboration, and hence, we see a lot of meetings taking place.
In my experience, a matrix organization can achieve monthly releases at best. But release interval is not the same as cycle time. Monthly releases imply a minimum cycle time of a month, very likely much higher; for example, it might take six months for a new feature to move through all the verticals of a matrix before it is released.
5.10.4 Monolithic Cross-functional Product Team
Figure 5-9 shows self-sufficient cross-functional product teams. The product team is fully accountable for the success of the product. It is almost like a different business unit except that they still depend on external shared verticals such as finance, admin, legal, and HR. Each product team has one person in charge as the outcome owner.
)
Figure 5-9 Monolithic cross-functional product teams
5.10.5 Cross-functional Setup with Activity-oriented Subteams
A single monolithic team may be unworkable after a certain size. At that point, the outcome owner may choose to assign an additional manager to the largest groups of specialists, for example, a manager for the developers or the inside salespeople.
5.10.6 Cross-functional Setup with Outcome-oriented Subteams
It is better to scale big product teams by creating teams that own suboutcomes rather than activities. Apart from the advantage of responsiveness, this also promotes modular software architecture. Conway’s law24 states that the design of a system is likely to reflect the communication structure of its team. Accordingly, monolithic teams tend toward monolithic architectures, layered teams (separate teams for front end, business logic, persistence, etc.) tend toward layered architectures, and teams that own different product modules will tend toward a modular architecture. The ThoughtWorks Technology Radar called it the “Inverse Conway Maneuver.”25