What is DevOps? An engineering competency? Yes.
This is a short series of three also fairly concise articles exploring what is meant by the emerging and ever popular term “DevOps”.
Previous articles in this series introduced and discussed
In this third and final post we look at DevOps as an engineering competency.
Let’s set the scene first. DevOps as an engineering competency is a very real skillset, heck, I even sometimes call myself a DevOps engineer! I am therefore firmly of the belief that “DevOps engineers” should be strong communicators and constantly strive to improve that communication and collaboration between the classic and often siloed Development and Operations teams as well as the whole business. In addition DevOps engineers should be proponents of DevOps as a culture and a practice, as I’ve discussed on this blog previously, whilst also being suitably technically skilled to work competently amongst all teams as well.
The above said, it is imperative to understand what DevOps engineers are, what they are not and importantly their role within the business, in what I believe are akin to marriage counsellors.
What DevOps engineers are *not*:
- A “guru”, “lone ranger” or god forbid a “hero”, “rock star” or “ninja”. Repeat, the aim is NOT to become a single point of failure or build an ivory tower, rather, impart knowledge and skills, think culture culture culture.
- “The” build or automation engineer. Yes, these are often areas where our passion and strengths are as DevOps engineers, however the value is in getting teams to become cross-functional and owning their full solution stacks, including the build and infrastructure.
- An out-sourced resource or chop-shop for DevOps’y style tasks that teams do not have the knowledge and or desire to complete themselves. Don’t be responsible for adding further barriers to adoption of responsibility by all team members by promoting a DevOps person or team. As Jez Humble puts it There’s no such thing as a “DevOps Team”.
What DevOps engineers are:
- Excellent communicators. Regardless of how strong a communicator you believe you are I encourage you to read the classic and excellent How to win friends and influence people by Dale Carnegie, a truly inspiring and thought provoking read, indeed it influenced this post.
- Effective and efficient. Nothing speaks louder than actually doing, using your time wisely is also imperative.
- All about the detail. As some often say, “the devil is in the detail”, arguably all software engineers should care about the detail, as a DevOps engineer it’s your duty to be passionate about it.
- Pragmatic. A nice quote from a good friend and previous colleague Mike Clayton during a very heated debate around a stressful deployment was “We’re prepared to short-cut the process, but there’s no short-circuiting going to happen!”. This is subtle, endeavour not to be so stubborn that you become short-sighted or single-tracked in your thinking and doing but conversely don’t be walked over. Yes, sometimes a less that acceptable build has to be massaged through to production for political or unavoidable commercial reasons, support your teams when this is required, don’t make it even more painful for them.
- Team players. Where possible align to development sprints or Kanban flow for implementations. Be they process, build or operationally focused those stories should be in a backlog, an important step to getting buy in from the whole company and promoting visible, positive change.
- Business focused. A DevOps engineer worth his or her salt will have the business’ best intentions at the forefront of their mind at all times. They will for example understand why Continuous Delivery (CD) is important to market presence and Return on Investment (RoI) and how Continuous Integration (CI) drives quality and efficiency allowing you to fail early, saving company resources, time and money.
- Technically strong and adept. Ideally you’ll have a mixture of development, operational and even support background, you need to be strong too as you’ll have to prove how things can be achieved technically, often under great critique (at least initially).
- Passionate learners. I‘m in no way individually the strongest network, infrastructure or development engineer and I don’t expect anyone calling themselves a DevOps engineer is. However what we do often share is an ability to communicate at a deep technical level, an intrepid desire to learn and constantly absorb knowledge from peers around their specialist areas. Keep your hand in and when flummoxed know how and where to find the most suitable answers.
There is no coincidence that the majority of bullet points on the ‘What DevOps engineers are’ list are soft skills. Technical ability get’s you a long way, however the ability to communicate and align to business value, whilst imparting that knowledge in a compassionate and non-condescending manor is, in my opinion what will both make a DevOps engineer successful and set them apart as someone people genuinely want to work with.
Are DevOps engineers the marriage counsellors of the business?
So finally, the title of the post. I believe there is a strong analogy between DevOps Engineers and marriage counsellors, hang on, let me explain by example.
Many relationships between teams within business have some friction, the worst are akin to a bad marriage with team members not talking and even directly (sometimes publicly) condemning the other parties, yes development and operations, we’re looking at you.
The marriage counsellor
An experienced and respected marriage counsellor will listen to both parties, they’ll offer some impartial advice based on their experience and what they have learnt from the husband and wife, help find common ground and potentially offer ways and mechanisms to manage disputes, often very communication focused. Ultimately if all goes well the husband and wife may well find a long lost or new found respect for one another. They then have the opportunity to be able to lean on what they have learnt from the marriage counsellor and discovered for themselves during the counselling process to begin progressing positively again with their relationship.
Or given our analogy…The DevOps engineer aka ‘marriage counsellor’
An experienced and respected DevOps engineer will listen to and understand the problems experienced by development and operations teams as well as the business. They’ll then often be in a position to offer some impartial advice based on their previous experiences whilst taking in to account their new found understanding of any business specific challenges. Advice can often be initially focused on finding common ground, whilst giving teams and individuals the ability to reduce the likelihood of disputes by improving the flow of communication. Executed correctly common respect can begin to filter through in the most busted of cultures and individuals passion for their work and the company they work for can really begin to thrive,
Not so different from a bad marriage wouldn’t you say? So, you may be thinking, “but the marriage counsellor doesn’t move in and live with the husband and wife forever more” and you’d be correct. It is for this reason that I often see the “DevOps engineer” as a temporary engagement within organisations, indeed this is what I have done on 3 or 4 occasions personally, aid in instilling that culture and empower existing teams and workers to collaborate and communicate and improve themselves and the business, along the way advise on technologies and help select and build tooling and implement process improvements. Hopefully, if done well your deficit should be easily filled by existing team members, whereby they will have the desire and knowledge to continue to constantly improve.
I believe DevOps engineers aren’t just technically skilled individuals, indeed they’re fundamentally great communicators who work effectively in a team, strive to always add business value and are experienced enough to be pragmatic in stressful situations, they’re also counsellors to those sometimes tempestuous relationships between teams. Fostering a DevOps culture whilst instilling the enablers of DevOps as a practice is the truly scalable way to build your engineering teams, sometimes that will involve needing specific DevOps engineers, sometimes you’ll be so dialled in and the teams so cohesive it will be truly cross-functional in nature.