This blog was originally published on Jun 07, 2016 on the CloudBees blog. here.
This is the eighth blog in the Field Notes from a DevOps Cultural Anthropologist series. It is the first in a two-part blog series on the Ops side of the DevOps house. The first blog focuses on managing an Ops focused DevOps career and the second is an interview with leaders from the Ops-focused G2 Technology Group , a substantial and innovative Boston based DevOps managed services company.
I believe I have had a pretty standard DevOps career. When I go to DevOps conferences, I get the impression that I am one of many Ops-focused DevOps consultants who have followed the same operations focused path that I have. Fell in love with Linux, had an affair with TCP/IP networking, crushed hard on Puppet, have been in a healthy marriage with the Cloud/AWS since it first came out, and now raising two cloud kids, PaaS and Continuous Delivery. These experiences are what make us DevOps engineers, both on our resumes and as people. I have found they are quite different from the experiences of the developer-focused DevOps engineers, who are the majority in the DevOps community.
In my role as a senior DevOps consultant, I am often paired with clients who have way more development experience than I have. My value add is my 19 years of operations experience. My career started as a contractor to the FAA at their Air Traffic Control Management facility. It had a mandate of six 9s (99.9999%) uptime. I worked there for 7 years and learned from literally some of the best operations people you could ever hope to work with. I rely on the training I received there daily. But, there is a schism between the Ops focused DevOps people and the Dev focused. In private conversations with my colleagues, we share that we are both intimidated by each other’s strengths. I for one have struggled with becoming a good programmer. It’s just not in me; it was not part of my training or education. At best, I am a scripter, not a programmer. I excel at systems engineering, networking and creative problem solving. In my darker moments, especially when I am surrounded by software architects, I question if my background and skills are good enough to contribute to the future of DevOps.
It’s unclear. I hope that there will always be a consultative need for ops-heavy DevOps consulting. With that said, there is an undeniable fact that I need to learn a programming language, in order to be a true DevOps engineer. Jenkins makes use of Groovy heavily, and the new Pipeline as Code DSL was written in Groovy. Groovy is very mature and is considered “a reasonable JVM language for DevOps”[1] . It is a simple, dynamically typed language for the JVM. Its syntax and style are similar to that of Ruby. My colleague at CloudBees Victor Farcic says, “For Ops, I would start with Python, it is already installed on almost every Linux distribution and is easy to learn”. He continues, “My advice is to learn Dev so that you can truly become a DevOps”.
This appears to be good advice at first blush. I had, however, a recent conversation with Dr. Bill MacMillan , a political economist who stressed the benefits of job or role specialization in DevOps. He said, that at his company Prattle it is better to have the data scientists focused on data science, and the developers focused on development. He said that focusins on one job frees his team up to coordinate and communicate better. An expectation for employees to be multi-disciplinary means that his staff would be jacks of all trades, but controllers of none…which is exactly not what he wants for his startup. He wants controller technologists with distinct strengths.
Dr. MacMillan continued giving a basketball analogy. He said, you might have a 7-foot giant that can drain 3 pointers, but you are better off having them under the basket catching and putting balls in the basket. Similarly, you might have a great point guard who is great on the outside, but you wouldn’t want to put them under the basket when you have the 7-foot giant who will be able to cover the basket better than anyone else. Specialization of roles allows the whole team to achieve more. Dr. MacMillan is an economist and has studied job specialization or division of labor. “Job specialization is one of the key facets of the modern capitalist economy and offers a range of potential advantages for workers and the companies that employ them”[2] .
Is this true of DevOps? Why do we feel so much pressure to be better at either Dev or Ops? Marcus Buckingham and Donald Clifton’s Now, Discover your Strengths first published in 2001, advocates focusing on building strengths rather than focusing on weaknesses. “The theory behind the book is that each adult individual possesses a certain number of fixed universal personal-character attributes, defined by the authors as ‘talent themes’, which, together, result in an individual’s tendency to develop certain skills more easily and excel in certain fields in a sustainable way while failing or not being able to sustain success or high levels of effectiveness in other fields. The authors claim that by identifying the individual strength of the members of the organization, its members can be utilized in more suiting positions, hence developing the required skills easily, helping to reduce turnover, improve employee morale and the organization’s overall performance”[3] . The central message in Now, Discover your Strengths is very similar to what Dr. MacMillan says about specialization within his team.
Yet the question remains. What is the appropriate balance of skills necessary for a DevOps engineer, or in my case a DevOps consultant? Should I play up to my strengths and work on my consultative skills? Should I play up my systems engineering background and controller HAProxy or Terraform? Or would my DevOps consulting profession be better served learning Python? There is a meme on LinkedIn that I have noticed recently and it extolls the virtues of managing your career as if it were a business . I agree with it. Your career is a business and should be managed like one. If you look at the problem as a business management problem, what are the best business development areas we should all be focusing on? Is it our strengths or our weaknesses?
Stay tuned to the second part in this Ops focused series. We will be interviewing Director of Operations Tom Levins and CEO Glenn Grant of Ops-focused DevOps managed services firm G2 Technology Group , to hear about their take on DevOps as a career and what it’s like to be focused on the Ops side of DevOps.
Thomas McGonagle Senior DevOps Consultant, Global Services CloudBees