osorioartist - Fotolia
Every so often, I get asked, what's the most important skill for doing and implementing DevOps?
It's an intriguing question, on par with, "what's the most important skill for a musician?" Or, "what's the most important skill for a doctor?"
For musicians, it's a good idea to have a degree of mastery of an instrument; for doctors, a solid understanding of the science of medicine and the particulars of his or her specialty.
But, are these skills the most important, far beyond any others? Hard to say. It's a Big Question.
When confronted with Big Questions, my habit is to head to the trenches. I was taught a long time ago by a very experienced executive that if you want to learn the true state of a company, go down to shipping and receiving and talk to the employees on the loading docks. They'll tell it like it is.
The same can be said of DevOps: Talk to the people who do it day in and day out. Hence, I talked to four people very much in the know. These are people for whom practicing and implementing DevOps is a way of life. They drank the Kool-Aid a long time ago.
The responses I received reveal a surprisingly consistent pattern.
Ajit Zadgaonkar, executive director of infrastructure and engineering operations, Edmunds.com Inc.:
Learning skills [is] critical. Those who are willing to learn, learn everything -- technology, behavior, attitude. A serious DevOps is a cult. My frustration is that it's being treated with immaturity in an industry where people link it to technical skills, like programming language, tools, etc. I agree those are important, but at the core of it, one needs to have a desire to get to the root cause, conviction to confront the problem at hand and passion for finding a better way of doing things -- debugging, automation, deployment, coding and process, as well as human-human, human-machine and machine-machine communication.
John Martin, senior manager of technology operations, DWA NOVA:
Empathy. The most important skill for anyone practicing DevOps to have is empathy. We often aren't building things for ourselves; we're building for others. We must be able to understand others' needs in order to build what is asked of us.
I remain one of those folks who believe strongly that DevOps is less about technologies and more a matter of how we work together. Communication [and] collaboration -- each [is] made more effective by remaining empathetic to those we are working with or delivering a product to.
Matt Heusser, nationally known DevOps consultant, Excelon Development:
First, the ability to work with people with different motivations. Second, to learn new frameworks, languages, patterns of working, etc., quickly.
Sheng-te Yang, senior director of engineering, U.S. Auto Parts Network Inc.:
When I am recruiting for DevOps candidates, I don't look for years of experience in any one skill. Rather, I look for individuals who have demonstrated the ability to navigate the unknown and a hunger for knowledge.
See a pattern? These people are not talking about being a master of continuous integration/continuous delivery (CI/CD) or a ninja in all things Amazon Web Services (AWS). In fact, none of the quotes above reference a particular technology. The thread that runs across these quotes is a commitment to cooperation and continuous learning.
Seems like a no-brainer, huh? Well, yes and no.
Commitment to cooperation
Many large companies silo their personnel, not so much out of nefarious volition, but rather just due to the need to organize and manage large numbers of people efficiently. Quality assurance does QA work, and the legal department does legal work. The sales department, shockingly, does sales work.
Specialization is efficient. That's the way things are in work and in life. You tend to hang out with people who have similar interests. Due to common experience, there is less friction in the interactions. But things change when dealing with corporate IT, because it touches everything: infrastructure, customers, employees, accounting… everything.
Thus, as the DevOps sensibility dictates, effective operation is about cooperation. You need to really work together beyond the silo. Yet, in many instances, cooperation beyond the silo is a difficult undertaking in a commercial structure that is, for the most part, encapsulated, hierarchical and command-based. Still, cooperation must happen and the challenge to implement a cooperative environment must be met to have a DevOps enterprise.
Commitment to continuous learning
Let me be frank, continuous learning is exhausting. Most technology is hard to understand and harder to master. That's the price you pay for the benefit of staying a step ahead. Think about it. Do you think people got the cotton gin right off the bat? No way. The device needed to be understood and mastered in order for the operator to become productive. Learning needed to take place. Over time, as the device became more commonplace on the commercial landscape, the learning curve associated with the device diminished and productivity increased. Then, the cotton gin was a profitable technology for decades. That's the good news. The bad news is that, today, a decade is an eternity in the lifespan of a technology.
How many of you today are working with the same technology you used 10 years ago? I'm not. Today, most of coding is in Node. Ten years ago, I did a lot of Java and .NET. Also, I practically spent no time working in a cloud environment. Today, it's all cloud all the time.
Carve your IT career path
Learn more about IT jobs, and the skills required to advance your career.
The learning curve I had to satisfy to get acceptably competent at AWS, Azure and Google Compute Engine was and is intense and exhausting. I still spend a good one to two hours a day keeping up on stuff, scouting the technical landscape for technologies that'll be important and will need to be mastered. The musical analogy is that it's like having to learn a new instrument every year along with learning a new form of music to play with that instrument.
And, yet, we continue to do the work of continual learning. Why? Commitment. Our sense of commitment to our vocaftion demands it.
The most important skills for practicing and implementing DevOps
Here's what I think is the most important skill for a person implementing DevOps to have: The ability to make a commitment to a professional life of continuous, intense and relentless learning about others and about technology.
You'll have to learn on a continuing basis how to cooperate with other people, familiar and new, from different walks of professional life. You have to learn how they think, what they value, their strengths, their shortcomings, their motivations and why they come to work each day. You have to learn how to speak their language and teach them yours.
It'll never end. People change. Work groups change. When IT was small and affected only a few, cooperation didn't matter that much. Now it's big and affects all. Cooperation is all there is.
And then there's the technology. The same rule applies. Technology will always be changing and you'll always be learning as long as you can maintain the commitment. It's exhausting doing all that reading, watching all those videos and doing the hands-on tutorials. I get tired just thinking about it. But that's what commitment is about. It's a pledge to walk the talk, to pay the price, to stay competent in a world in which the rate of change is continually increasing.
Thus, you'll have to learn to pace yourself. You'll need to learn when to commit to a new technology and incur the learning curve that goes with that commitment. Also, you'll have to learn when and where to pass. We need to be judicious when making a commitment.
I am a big fan of the DevOps sensibility. I became a firm disciple when I came to really understand the consequences of infrastructure as code, test-driven development and automated CI/CD. Also, I really have come to understand the implicit paradox in play. In the modern enterprise, no one person can know everything and, yet, the elusive goal for those implementing DevOps is to know everything.
Success seems unachievable, and it very well might be. The paradox will prevail in the absence of commitment. But, when each person in the enterprise has the ability to commit to a professional life of cooperation and continuous learning, we can go a long way toward resolving the paradox and make for a healthier, happier professional life, and maybe even a personal one, too.