Top 5 Lessons for Every DevOps Leader

One thing about the DevOps route is that it comes with a lot of range. Two organizations may be using a DevOps approach but considerably different in how they apply it. Ultimately, different organizations will succeed or fail at DevOps for different reasons. Naturally, DevOps leaders implementing specific and widespread changes are caught in the middle of this. 

Regardless of your organization’s structure, from a leadership perspective there are a number of boxes you must check if you’re to succeed at DevOps. We are going to look at five of the most prevalent lessons that a leader can draw from executing a DevOps strategy.

For better context, let’s remind ourselves about the importance of good leadership, what makes good leadership difficult in a DevOps setting, and how we can work around the challenges.

When an organization embarks on a software development project, a DevOps leader has to identify and provide numerous tangible and intangible needs to team members. But it’s never as simple as people making wishes that you then fulfill.

Leaders are constrained by a number of factors such as budgets, intra-team relationships, aggressive competitors, timelines, bureaucracy, etc.

Leaders must also make sure that they are speaking to the right people to find out what’s needed. Then they have to find a way to translate these needs to the senior business decision-makers to get buy-in. But it doesn’t end there. Where they can’t get everything they want, leaders have to do a good job at prioritizing certain goals and balancing short- and long-term gains. On top of this, they must also ensure that every person involved in a project lines up behind the overall goal and any momentary changes in the near-term.

Fundamentally, DevOps attempts to increase collaboration between the development and operations teams. Some individuals and sets of people become more autonomous and flexible in the way they work. These changes can fully manifest in the form of an Agile mindset, and by extension, SCRUM and SAFe, which can gradually make project leaders irrelevant.

In this case, a leader has to pay more attention to these two teams’ new ways of working. This may include changes in schedules, assimilating new members into digital collaboration environments, adjustments to timelines, and so on. The leader may also need to be more invested in team building and bonding exercises. Basically, leaders have to find the new or leftover gaps where they can still apply themselves.

 

DevOps and Oversight Culture

DevOps turns company culture on its head by reinventing traditional processes. But this may conflict with the oversight culture that is common in large organizations. In pursuit of greater agility and efficiency, DevOps practitioners may want to skip certain steps. Things such as reporting to higher-ups and getting consensus from various stakeholders are changes some deem too minor to bother everyone with them.

But executives tend to think differently, especially when there’s a lot of intellectual property, trade secrets, and other sensitive data involved. Higher-ups want to be in the know every now and then, which can slow things down.

 

Project Leadership

Project leaders have to reimagine their role, say by morphing into product owners or line managers. For instance, as a line manager, one can relay objectives from higher-ups to developers and communicate the developers needs back to the higher decision-makers. Line managers can even do this while occasionally focusing on critical functions with a near-term impact.

This is why it’s important for leaders to keep it simple and necessity-driven. They must learn to continuously focus on internal work that produces value. Leaders should be skeptical about suggestions that are too sophisticated or designed to appease a small group or have an unclear path to success.

For any leader in an organization taking a DevOps approach, here are some key lessons from a professional DevOps leader.

 

Simplify Collaboration

When you first embark on a DevOps journey, you may have a lot of people directly working together who had previously never had to do so. Don’t rush to make it all about the digital transformation tools they need and what processes must change. It pays to immerse yourself in departments like IT operations and put yourself in their shoes. The goal is to understand how they work, what makes them tick, and what slows them down.

You need to get acquainted with the leadership structure in each department and know “who reports to who.” From here, you can pinpoint the fluff in specific processes and redundant procedures and policies that need refining. Furthermore, it’s important to educate members of one team on why they may have to adopt some practices of another team.

You don’t want to end up alienating workers who feel like they are being forced to work in an unfamiliar manner. When people catch a whiff of favoritism, they could push back and slow things down. Endeavor to explain the logic behind making the project progress in a certain order.

By the time collaboration tools are brought in, everyone will know how crucial it is to deliver at a specific point in time. As a DevOps leader, you should also encourage team members to take initiative to learn whatever they can about the relevance of each other’s roles. 

In this, it’s essential that leaders identify all the areas that can benefit from less micromanagement and enable team members to work with minimal supervision in such cases.

And let’s not forget that learning also applies to you as a leader since there will be situations you haven’t anticipated. 

 

Exercise Patience

At the onset of a DevOps transformation, there are a lot of expectations about how DevOps should improve software delivery. And at the same time, there’s plenty of uncertainty about who will have to change their ways for new goals to be achieved.

This means that even when you alter the way people are working, you may not get the rapid iterations you hoped for. Falling short causes people to point fingers. And where it’s hard to find a scapegoat, the leader may be portrayed as the one imposing unnecessary practices and expectations on team members.

In many cases, problems are widespread so it’s important to diagnose the entire picture. Whether it’s clear that one side fell short, it doesn’t hurt to find out whether another side did the same. You have to be patient in how you come up with solutions.

You must also come up with a clear way of tracking the results of any changes made. Failure to do so will make every solution you suggest seem like guesswork. If you and the entire team can come up with a clear system that discerns correlations from causations, results might improve.

Be willing to monitor progress and adjust team goals when the facts indicate that more time or money is needed. Avoid pushing people to overachieve. If the data says you need more people for testing, don’t rush to squeeze more out of fewer people. Figure out the maximum that those available workers can achieve and work to get them more help or extend their deadlines.

 

Be User-centric

For nearly every change you make, you must ask yourself how it ultimately benefits the user. Developers and other technology specialists can be notoriously stubborn about their ideas. They often think more in terms of how to make the coolest, most sophisticated and ingenious product.

They want to flex their coding muscle and apply just about every tool and technique touted as the future. On the other hand, customers just want something that solves the problem. They could care less about the magic on the back-end that gets everything working. The same goes for additional features.

DevOps can bring with it the spirit of reimagining how to solve problems, but its practitioners can easily get carried away. Find ways to always translate the next immediate goal from technical terms into a value creation effort. Help team members to be able to describe what they are working on in terms of how they are trying to help the user.

There are many products on the market that have a roundabout way of doing simple things such as creating new project files. Be sure to work toward simplifying how products are created.

 

Teach More, Command Less

When you set expectations for a particular team member or group, don’t turn them into demands. Start by listing everything you know about how to achieve your objectives. Proceed to list everything that team members know about achieving those objectives too.

From here, you can get a sense of the gap in know-how or requirements. Ascertain the extent to which this gap can be filled by that team member on their own, and where they might need coaching. To do this properly, you’ll need to have occasional face-to-face meetings with the members in question.

You’ll also need to come up with the right questions in order to know where help is needed. Pass on all the help you can and encourage the team members to be proactive in problem-solving. Where possible, bring in other experts to pass on knowledge or enroll team members in external learning events.

 

Cultivate Capacity to Change

Increasing the pace or frequency of certain activities in any organization is challenging. There can be positive results, but they’ll also likely be a few mistakes. People who have to deliver faster than usual can find themselves having to refine or expand their skill set.

This goes for everything from technical skills to soft skills. A good DevOps leader should know when a problem needs you to simply increase your efforts or totally change your approach. For example, some tests may have to be conducted on smaller pieces of code rather than waiting for larger blocks.

This seemingly small change can create new work for both developer and tester. Testing a larger piece of code may come down to determining how well it does a specific action. But once things are broken down into much smaller pieces, evaluation could change.

It could become more important to understand the role of each of these different pieces, the various ways they can be combined, and the compromises made in some pieces for gains in others.

Therefore, a developer and tester may have to interact more so that one understands why things are being built a certain way, and the other understands how that might change the way they gauge the product’s quality. These interactions affect schedules. In all, these are changes that people need to adjust to.

A DevOps leader should do everything in their power to ensure that the relevant people can adapt to change, whether planned or abrupt. Without an agile mindset, you’ll always feel like you’re playing catch-up.

DevOps definitely has a very technical side to it, but you cannot realize the benefits without good leadership. Before all the automation and fancy technology comes into place, mindsets have to be changed, a new culture has to be built, and practices have to be challenged.

Sometimes, things have to get a little bit more radical, with structures being broken and some roles disappearing. This will all need someone who is diplomatic, self-aware, has tremendous foresight, and doesn’t easily back down from a challenge.

Søren Pedersen

Co-founder of Buildingbettersoftware and Agile Leadership Coach