In the previous post I talked about the connection between the organizational structure and culture, with a view from the DevOps transformation perspective. This article will focus on designing the organizational structure and triggering the change.

Table of Contents

Planning the structure

Considering the target - an organization focused on the Customer, the following questions have to be answered:

What is our Product?

Depending on the organization’s size and profile, the answer might be anything from a single Product (for example: “Savings Accounts”) to a multitude of different Products, loosely coupled together (for example: “Telephony, Hosting and Advertising”).

What is the smallest self-supporting unit or team?

Historically, we have put together different components of the Product in functional teams. For example, all QA Engineers in one organizational unit, since they all do QA. But these teams are not self-supporting. They are, per definition, reactive teams (Development reacts to a Feature/Change Request, QA reacts to a new version of the Product, etc.).

As it’s the case with a factory assembly line, you actually want to concentrate on creating and delivering the Product. In a BMW factory, for example, you don’t have a highly specialized workbench, that assembles all the doors from all the car models. If you did, the following problems would arise:

• Shifting blame: “Sorry boss, it was because we didn’t receive the doors on time that we ended up 20% over budget.”
• Them vs. us: “These guys from Door Assembly didn’t put in the correct hinges again. That’s why we can’t continue.”
• Lack of understanding: “Why do we need to wait for so long for the freaking doors to be delivered? It’s only a door. How hard can it be?”

The same applies to IT organizations as well - maybe especially so, since visualizing the whole end-to-end pipeline is impossible without proper monitoring.

Every Product can normally be split into components, that are actually smaller products on their own. A company selling telecommunication services actually has multiple smaller products in their portfolio, some visible to the Customer, some not so much. If you only look at a simple Prepaid (Pay-as-you-go) Calling Card, you need a long list of things, from interconnections to other telecommunications companies, to setting up an AAA system. Each of these required things are smaller Products and should be treated as such.

Are there any cross-functional Products supporting our main Product?

Unless you work in a company where all the cross-functional products and services are external, the answer to this question is “yes”. Identifying these Products is mandatory, in order to find the smallest self-supporting units.

Are there any processes or activities, that have to be applied across multiple units?

When thinking about architecture or security for example, it makes sense to have the means to align multiple units. Establishing groups of interest across the organization, where people with similar focus from all the different units can come together in a coordinated way helps not only for the specific topic, but also in exchanging information about the way each unit works. This is the way the organizational structure can support communication, collaboration, trust and transparency between the different teams.

Identifying all these processes and grouping them by functions is very important. Depending on the size of the organization, one could create such a group of interest for Service Management or different groups for Incident Management, Problem Management, Change Management and so on. If the organization sees security as a very important part of quality, then a group for Quality Assurance makes sense. If not, then we need two groups: Security and QA (for more about this you can also take a look at Tanya Janca: Security bugs are fundamentally different than quality bugs).

Breaking existing tendencies

When organizing the company for DevOps it’s important to have the two dimensions in mind: Product and cross-functional Products and processes. There is a strong tendency to group based on the latter, while the former is either ignored or only present ad-hoc, when projects appear.

The problem with this approach is the concept of Team. There cannot be a real Team when people are grouped together for three months to work on a project. The moment that the team manages to come out of the Storming phase, the team members are assigned to different teams.

More so than in agile software development teams, a team embracing DevOps needs to be stable and adopt an open approach to communication. The person leading the team has to be focused on bringing the people together.