What I Do as a DevOps Consultant

Perhaps I was unclear. The reason I scarequoted the term "devops engineer" is that to have such a thing (and we simply must stop abusing the term engineer, we're not) you'd need to find somebody who does absolutely everything in the stack, from technical to business-strategic. Which is why "devops engineer" makes as much sense as "Agile engineer". They're processes for people, they're not computer-touching anythings.

The idea that a "full stack developer" is "hurr, JavaScript" but that devops engineers are somehow different is...questionable. I've shipped mobile apps, web apps, backend APIs, and build and operate computing infrastructure at scale in cloud and on-premises environments, while having also had success at the strategic level with regards to the development of and the pursuit of business requirements and objectives.

Write code to tell computers to do stuff. That's all any of it is. The elaboration of the details is important in the small but not important in the large.

DevOps in my experience often stems from a breakdown of communication/trust between management and developers. Software production and deployment complexity has outpaced the deliverable(s). Traditional IT system admins struggle to keep up with deployments that are way beyond ftp/sync tools. Simultaneously developers are creating microservices each with independent multi-step build processes.

The complexity and problem solving of the job is not automating some widget or service. That is very easy and not a challenge to someone with a deep programming background. The challenge is knowing what to build to a) enable developer productivity and flexibility to b) increase development speed to c) provide products/services the business side can iterate on quickly while d) not completely destroying the infrastructure and lessons learned that already exist and e) providing training and leadership to system admins and developers not used to these processes.

He isn’t pushing human interaction. That is part of the job and problem solving. There was this story going around about what kind of developer you are: cowboy or farmer? Good devops people are plumbers.* Plumbers get stuff working by making sure all the disparate components of the the whole system work together. Human interactions are necessarily part of the whole system.

A solution can be technically fantastic, and yet people may not adopt it for one reason or another. You have to get buy-in from people.

I recently interviewed at a place where they vaguely know they needed devops but there wasn’t sufficient buy-in. I made the mistake of taking the interviews at face value. I should have been treating it as consultation from the get-go, drawing out any issues they might have (by starting with pain points), coming up with solutions. I didn’t realize I can be applying the same skills I have while working to at the very earliest stages.

If I were to build a consultation firm, I would sell organizations on the human interaction (because that is easier for people-managers to grasp; it is what they fo for their jobs). However, if I were hiring someone within my hypothetical consultation firm to do this kind of work, I would look at their problem solving mindset and people skills, at whatever experience level they are at.

*And it seems reading that Small Farmer Journal article about how to get started as a farmer with no money, real farmers have to problem solve too.

Somewhat, but I also think it means there's a less of a boundary between the product development and the product deployment than in the past.

To everyone in this thread: this is an article, not a question to HackerNews.