Should Dev Happiness Become A Devops KPI?

The term “employee happiness” is thrown around quite a bit these days. It started out as a buzzword and became a business standard several years ago when Google promoted one of their first software engineers to the role of “Jolly Good Fellow”. Since happy workers are more productive and less likely to quit, they are the key to an organization’s success and longevity. This is why businesses work hard to increase the well-being of their employees.

But what happens when those employees are developers? With devs in short supply, the ability to make them happy is money in the bank. An opinion gaining traction in recent years claims that DevOps should be the ones responsible for dev happiness. So how does one cater to a developer’s well-being? And is DevOps truly responsible for driving dev happiness?

We tried to answer that question by making a list of dev-pleasers that every business aiming for growth and success should consider. Let’s see how many of the points mentioned here can be assigned to DevOps.

Give them all the right tools

It may sound obvious, but ensuring your developers have access to the right tools for accomplishing their tasks is an important part of creating a smooth operational flow. Devs enjoy having good infrastructure and systems that run well with no surprises. One of the most discouraging scenarios for a developer is being stuck for hours and days on end, on an issue that could have been avoided if they could only use a better tool. DevOps are responsible for preventing bottlenecks, are in charge of the ongoing tool availability, and for adding and removing tools. Since developers rely heavily on these resources, their delivery dramatically improves with the right stack.

Optimize workspaces and culture

Sure, perks, unlimited coffee, and snacks are all great. But let’s face it: it isn’t gonna cut it for making your office into a dynamo of dev-happiness. The perfect dev workspace, both virtual and physical, is one where the hum of productivity inspires without being distracting. It’s where developers can put their heads together without treading on each other’s toes.

Moreover, great workspaces stand out for their culture. A positive work culture should encourage independence balanced with structuring each task as an integral part of a whole. DevOps and heads of R&D should strive to set clear goals for their devs, but leave them the freedom of deciding how to achieve these goals.

Build connections

Coding can be lonely and atomizing. Build a supportive home base for devs by encouraging meaningful connections between team members and between their tasks. Make sure that each dev knows what role his assignment plays in the project at large and why it’s essential. One of the main roles of DevOps is to improve communication within and between cross-functional teams in the company. Better communication creates stronger connections and encourages devs to support each other, share expertise, insights, and give feedback.

Promote personal growth

With technologies changing at the speed of light (serverless, anyone?) each position represents a chance for a developer to build his or her personal toolkit, or have it grow stale. Give developers plenty of opportunities to grow in their jobs, and they’ll be less likely to seek growth elsewhere.

DevOps are often the company’s trailblazers. Be it breaking down a monolith into microservices, or moving to the cloud, they are the ones leading the way when it comes to changes. The implementation of such changes should be planned carefully from an architectural perspective. However, the human factor should always be taken into consideration as well. Use organizational changes to boost professional growth. Encourage devs to acquire new skills and provide the right training and tools to help them do that.

Provide technical challenges

Good developers are a curious bunch; the modern-day successors to the kids who disassembled clocks in garages to see what made them tick. Sending technical challenges their way will get you valuable solutions while keeping devs interested, engaged and excited. Keep in mind there’s a difference between challenging a newbie and an experienced developer. This is why you should assign tasks accordingly. Of course, this depends a lot on your organizational flows and isn’t always the DevOps responsibility.

Balance boredom with automation

As we’ve established above, challenge and personal growth are both important for making developers happy. While that holds true, a bit of work that allows for wandering minds can stimulate creativity and yield innovative approaches to stubborn problems. So keep just enough routine tasks in the mix to enable productive space-outs.

And although a bit of boredom may be beneficial, too much time wasted on repetitive tasks is simply frustrating, annoying, and a waste of valuable talent. Automate irritating tasks and set your devs free to do the quality work they’re itching to do. Finding the right balance between routine assignments and automation is certainly a DevOps responsibility.

Bypass avoidable constraints

As some of the most practical, logical, and resourceful people around, developers have little tolerance for constraints that seem small-minded and rigid. Policies that run counter to the dev ethos and put unnecessary stumbling blocks in their paths, are seen as constant annoyances and met with little tolerance. These can be open-source bans, refusal to acquire essential software, or having non-devs decide which technologies devs get to use. Do your best to ensure your developers have what they need. Whenever constraints are real and cannot be avoided, DevOps should step up to explain the situation and help find acceptable alternatives.

Let’s wrap things up

Contrary to the myth of the developer geek, good tools alone won’t bring much joy to your devs. Cultivating their happiness requires teamwork, measurable goals, and rich interactions. It should also involve interesting challenges and powerful feedback loops. Management, HR, and Product must all be attuned to the professional, psychological, and social factors that keep developers excited, engaged, committed, and curious. DevOps certainly plays an important role here as well. At its core, it emphasizes people over technology, but should dev happiness become a DevOps KPI?

I’ve heard contradicting opinions about this from different heads of R&D. Some claim the answer is a resounding yes since DevOps engineers are in charge of most of the contributing factors. After all, happier devs are more productive, which is crucial to the success of any company. Others aren’t so sure, however. They resolve to provide their engineers with the right tools and prefer to leave the softer side to other people within the organization. At the end of the day, it’s really up to your business culture to decide who will lead this important effort. Just makes sure to keep it in mind, and maybe save this post as a checklist. 😉