Tag: Organization

General

Organizing for Collaboration, Part 2

Posted on by Robert Wlodarczyk

Note: This is Part 2 about organizing for collaboration. Part 1 can be found here.

In the previous post, I focused on some common ways to organize with DevOps folks in mind. A quick recap… commonly organizations will stick with hierarchical approaches, but this creates silos. Some organizations choose to use a hybrid approach, where DevOps engineers are still centralized with the hope that engineers that are in a matrix organization will learn the DevOps ways, but this creates problems around having DevOps engineers feeling part of the software delivery team. A common approach is a full-on matrix organization, where engineers with different skill sets and reporting to different managers work together on software delivery teams, leading to well-balanced teams with a diversity of views, opinions, and approaches.

A Stepping Stone…

How are true matrix organizations and software delivery teams part of the organizational journey? The reasons may be subtle, ultimately boiling down to organizing so that autonomy, accountability, and purpose can flourish. Daniel Pink goes into depth on the subject in his acclaimed book Drive. In brief, he describes that these are the main attributes that motivate us, allowing us to be delighted in what we do and be fully engaged.

Self-contained software delivery teams are, by definition, autonomous. They include engineers with varied experience and specialties allowing these teams to operate as a full-stack team. These teams are empowered to deliver on a single purpose in an end-to-end fashion. Lastly, they are held accountable for delivering on the mission and purpose of the team.

This model has been highlighted extensively by Spotify. The essence that organization are these software delivery teams, which they define as squads. Engineers with the same specialties form chapters, and engineers with an interest in similar topics form guilds. Those concepts allow for knowledge sharing, best practices, and common solutions to be shared between squads. Ultimately, though, the squads are autonomous, accountable, and share a single purpose.

Despite Spotify growing, using this foundation of squads has allowed them to remain nimble. It’s a good example for other organizations to take away key learnings from. Specifically around empowering autonomous teams, focusing them, and holding them accountable for delivery in their area.

Going Further… Laloux Model

Is the matrix organization the “be all, end all” of organizations? No way! There is a continuity of organizational models. In the book by Frederic Laloux, Reinventing Organizations, he outlines what that continuum looks like.

According to the model, there are 5 main categories of organization: red, amber, orange, green, and teal. A red organization is one where power and fear are in control. An orange organization is one where structure, hierarchy, and process reign supreme. An amber organization is a meritocracy with innovation and accountability, typically in a hierarchical structure. Amber is where most companies are today. The last two are where the concepts of autonomy, accountability, and purpose shine. In a green organization, individuals are empowered, there is a shared purpose and values. Lastly, in a teal organization, power is shared and authority is decentralized, leading to autonomous teams that wax and wane as the needs of the organization change.

Teal organizations, in particular, reflect the principles of Agile organizations. These organizations adapt to needs. Employees in these organizations are encouraged to be authentic. These unique characteristics align well with Daniel Pink’s research as well. The whole organization becomes autonomous and self-regulating, where the purpose of the organization resonates with each person in it.

If this topic is of interest to you, I highly encourage you to research it further. I’ve linked several lengthier summaries in the references section, and ultimately I encourage you to read the book itself. The book covers many case studies of different organizations, which is tremendously useful in understanding the journey these organizations have been on and how shifting towards teal has allowed for those organizations to grow.

Achieving the DevOps Dream

The original post in this short series was around achieving the DevOps dream. With a look into matrix organizations, and what other types of organizational models exist, allowing a DevOps culture thrive is achievable. Organizations can shift from creating isolated “DevOps Teams” to integrating DevOps and infrastructure within teams and allowing for shared responsibility of development and operations. This is a step in the right direction. As the organization grows, it will come to realize that teams also do not need to remain static as well. They need to change as the focus of the organization changes. In time, the benefits of building interdisciplinary teams that change over time become the norm.

With these types of organizations comes happier employees that have clear purpose and autonomy, and are held accountable. The organization also ends up delivering customer experiences that delight and are responsive to feedback.

In conclusion… I hope that you enjoyed this series and you’re able to take away some information to add to the organizational conversations within your organizations.

References

Update – 11/25:

Update – 12/6:

General, Software Engineering

Organizing for Collaboration, Part 1

Posted on by Robert Wlodarczyk

In my previous post about the Dream of DevOps, I discussed my vision for how we achieve the true vision of DevOps. Namely how having an inclusive culture around software development where not only developers work in a silo, but rather include disciplines such as software testing, infrastructure, and build/deployment.

What DevOps is not…

Let me first go into what DevOps is not meant to be. It’s not meant to be a separate team. Unfortunately, I see many organizations falling into the trap of saying, “We need a DevOps team.” If the organization read The Phoenix Project or any number of other articles on the topic, they would quickly realize the fallacy of building a “DevOps team”. The whole point is that you want integrated project teams that solve customer problems.

How did we get to thinking we need “DevOps teams”? As eluded to in the prior blog post, I feel that this is because many organizations see this is a new engineering function. Since this new engineering function doesn’t fit within the context of the pre-existing functions (such as frontend or backend engineers), there’s a feeling that this needs to be a separate team, operating alongside other software teams.

Instead of treating DevOps as a new team, an organization needs to come to the understanding that this is a function of a team.

Some organizational styles

While many software engineering organizations may start off with the need for a new “DevOps team”, engineering leaders should begin to see the need to have this function be part of software delivery teams.

How does an organization begin to transform with respect to DevOps? An early way to begin making changes is creating a matrix organization. This is an organization where a software delivery team is comprised of engineers from a variety of different teams managed by multiple managers.

The matrix organization

A good example of this is a team delivering something like a web storefront. This application involves a web frontend for users to interact with, some backend for product listings, shopping cart and checkout, some infrastructure that the store will run on, some build and deployment pipelines, and perhaps even a mobile application. In this fictitious organization, let’s start with the frontend engineers having one manager, backend having another manager, mobile having yet another, and let’s say that the build/deployment and infrastructure are managed by someone else. In a true matrix organization, the project scope would be roughly identified and some seed of folks from each of these teams would begin to work together as a software delivery team. They would wholly understand the needs of the customer and work to build a solution meeting those needs across each of their areas of experience. This software delivery team would likely have a team lead, but ultimately not be managed by any of the managers of the individuals working on the team. This type of organization is shown in figure 1.

Figure 1: An example matrix organization, with project leads denoted in bold.

The hierarchical organization

Contrast this to a classic hierarchical organization where software delivery teams do not exist. Rather projects are defined and are worked on in silos. The backend team may be told that they need to deliver a way to list products and provide a shopping cart and checkout. The frontend team would be told that they can query the backend for a list of products. So on and so forth. In this manner, each team only gets a small glimpse of what they need to deliver without understanding the bigger picture. Designs of one team may be incompatible with the other’s leading to rework later. This type of organization is detailed in figure 2.

Figure 2: An example hierarchical organization where managers are the project leads.

The hybrid organization

A third way to organize is a hybrid of the two styles above. Let’s call it the hybrid matrix organization. In this organization, it generally follows a matrix organization. The key difference is that certain functions — typically “DevOps”, infrastructure, or testing — will remain under a manager with either dotted-line reporting into a project or working with an engineer in a project team that has some interest in taking on those skills. The idea of this is to allow this specialized team to remain intact while providing input into software delivery teams and grow interested engineers on those teams to take on the work the specialized team would have done in the past. Some teams may not see a need for input from this specialized team, in which case there would not by any liaison. Additionally, there may be engineers who do not work with any software delivery team and instead focus on building some shared tooling or have some specialized role that otherwise doesn’t lend itself to working within a software delivery team. This organizational model is outlined in figure 3.

Figure 3: An example of a hybrid organization, with engineers reporting to manager 3 working with liaisons from some software delivery teams.

Contrasting these organizations

Some may say that how we organize doesn’t matter since software eventually gets delivered in either organization. Some software will indeed be delivered in any of these organization styles. However, what will be impacted is how teams interact.

In a hierarchical organization, teams may play the blame game when dependencies between managers aren’t delivered in a timely and high-quality manner. Requests of one team on another for features or addressing defects may be delayed as this requires injecting the requested work into a different schedule that has different delivery priorities. Requests to infrastructure or test teams often come late and these teams are generally not consulted on the software implementation.

In a matrix organization, software delivery teams are empowered to work together on delivering a set of functionality on the same schedule. Feature requests and defects are a normal course of business and prioritized according to the priorities for that software delivery team. There are no requests for infrastructure or test teams as they are fully incorporated into the fold of the software delivery team.

A hybrid organization has some benefits of a matrix organization expect when it comes to that specialized team. If there is a liaison established, the partner in the software delivery team may be keen to take on the work of that specialized team, but they may also be overwhelmed with their normal responsibilities or have been selected without having any interest in being the liaison. This poses a new problem unique to this organization type. In the case where no liaison is established upfront, but the need arises later, similar problems to that of the hierarchical organization emerge. Additionally, there become questions about what other work that a specialized team is delivering.

Of the organizational models presented here, a true matrix organization offers the ability for software delivery teams to deliver software holistically.

What’s next?

While this is relevant to the previous post on the Dream of DevOps, this is the first of two parts on organizing for collaboration. This part focused on three common ways to incorporate DevOps, infrastructure, and test engineers into software delivery teams. The next part will look at some of the foundations of this including diving into organizational research and Agile management practices.

A teaser… what if teams were able to self-organize as the needs of the organization evolved?

1