Don’t Drive Away Your Developers: IT Processes to Defeat Burnout
Developer burnout is a real problem for developers and the organizations they work for — the companies that rely on them to build the next generation of innovative products.
This problem is exacerbated in a post-pandemic job market where job seekers have all the leverage. If you are responsible for a technology organization that relies on these developers, you ignore the problem of burnout at your own peril.
So, what are the contributing factors that are potentially driving your developers into the arms of other companies and, more importantly, how can you address developer burnout and incentivize them to stay?
Governance, Bottlenecks, and Budgets… Oh My!
The developer’s job is to create software and applications. Anything that distracts from their job or confounds the process is a headache, slowing their productivity and/or negatively impacting work/life balance. It’s often the provisioning of application environments where developers run into the first and one of the most persistent headaches.
Developers need dev, test, performance and production environments for different stages of the software development process. But rarely (almost never) do they have the expertise to spin up these environments, so they must rely on a centralized DevOps team to provision them. Unfortunately, the process from request to fulfillment can take weeks — I’m not exaggerating about this, folks — literally weeks.
There are endless requirements and configurations for environments, but provisioning an environment in a typical large enterprise might look something like this: The developer opens a ticket, then one person might need to set up a VM/server in the first stage, then it would be passed over to another person who would set up the IP, and yet another would implement security protocols and so on. Meanwhile, the developer waiting for the environment is sitting largely idle and unproductive — and probably questioning their choice of employers.
The next soul-crushing, burnout-inducing misery machine developers often have to hear about is governance over these environments. Every enterprise is required to adhere to some industry compliance and/or internal security mandate that can create burdensome processes when it comes to managing the environments developers use.
In fact, this is one of the reasons that a central DevOps team must be responsible for provisioning these environments. This shouldn’t be part of a developer’s job, but they are still impacted by it because they may have to hear about it from their boss or their boss’s boss — “Did you get the memo? It’s just that we’re putting new coversheets on all the TPS reports before they go out.”
Last, but not least, is the issue of cloud costs and budgeting. One of the fastest ways to destroy a relationship is to make it about money. This includes your relationship with developers. Just like governance, this absolutely should not be the developer’s problem. But cloud costs are a significant line item in any IT budget, and guess who’s using these environments? I’ll give you a hint: It’s probably not your cat.
Burdening developers with security and compliance protocols, beating them over the head with budgetary considerations and just plain throttling their productivity all contribute to developer burnout, which can be rectified simply by implementing a few new systems and processes.
Save the Environment(s)!
Ultimately, your developers need to create environments quickly and simply with just a few clicks. Those environments need baked-in governance, tagged to track cloud costs consistently and easily, so you, your boss and your boss’s boss will know where that expense is going. And each one of those environments should get torn down automatically when they are no longer in use to minimize costs and the number of times your developers have to hear about it from every one of their five bosses.
Today, most organizations are using Infrastructure-as-Code (IaC) tools to provision environments for their developers. And IaC is great; it’s an important piece of the application environment puzzle. But if you’re using only IaC to provision infrastructure, that’s where the value ends — provisioning.
Most businesses lack a strategy for complete environment lifecycle management — a control plane that you can use with your existing IaC solution and other tools in your DevOps pipeline to automate processes, enforce governance and help optimize costs. This would significantly relieve your developers of burdensome operational considerations that shouldn’t be theirs to consider in the first place.
Instead of coding each environment every time or digging through a repository of IaC scripts to piece together the appropriate configuration each time a developer needs a specific environment to do their job, you need to provide them with preconfigured environment blueprints. In other words, you can apply automation to spin up and manage environments for your developers and save them the hassle of waiting weeks to get down to business.
Once these environments are configured appropriately, they can be blueprinted, and developers can access them via self-service governed by Role-Based Access Controls (RBAC). Now developers don’t have to worry about using the right compute type or approved infrastructure components. They just create the environment from the selected blueprint.
This holistic approach, which considers the complete application environment, is an evolution from just thinking about the infrastructure alone. When viewed from the environment level, you can remove the hassle of constantly worrying about governance and cost controls.
More importantly, you don’t have to worry about how your developers are using those environments. When you are able to blueprint their environments to enforce compliance and corporate security standards, set run-time limits and gain visibility into cloud resource consumption, you make everyone’s job easier.
Developers are what make technology tick, so it is important to keep them happy and to keep them around. Imagine if you could tell your developers, “Now we’re automating your environments so you can get to work quicker and we don’t have to worry about costs and compliance — did you get the memo?”