You are here

How to become the ultimate DevOps leader

public://pictures/greg.jpg
Greg Bledsoe, Managing Consultant, Accenture

DevOps is a cultural phenomenon. It can't be forced, but it can be inspired—and led. But because a cultural phenomenon usually arises from a groundswell of internal support, hiring a great DevOps boss can be hard. If you're on the inside, you know how much your development and operations teams would profit from DevOps. That's the reason you want to become that leader who can inspire change. Here's how to get there.

The best person to lead DevOps is someone with not only the business acumen to know what truly matters, but also the ability to negotiate outcomes with groups whose immediate goals vary, keep egos firmly in check, and surf atop the waves of inevitable chaotic entropy that assail such efforts. Most of these skills can be learned and developed in a fairly short period of time. But there is one exception: To become the ultimate DevOps leader, you must have deep technical expertise.

Developing deep technical expertise

There's a time and place for nontechnical managers, such as the CFO, to provide oversight for technical groups. But without a technical manager, or at least a lead engineer who can sit between the technical and nontechnical teams to bridge the gap, communication breakdowns and disengagement of key staff are likely. To truly capture all the available value for the business that your staff represents, you need to become someone with deep technical expertise.

By that I mean you should strive to become the expert's expert—someone to whom other experts go to discuss tricky issues, the person whose insights they trust, sometimes even over their own. The exact type of expertise required varies with each organization, but it should be in an area directly related to your team's function and your particular technology stack.

Research shows that at least 10,000 hours of practice in a given skill are required to become highly proficient and qualify as an expert. This is just a biological reality of how the brain restructures itself as people learn through progressive experience. Eventually, insights become intuitive, and the long-term consequences of decisions you make today become obvious.  

So how does one gain this mystical quality of enlightenment? The most straightforward, brute-force method is to expend the time and effort. If putting in five 2,000-hour years of study gives you baseline expertise, then deep technical expertise requires twice that time. After that full decade of developing skill, debugging problems, and tracking consequence, you will have gained deeper insights and more sophisticated understanding. You will have synthesized and crystallized the principles of success in your field into principles you can verbalize when others may intuitively understand that knowledge but not have the language for it until they hear you say it. This is how cliches and maxims are born. But that might take ten years. 

You probably don't have ten years of full-time effort to put in. Fortunately, there are a few ways you can speed up the process. And in the meantime, you can be still be a DevOps leader while you are on your way to becoming the ultimate DevOps leader.

Two ways to get there faster

If you already have an aptitude that is a couple of standard deviations to the right of the bell curve, you can develop expertise faster. This is a great advantage, but not everyone has such aptitude. If you do, it will help you shortcut some of the mistakes others make before they reach a particular insight. But aptitude can also be a curse: It leads some people to stagnate, rather than advance, as they feel that their marginally higher level of aptitude over their peers is good enough. That tendency, combined with hubris and an unchecked ego, can create a prima donna effect that kills leadership potential.

There is another way to speed up the process that is open to everyone, regardless of aptitude. It's to have the right attitude and develop the habit of awareness. Consciously trying to achieve deep technical expertise is more effective than you might think. By that I mean having that goal in mind as you go about your daily practice.

Expertise develops serendipitously for most and accidentally as we group like problems and solutions together and correlate random events into classes over time. But serendipity and chance don't have to play such a big part, and you can decrease your time on the path if you put yourself in as many situations as possible. Intentionally start trying to put principles behind your intuitions, mentally separate your failures and successes into groups, and find the commonalities and differences between them.

When you are trying to solve the single problem in front of you as efficiently as possible, you necessarily put minimal mental effort into that particular problem so you can move to the next one in a classic linear scalability solution. It's only afterward, in the background and after solving many more problems of the same sort, that you finally classify and correlate it.

To consciously develop expertise, take a minute as you are solving each problem to ask yourself the questions that you will answer intuitively later: Have I solved problems like this before? Can I reuse past solutions here? Can I classify this problem and solution and identify a pattern by which problems like this are most efficiently solved?

Become facile with statistics so you can better evaluate anecdotal evidence and test the overarching ideas you've gained from these practices against the experience of others and your own future experience.

Expertise gets respect

Gaining expertise brings a host of benefits by itself, as getting to this level of understanding trains the brain to think through problems and opportunities at a deeper level and with more thoroughness. This pedagogy alone will help you to think through your DevOps process and how to get from here to there in a more effective way. But the most important reason that the perfect DevOps leader should have deep expertise is more primal: It commands respect.

The quickest way to win the respect of the intelligent is to display intelligence. The quickest way to win the respect of the technical is to show technical acumen. Not only does this immediately open the door to the consideration and acceptance of your ideas, but it also gives those you are trying to influence the sense that you understand them and what they need to do their job. For the engineer, the job, the project, the goal is all. An engineer will devise a way around all obstacles to achieve the goal, even if the obstacle is the boss or the company process and bureaucracy.

On the other hand, because of their respect for you and your ability, the engineers on your teams can come to see you as their most important ally in the war on inefficiency, as a trusted source of wisdom and aid in the quest to get stuff done. They may begin to seek you out as the middleman to explain their plight and secure relief. In order to make the most of this influence and turn it to everyone's benefit, you have to work hard to bring all sides together, particularly with the teams whose respect you have earned.

This requires another trait of the ultimate DevOps leader: the ability to coach and mentor. This comes more naturally to some than to others, but if you can develop deep technical expertise, you can learn these skills as well. This respect is easy to squander, though, if your motives aren't right or your nontechnical skills aren't up to par.

Become the ultimate DevOps leader

Developing deep technical expertise is essential to becoming the ultimate DevOps leader. To get there, follow an agile approach: Get started now, and develop the expertise you need to develop more expertise as you go. That is to say, you must become an expert before you can become the ultimate expert. So put yourself in as wide a variety of situations as you can and think deeply about how to navigate them and what they mean, and you'll be much further down the road toward becoming the ultimate DevOps leader.

What traits do you think are necessary to become the ultimate DevOps leader? I welcome your thoughts and comments.

Topics: DevOps