Is DevOps the Wrong Name?
The invisible, yet critical, work of engineering teams needs its own name
I have to admit I was late to the world of DevOps. Having been in startups for several years, the idea of shipping code fast was simply how things got done. There were no approval processes, fixed deployment schedules, or hundreds of steps to release code. As soon as code was checked in, it was ready to deploy, usually without any human intervention at all.
Then I got to experience how big companies get things done. During my time at Stack Overflow, I would meet with many leaders of engineering organizations in larger enterprises. It was an eye opening experience as I toured the engineering departments. Antiquated and underpowered PCs. uninspired cubicle farms, disconnected tools that required many manual steps, endless meetings, and other roadblocks in getting things done. It could be weeks or even months before code would be deployed to production.
One of these big companies was trying to change how their engineering teams did things. They brought in a well-known leader who had helped transform the engineering organization for a larger retailer. When we finally had a chance to talk, he said to meet him at DevOpsDays. I had no idea what that was, but I figured I would sign up since it was local and I needed to meet him if I was to make any progress in having this big customer come on board as a customer.
The day I attended DevOpsDays NYC led to two significant outcomes. First, the big company signed up as a customer. The bigger news however was that I finally understood this thing that I kept hearing about called DevOps.
What is DevOps? There are so many explanations and it is dizzying trying to corral and understand all the variations of the term. Most agree though that it involves developers and operations teams working together more effectively for the purpose of shipping code faster. There are a few important things however worth expanding on:
Developers and operations are separate teams where developers write the code and operations puts the code in production.
Working together more effectively can mean anything from processes to tools to culture that enable better communications and collaboration.
When you ship code faster, you deliver value to customers faster, gather feedback and iterate faster, and ensure more satisfied customers.
That is a huge swath of stuff however entailed in bringing DevOps into an organization. It feels messy and complicated. You have to get two teams on the same page, which threatens some people and creates political tension. A lot of “not in my backyard” objections get raised. Then eventually just to get something going, a compromise is made and the extent of the change is limited to a few tools for things like CI, or continuous integration. They might even go for CD, or continuous delivery, tooling to stage code changes to production systems, or go the full way and do continuous deployment to automate pushing those changes live into production.
DevOps as an idea got its start from the rumblings of the Agile movement. The concept did not really take shape until 2009 when John Allspaw and Paul Hammond gave a talk at Velocity called “10+ Deploys a Day: Dev and Ops Cooperation at Flickr.”. One of those watching the talk, Patrick Debois, was so inspired that he launched the first conference around this idea of ops and developer teams collaborating together. That event was called DevOps Days.
Over a decade later, DevOps is an embedded concept in most companies. It is so well adopted that there are numerous DevOps oriented conferences, books, podcasts, major motion pictures, and you can even get certifications in DevOps. I am joking about the movies, but the key point is no one asks whether DevOps makes sense.
There is one question that no one is asking however. Why did we stop at DevOps?
What I mean is that the key point of DevOps was getting operations / system administrators and developers to collaborate better. While the processes, tools, and culture all encompass aspects of DevOps, the bulk of what DevOps entails is the organizational alignment of two historically siloed teams. Everything in the spirit of DevOps is to bridge the vast divide between these two groups. Thus DevOps as a name is the catenation of developers and operations derived from the Allspaw/Hammond talk.
Where does this leave the actual operations of a developer organization then? This would encompass all the activities that ensure developers can do the job of writing and delivering code. That means recruiting talent, onboarding and training staff, implementing and managing tools, and fostering the culture of engineering itself. What is the name we give to that?
Perhaps we can look at different domains for some guidance. In the sales world, there is sales or revenue operations, which does all the underlying functions to support sales teams like managing CRM and data, handling financing, building reports, etc. In the finance world, there has evolved a concept called FinOps to provide financial rigor to cloud costs. The human resources industry has HR operations which handles administrative services, recruitment, job analysis, and employee relationship management.
The problem with applying the word operations to developer teams is that the word has already been co-opted by DevOps! Could you say “developer operations”? Sure, but we would all condense that down to DevOps and cause confusion. Could “engineering operations” work? Again, that is a term that has already been co-opted by the construction industry. What then can we call the field of activities and practices that support engineering teams?
That term is called Developer Enablement. No one is calling this internal “glue work” of developer teams by this definition yet. Mostly it is because there is a lack of recognition of the problem space. CTO’s and heads of engineering are not thinking about this as a specific discipline that can help to unlock untapped developer productivity and allow developers to spend more time in their “flow state”.
There is a massive amount of unstructured and non-technical work in engineering teams. Much of this is foisted upon engineering managers or developers that voluntarily decided to take on some of this work. This could be documentation and knowledge management activities, creating onboarding and training materials, implementing collaboration and communication tools, hosting team bonding activities, and building metrics and reporting for the team.
In the new world of Developer Enablement, a team that reports into a head of engineering would own the “glue work”. Much of the invisible work of engineering teams would be defined and elevated in importance, thus allowing for analysis, measurement, and iteration. For front-line engineering managers, they could then off-load this work to focus more of their time on technical mentoring, supporting team members, and maintaining their own technical skills.
Developer Enablement is not going to be something that takes off soon as a true discipline. It took nearly a decade for DevOps to become an accepted idea in most companies. Also, I do not have an awesomely catchy talk title and compelling presentation to lead a new movement! Jokes aside, there are startups today that are starting to touch this elephant called Developer Enablement, so expect to see this become its own category within the next five years.
Mark Birch, Editor & Founder of DEVBIZOPS
Want to learn more about DEVBIZOPS and read more hot takes about IT, technology, and working smarter. Receive our weekly newsletter by signing up to our Substack!