DevOps 2.0: Types of Teams

The four types of teams are based on my experience over 15 years in the consulting world, where I have seen many good things and many bad things; we are not here to judge, but to help by showing other realities and other ways of doing things. 

 

There are those who would tell me that in their organization, it is the only way to work, that there is no possibility of changes, that it would be very disruptive or even impossible, but  just as we saw in the previous post, everything depends on good and strategic planning. Nobody wants the Big Bang. Over the years I have learned how bad and harmful these can be for an organization. Everything that is well planned, that has a clear action plan, and that has a long-term vision can be achieved.

 

From my years of experience I have been able to identify four types of teams in the world of DevOps:

 

1. The Rat Race
2. The Bottleneck
3. The Divide and Conquer
4. The Enablers

 

Let's see what these teams are about., 

The Rat Race

Referring to Kiyosaki's famous book, The Rat Race is a team that is so absorbed in their day-to-day tasks that it is impossible for them to escape from it. For team members this becomes in most cases a purely operational and even, I would dare to say, monotonous job.

 

These teams are focused on resolving tickets all day until they are closed. Some more advanced teams have global-level ticket support, making 24/7 support possible without physically and mentally exhausting their engineers. Others rely on rotating shifts, causing a loss of balance between work and personal life. 

 

In both cases, one thing I am 100% sure of is that these teams apply very little of DevOps methodologies. In most cases, their objective is attached to how many tickets they resolve rather than the quality of the solution, resulting in much of their work being manual tasks rather than automated ones. And sometimes, only sometimes, they have an external automation team that helps them automate some of their processes. 

 

But here comes the big question, these automation teams also have other objectives within the organization, causing the operators' work to have very low priority, and the communication flow between teams is one of friction and not of solution. Why friction, you may ask? Friction is generated for two reasons:

 

1. The lack of attention and priority given to these teams is often communicated in a way that is not politically correct, sometimes even showing annoyance from the automation teams about operational tasks, which creates a negative cultural impact between both parties.
2. Both believe that their jobs are crucial to the organization, but neither considers what is crucial is for them to coexist harmoniously and under a quality standard that can take them together to the next level.

 

In this way, those in "The Rat Race" mostly show a hint of demotivation and a lack of appreciation in their work lives, and often a high turnover of resources.

The Bottleneck

This is one of my favorite teams, not because they are good or bad, but because they are the most entertaining to work with and help improve. In these teams, everything goes through the manager or team leader. The leader is the only one who has constant interaction with developers and managers of other teams to understand the organization's pain points. In their daily calls, if they have them, the leader conveys to the team the vision and what they should work on and explains the reasons for the work to be done.

 

The problem with these teams? Scaling is impossible, and internal team growth is almost non-existent. These teams tend to have higher motivation than "The Rat Race," and they are usually composed of mid-level engineers and occasionally a senior one. But the main problem is that the only one who understands all aspects of the system is the team leader. Additionally, the leader often conceives technical solutions or makes decisions without consulting their team, who, based on their experience, could suggest alternatives or more effective solutions.

 

While their entire team is not in constant interaction with the development teams as we will see later with "The Enablers," the leader or manager mostly understands the functioning of the methodology and knows how to explain it. But because the leaders are a bottleneck for the team, the speed and quality of the team are greatly affected. Furthermore, this leader or manager rarely has time to dedicate to their team, as they are involved in every aspect and meeting about product development.

The Divide and Conquer

If there's one thing every good leader must learn, it's how to divide and conquer. In many organizations where the budget for DevOps areas is very low and the development teams multiply year by year, these teams tend to shine for their ability to do a lot with very little. 

 

They tend to be teams of four or five senior engineers, and each of them supports one or more internal development teams. Unlike "The Bottleneck," product knowledge is divided by engineer and team. Engineers usually participate individually in the daily calls of the team they are supposed to support, and in some cases, they have meetings with the entire DevOps team to update the rest of the engineers on what they are working on.

 

While these teams already apply DevOps methodologies in a more effective and professional way, I often detect several complications with this model:

 

1. The Bottleneck 2.0: They tend to become an improved version of "The Bottleneck," since a single engineer provides support to one or more teams. If this person goes on vacation or is sick, they often become a blocker for the development team. And if this person resigns, an engineer who is providing support to other teams often takes on this work, resulting in a burden for that engineer.

 

2. Trust: Development teams, especially when they have been working alongside a single engineer for a long time, tend to trust exclusively in the engineer they have on their team. The speed and performance of the team are greatly affected when this engineer is rotated, either due to a growth opportunity or an abrupt departure.

 

3. Limitation of Proposals: You often see a limitation on the part of the engineer to offer new solutions or tools that can improve speed, quality, or workflow. Although they are responsible for supporting a team, the proposal of new solutions does not depend entirely on them but on the organization itself, as the premise of these teams is usually simplification so that all development teams operate in the same way, under the same standards and technologies. This isn't necessarily bad, but we will see a better option with "The Enablers").

 

4. Limited Time: What I usually see in these teams is that a single engineer tends to support two or even three development teams at the same time. This means that the engineer's time to carry out the tasks in each team is quite limited, affecting not only quality and speed, but also affecting resources.

 

In conclusion, these teams are effective and apply a good DevOps methodology, but they are limited by their scalability, thus affecting productivity.

 

The Enablers

Without a doubt, this is the type of team that every organization would like to have. These teams are self-managed, effective, focused on quality and speed, with a single objective in mind: "How to make the lives of developers simpler." 

 

Unlike "The Divide and Conquer," these teams are not distributed individually, but are distributed in the form of pods. Each team or set of teams has a DevOps pod, composed of a leader and their engineers. They have their own daily call where they analyze their work and priorities for the day, and they hold planning meetings to visualize future work. 

 

They usually have clear goals for each quarter, where their main objective is always to think about "What can we do to improve." Their objectives are mostly business-oriented and not technical. Collaboration and teamwork with developers and quality teams are key. 

 

They also have weekly meetings with development and product leaders to understand the current situation and pain points and treat their internal teams as their customers, understanding that their role within the organization is to be facilitators of solutions.

 

These DevOps pods are usually led in turn by a manager, and one or several DevOps architects often help these pods define the least critical path and achieve success.

Conclusion

The four types of DevOps teams described – "The Rat Race," "The Bottleneck," "The Divide and Conquer," and "The Enablers" – reveal the diverse challenges and opportunities faced in the world of DevOps.

 

The Rat Race: Characterized by overwork and an operational focus, teams in this category struggle with motivation and creativity, often due to poor prioritization and lack of strategic planning.

The Bottleneck: Teams dominated by a single leader who acts as the sole decision-maker and point of contact are hampered by scalability issues and a lack of knowledge sharing.

The Divide and Conquer: While this approach enables organizations to support multiple development teams, reliance on individual engineers can lead to bottlenecks and an inability to scale effectively.

The Enablers: Representing the ideal DevOps team structure, "The Enablers" prioritize collaboration, automation, and developer empowerment. They function as pods that work closely with developers and product teams to facilitate quality and speed improvements.

 

 Organizations should aim to evolve their teams toward the "Enabler" model, where DevOps practices emphasize collaboration, flexibility, and strategic vision. This will allow for improved productivity, reduced bottlenecks, and enhanced developer satisfaction.

 Success in DevOps requires well-planned transitions, long-term goals, and a willingness to embrace change without creating organizational disruptions.

 Achieving the right balance between quality and speed is essential. Automation, strategic planning, and effective collaboration can significantly reduce operational burdens while maintaining high standards.

 

In conclusion, the path to DevOps 2.0 requires a mindset shift from operator-driven to enabler-focused teams. By embracing the principles of "The Enablers," organizations can unlock DevOps' full potential, driving innovation and achieving sustainable growth.

 

In the next blog post, we'll explore how DevOps can add as much value to the business as product development. We'll uncover strategies to align DevOps practices with business goals, enabling organizations to maximize their impact in the market. Don't miss it!