Organizational challenges for effective Dev*Ops — Organization Structure
This is the third part of the triangle for the success of Dev*Ops that I presented in the 2020 Web Summit roundtable I hosted. You can use the following links to check the first two parts about mindset and technology.
In the DevOps context, the organization structure should enable the mindset and the good usage of technology in the products delivery process.
In the past few years, I have been following Matthew Skelton and Manuel Pais’s work around team topologies. Their work is of great help to tackle the challenges around teams structure in the organization.
They are setting some standards for DevOps team structures, definitions, a common language, and practices that, when correctly applied, can help organizations improve the way their products are built and delivered.
Let me point out what I think we should address to help us define a good structure for our DevOps teams.
Design the organization taking into consideration the architecture you want for your product
Since 1967 we know that organizations design systems that mirror their own communication structure. Melvin E. Conway stated that in what we know as Conway’s Law.
Knowing that the produced software connections mimic the team’s communication structure, we need to look at the wanted architecture to better structure our teams.
The idea here is to apply the so-called Reverse Conway Maneuver. We set the software architecture of the product(s) as the starting point. This is the target architecture we want our teams to build.
Then, we look to the teams we need to build it and how they should interact. The team structure must take into account the following aspects.
- We need cross-functional teams able to control their end-to-end value stream;
- We must avoid dependencies between teams to deliver value;
- Teams with common points must be closer together.
Instead of creating teams for the building blocks of the architecture, the idea is to go against Conways’s Law and define teams that can work on every building block needed for the stream the team is building.
Better said than done, I know. Not starting from scratch means that a usually non-pacific transformation is needed. Even building a structure from scratch, we should expect the need to review it somewhere in time.
But we should not expect to improve delivery when an existing team structure has known dependencies because of their communication needs with different teams. Without changing the teams’ structure, we already know that communication improvements will not happen. And this affects delivery.
Manage the complexity of each team domain to decrease cognitive load
Empirically, we can understand that our capacities as individual human beings are limited. To do a good job, we need to maximize our capacity to process new information, resolve problems and learn.
A great deal of research in neuroscience and psychology has emerged in the last few decades focused on our working memory system and cognitive load.
Working memory is generally viewed as an executive function system responsible for our cognitive processes.
Cognitive load refers to the limited capacity of our working memory system and how we use it to accomplish our tasks.
Simplistically, we can look at our working memory by having 3 types of information:
- The intrinsic load is the part with all the information we know and need to resolve the task. If our context is too complex, the intrinsic load is high and consumes our working memory space.
- The extraneous load has all the information in the team context that is unnecessary or unproductive to do the task. For example, if the team has complex processes and bureaucracy to deal with, the working memory is being filled with this kind of load that we don’t need to address team challenges.
- The germane load is the amount of memory we use to solve the tasks. This is the memory we use to understand and find solutions for our challenges. Less working memory available for germane load removes the ability to solve the tasks in the best way.
We need to simplify the complexity around each team and reduce the unproductive information each one has to deal with. To allow each team to provide the best and innovative solutions, we need to optimize our working memory space with space for the germane load.
Size matters!
Here I’m talking about the size of the group of people we want to be working together in the best way possible.
Dunbar’s number shows us how the number of a group affects the type of connections we have in the group.
We should use that and extrapolate to the groups in our company structure, allowing the type of relations we want to have on each type of organized group.
Yes, size matters, and we should use this knowledge to set the best size of the groups on our structure: teams, departments, divisions, areas, domains, guilds, swarms… whatever you have on your organization structure.
Identify the topology of your teams and their modes of interaction
Team Topologies give us two dimensions to define our teams: four fundamental topologies and the possible interaction modes between teams.
Here are the team topologies we should use to define our teams:
- The stream-aligned teams are the full-stack, cross-functional, product teams. Each of these teams is aligned with a stream of value on the organization. The majority of teams should be of this type.
- Enabling teams are the ones that help the stream-aligned teams to adopt or modify software, as part of a transition or learning period.
- Complicated subsystem teams manage a complex subsystem that the stream-aligned teams can’t handle by themselves. This type of team was formerly known as the component team. Complicated subsystem teams should exist only when needed and by a period of time — until the stream-aligned teams can handle the subsystem by themselves.
- Platform teams are the ones supporting stream-aligned teams on their product delivery.
These are the only topologies we need to define the type of teams we have on our DevOps structure.
In addition to the topology of each team, we should define the modes of interaction that each team has with the others. Here are the main interaction modes we should use:
- Collaboration is the interaction mode of teams working together over a period of time. This applies to teams that need to discover new things like APIs, practices, technologies, etc.
- X-as-a-Service is the interaction we have when one team provides, and the other consumes, something as a Service.
- Facilitation is the mode we use when one team helps and guides another.
These definitions from team topologies should help us identify the teams we have and the teams we need.
These definitions also help to improve communication by providing a clear and simple view of the organization’s connections. With small artifacts, like the “Thinnest Viable Platform” for platform teams or “Team API” for all teams, we create the information to share across the organization and improve visibility and understanding of its structure.
Follow the links to see the relevant information we should have on these artifacts.
Use a platform to reduce the cognitive load from product teams
The platform, nowadays often called Internal Developer Platform (IDP), should enable the stream-aligned teams to focus on the business and value creation.
As mentioned on the mindset part of the triangle for Dev*Ops success, the usage of this internal platform has the following gains to be achieved:
- An internal platform is also a scaling model as it should support all stream-aligned teams of the organization;
- It avoids duplication of work around the use of infrastructure resources;
- It allows all teams to be more focused on their business and user needs.
We should define and use a platform to build the common pieces that enable the product delivery, removing some of the complexity, and the inherent cognitive load from the stream-aligned teams.
This is the so-called platform model and, as stated on the “2020 State of DevOps Report”, when “(…) done right, it simply works, resulting in faster, more efficient delivery of high-quality software that meets an organization’s business needs — and at scale. One platform to help product teams”.
In 2021, in the same report is stated that “highly evolved firms make heavier use of internal platforms for their engineers, enabling developers to access authentication (62 percent), container orchestration (60 percent), and service-to-service authentication (53 percent), tracing and observability (49 percent), and logging request (47 percent) services via self-service.”.
Additionally, “it enables stream-aligned team members to focus on the things most important for their customers and get common building blocks and tools from the platform. Its purpose is to ensure delivery is smoother and faster.”
The platform should provide the technical services and enable the organization developers to use them for the needed infrastructure and tools to build and maintain the products they develop.
In this sense, the platform should be developed as a product, an internal one, with the developers as the platform customers, giving feedback for continuous improvement.
The internal platform should be developed by a platform engineering team. To define the structure of this team we should follow the organizational structure concerns mentioned above.
As we are aiming for the best way to help the delivery process, the platform should, as much as possible, provide self-service solutions to the stream-aligned teams, optimizing all needed integration. As a vision, we can aim here to a NoOps concept, providing the delivery environment fully automated and abstracted from the underlying infrastructure.
Wrapping it up, we have the triangle formed by Technology, Mindset, and Organization Structure as the base to apply good practices, patterns, frameworks, principles, values, architecture, processes… all that we can do to improve our products and the way we deliver them.
For sure, we need a good base to be able to work in the best way possible.
Should also keep in mind that nobody can do it alone and it’s nothing one can order. It’s something for which we are all accountable.
We should use this triangle to guide and direct our efforts, create a common language, and aim for the same place.
Following a sailor old saying,
“there’s no good wind for those who don’t know where they’re going”.
