In the thinking environments paper I mentioned, in an earlier lesson, three organizational structures besides the traditional silo approach are explored. In this video, we're going to discuss each of them, keeping the seven characteristics for DevOps minded organizational structures in mind. We'll discuss some examples of where these organizational structures are employed, as well as some benefits and considerations to each. Let's start our discussion with the matrix structure. A matrix structure is when functional areas will have a dotted line, essentially representing informal reporting relationships to product teams. I've seen this model in all three companies I've worked for. Often, it is used when it does not make sense to dedicate a person to a team for the particular skill they have. For example, I've supported teams that had products with Oracle databases and the Oracle DBA team was not big enough to embed or dedicate database administrators to every product team. Instead, they maintained a dotted line relationship and work closely with the teams when needed. This allowed them to continue to optimize for efficiency across the organization. Now, this model can be challenging if multiple products require the same skillset and that skill set is scarce. Often, this can lead to disagreement about priority. In this model, it is important to have a way to reconcile and provide clarity, if competing priorities surface. Without that structure, the team will be left to decide and that can often lead to paralysis or making a decision that is not truly aligned with the organization's objectives. One way to help mitigate this is to move to more of an embedded model. This model keeps the reporting relationships as is and dedicates people from the functional areas to the product teams. To address what I mentioned about not having enough people, I've tried the embedded model, by prioritizing products that needed the embedded people the most. For example, if we were working on a strategic priority requiring wireless network expertise, then we would embed a wireless network engineer in that product team only, not everywhere. Other products dependent on wireless network engineers would remain in the Matrix Model. The second structure is called a Product and Platform Structure. This is sometimes also referred to as a Full-Stack. A product structure has teams dedicated to individual products or product groups. They are supported or enabled by a group that maintains the platform on which they work and often additional groups for tool support, help desk, and end-user services. Their activities are informed by groups dedicated to the voice of the customer and product strategy. Organizations vary on how they define what belongs in the platform organization. I have had experience where the platform team includes Site Reliability Engineering, also commonly known as SRE, deployment pipeline tooling, cloud enablement services, and other tools that help engineers by creating self-service capabilities, so product teams don't need to focus on that. Some organizations also include best-practice creation and sharing in the platform team. Even including coaching for how to adopt new techniques for getting work done. As another example, at Nike, I'm currently in a situation, where I'm leading the platform engineering teams, which include the APIs and data sources, product teams need to enable consumer experiences. Platforms in this definition, includes content management, digital asset management, search, checkout, payment, inventory, login, profile, and consumer data. In my case, we are treating our platforms as products, creating simplified ways for other teams to consume the platforms and APIs. One drawback with the product and platform structure, is that it can be challenging to adapt. If a product starts to become more of a steady-state investment, how do you evolve the team dynamics to support that? If you need to create a new product team, do you mobilize with key people from other product teams? Or do you create the team with all new team members? If you pull people from other product teams, how do you minimize disruption to the product they are currently working on? Here's where the third common structure comes into play. It is an adaptive structure. It's organic and dynamic, adjusting and reconfiguring itself as needed. In its purest form such an organizational structure would be completely flat, to the extent that management remains, say a CIO. The focus would be much less on control and decision-making than more traditional models. Instead, management would focus on vision, culture and people. The product of management in such an organization is learning. Product teams take accountability and responsibility for setting their mission, staying aligned, and delivering value to customers and other stakeholders. This model contains the capability to generate and retire new structures to meet real-time needs from stakeholders as the organization learns. The structure of such an organization is fundamentally different from the prior models. I often talk about speed to mobilization and in this structure, organizations have the best chance to optimize for that as an outcome. In my experience with the other models, when an organization needs to mobilize around a new opportunity or capability or product, often, the time it takes to adapt is lengthy and disruptive. To form a new team, usually creates disruption with the existing product teams and the implications are often not well understood. Of the models considered here, the adaptive structure is the most unusual in the context of modern organizations. Because there are few examples of this model in practice, it is less clear how organizations can transition into the model or what its challenges might be in practice. Conceptually, drawbacks to this model include the risks that without effective governance, teams may sub-optimize the whole. They may make decisions without considering the impact on the other teams and the overall organizational system. Paradoxically, if teams adapt to their environment too quickly, speed and quality can suffer, as teams always remain in the stages of forming, storming, and norming, and never achieve stability. Teams used to clear management authority structures, may not easily make the transition to this model. As companies have adopted DevOps practices, there seems to be a tendency to evolve in a gradual fashion from one approach to the next. Making use of next level structures to stimulate greater maturity and DevOps practices and agility. Conceptually at least, this incremental approach makes sense. Considering DevOps' emphasis on experimentation and continuous improvement. This is not to say that a decision to drive a more dramatic transformation is incorrect in all circumstances. A change in structure such as moving from functional silos straight to a product structure, effectively bypassing a Matrix Model, could in some contexts help achieve a profound alignment to DevOps principles and practices. At the end of the day however, there is no default answer to the question, "What model is best for my organization?" Invariably it depends. I've given you some of the details about these models from the Thinking Environments document. I would encourage you to download it for additional information about the pros and cons, considerations to make including cultural elements. Changing organizational design, shouldn't be taken lightly. It's important to be able to explain why an organizational change, will improve outcomes and flow of value to the customer and often if a transformation starts with an organizational change, it likely won't yield the maximum benefits. It's more important to focus on culture and allow the organization's objectives to be the driver for any organizational adjustments.
