Why developer enablement is a crucial part of DevOps

DevOps is a concoction of ideas which aims to help developers deliver higher quality software at a quicker pace.

DevOps is hard to define and that is a good thing. It leaves room for flexibility and for each company to figure out what they need to do to enable autonomous and high performing development teams.

However, over the past couple of years the industry has found that certain ways of working, using certain tools, building applications in certain ways, has proven more successful than others. Like breaking your application into smaller parts (microservices), which makes it easier to modify and deploy only the part you intend to. Or ensuring that you have automated tests; not only a couple of unit tests, but enough test coverage that you feel comfortable making changes to your code base without manually verifying that everything is still working.

A lot can be said about tools, processes, architecture, leadership and many other things. I will likely do so in future posts (and I have linked to a couple of good resources at the bottom of this one) but for now, I want to highlight my favorite principal from the DevOps concoction and the one I have come to double down on over the past couple of years.

Increasing speed by enabling ownership

DevOps is speed, which is achievable when your operations department enables the software development teams to take complete ownership of their services.

We want to structure our organisation in such a way that each team can take full responsibility for their deliverables. The team should own the entire life cycle: Planning, implementing, building, testing, deploying, monitoring and supporting.

Why?

Because the alternative is that different parts of the organisation are responsible for different steps of the life cycle. This requires handovers. Handovers take time. Handovers implies communicating complex ideas, which is difficult. Handovers are very seldom the reason one becomes a software developer.

Handovers cost money.

But taking responsibility is not something the team can do on their own. We must give them the opportunity to take responsibility and provide them with the tools required to do their best work. Furthermore, it’s imperative that we remove as many hurdles as possible for the team.

We must enable developer ownership.

Silos

The most common hurdle I see in the industry, making it difficult to enable development teams to own their deliverables, is working in an organisation with silos.

Here are a couple of silo hurdles:

• The development team cannot deploy their product because the QA department needs to test each release first.
• The development team cannot start implementing a new service, because they need to wait for the Operations department to give them a new VM and database.
• The development team doesn’t understand how or why they should implement a certain feature, because they do not get to speak to the end user, nor the people supporting and monitoring their application.

Every hurdle takes time, depletes the involved people of energy, and costs money.

When we work in silos, it is very common that each silo attempt to maximise their own goals instead of focusing on what yields the maximum utility for the end user (and therefore the company). In a silos organisation, the Operations department gets praised if all systems are operational and there is no down-time. In that same organisation, the QA department gets praised when there are no bugs in the code.

Do you know what causes down-time and bugs? Change. Change causes both.

But a company that does not change, evolve and improve will soon be left in the dust.

So instead of maximising for “not making any changes what so ever”, we should maximise for “making it super easy to quickly iterate and learn”. (In most cases, under most circumstances) it is OK to have a bug in your application, if a new release can be deployed within 5 minutes of you committing the change to source control.

We should build an organisation with a common goal (satisfy the customers’ current and future needs) and do everything we can to enable our developers to satisfy those needs.

Enablement through a self-service platform

How do we enable our developers to satisfy our customers’ needs?

Get the info to the developers

We must ensure our developers get the right information. If the developers do not understand how their application is being used and what functionality their users like, dislike or lack, they will not be able to build a product that satisfy their users’ needs.

Our developers should be encouraged to interact with end users and learn from them. Additionally, our developers should definitely build their applications in such a way that they can derive meaningful metrics based on how their users interact with the product.

Provision infrastructure

Best case scenario we give our developers access to some Cloud Service Provider where each team can provision resources as they see fit. This has the added benefit of fostering developers who understand the financial aspects of a company, as well as the technical.

If the team understand the cost of their infrastructure as well as the income their application generate, they can make informed decisions about new features, performance improvements, and cost reducing measures. Few organisations are willing to go this far, but the transparency is likely something many developers would welcome.

In a sufficiently large organisation, there is likely a need for an operations department (or a platform team) that ensures each development team can acquire what they need as soon as they need it, in a self-service manner. The Platform Team can help unify the tech stack of the organisation to a feasible spread and we can also get some economy of scale benefits by reusing ideas and concepts across several teams. Of the top of my head I come to think about in-house maintained Terraform modules with reasonable defaults.

If our organisation consists of just a handful of people, we might not be able to motivate a separate team to manage our platform. In such a case it becomes crucial to build your teams with people who take responsibility to acquire the skills and tools they need to handle their product’s life cycle.

---

Future posts

Ping me on Twitter @ErikThorsell if you have any ideas for topics in future posts or you would like to discuss this one.

Further reading

If you want to learn more about which tools, architectural principles and ways of working the industry has concluded to be successful over the past decade, take a look at the resources linked below. They are sorted according to how short they are.

• The State of Devops report that Puppet put together every year (since 2013). Here’s the 2021 one and here’s all of them.
• The Phoenix project and The Unicorn project are two books looking at a company’s DevOps transformation from two different perspectives (a manager’s and a developer’s respectively).
• Accelerate by Nicole Forsgren et al. is an excellent book on how to apply Lean principles to software development.
• The DevOps Handbook is exactly what it claims to be. It is Gene Kim et al.’s instruction manual for adopting DevOps principles in any company.