While the past few years saw a big drive towards caring for employees, the last months have seen the pendulum swing in the other direction. The tech industry has been harrowed by layoffs and economic uncertainty — and that’s directly impacting existing employees’ morale and well-being, which in turn affects their productivity.
Digital health tools, better mental health treatment and mental health days are great steps, but they do not directly address some of the root causes of software engineer dissatisfaction at work. To counter this productivity-sapping trend, companies need to be thinking more about developer experience (DX). DX looks significantly different from general employee well-being.
Developer experience is more about how software developers feel about the work they do on a daily basis, and that’s directly influenced by the tools and processes they use. That means looking at your team’s experience of the work day itself, the resources they use, and the efficiency of their workflow. The benefit of optimizing those elements is not only happier developers — it translates directly into better business results.
Engineering leaders can do this by more effectively monitoring engineer satisfaction and performance to spot factors that are harming your engineering team’s experience. They should embrace new, holistic metrics and learn how to respond to them. Here are the steps any tech company can take to better understand and improve their developers’ experience.
Get to the root of problems in the workplace
A staggering 3 in 4 software developers globally have experienced burnout in their lifetimes, and engineering leaders everywhere should be asking themselves why. One of the problems is that we’re essentially making engineers’ lives more difficult than they need to be. We have tools to better optimize the workflows and resources software developers use on a daily basis — which would improve their day-to-day experience and help reduce the risk of burnout. However, we may be missing opportunities to make those improvements because we’re not tracking the right metrics on how our engineering teams work, or talking to them enough about their experience.
Another problem is that we haven’t been enabling software developers to engage in more fulfilling tasks. The 2019 State of DevOps report found that software developers often spend just 30 to 40% of their time actually creating features, while most of their time is consumed by delays and admin work. Fixing these time-consuming, low-reward tasks can lead to greater career development and job satisfaction.
Tools that give engineering leaders visibility into this data are widely available and can drastically improve a developer’s experience. If we harness them, each business can start identifying their own unique root causes for developer dissatisfaction at work.
How to improve developer experience: Give it SPACE
There are two things engineering leaders need to look at: the best metrics to really gain insights into DX and how to use that information to improve how software developers feel on the job.
A growing number of companies are turning to DORA metrics to measure software development performance.
These are critical indicators, which essentially measure agility and quality. However, they don’t give the full picture. Indeed, the same team that created DORA’s four key metrics went one step further, and created the more holistic SPACE metrics system. These encompass all of DORA’s metrics, while also looking at the human or emotional aspect of software engineers’ work (or “Satisfaction and well-being”).
Here’s a breakdown of SPACE:
- Satisfaction and well-being: software engineers’ satisfaction on the job, happiness and positive habits
- Example metric: typically measured qualitatively using questionnaires
- Performance: tracks the results of the team’s systems and processes
- Example metric: change failure rate. Indicates how often a team’s deployments to production fail or get canceled
- Activity: measures development team outputs
- Example metrics: pull requests in progress; pull requests reviewed
- Communication and collaboration: how effectively teams communicate during the software development process
- Example metric: sharing index and collaboration map
- Efficiency and flow: tasks accomplished rapidly and with minimal interruption
- Example metric: mean time to recovery (measures the amount of time it takes to recover from a failure in production, and shows how efficient your team is at fixing problems)
Use relevant metrics to improve experience in concrete ways
To improve developer experience, first spot the factors that might be harming it. Bottlenecks can be stress triggers. Outdated or complex technologies can make your engineering teams’ job exponentially harder.
Identify which metrics are lagging. You can do so by comparing your team’s numbers to industry benchmarks, or to the same metrics from previous quarters to see if there have been negative changes.
For example, one important metric is “lead time for changes”: the time it takes for changes to get to the codebase (or how much time has passed between commiting the code and sending it to production). If lead time takes too long, it means the development process has inefficiencies. It may be that the workflow is getting interrupted because the process of implementation or testing of the code changes is too complex. Any interruptions can cause frustrations within the team, especially if they go unnoticed and unaddressed, and end up impacting the team’s overall results.
Creating visibility into potential sources of dissatisfaction also means asking for individual feedback on people’s experience as part of the “Satisfaction and well being” metric. You could request targeted feedback on a specific aspect of a developer’s work, if you’ve already been seeing red flags come up from other metrics. Don’t try to guess at the solution without speaking to your team about the core problem.
On a broader level, satisfaction is also measured in retention — if you’re losing developers, even though your performance metrics appear to be high, there’s probably a blocker in another aspect of your company. That could be a lack of communication within the team, leaving developers feeling isolated. It could be disorganization within the workflow that sends them fleeing into the arms of more structured processes. Approach the issue with curiosity and an open mind to consider all the possible influences.
Satisfied developers mean better results for your business
Better DX goes hand in hand with a more agile development process and greater productivity. By knocking down barriers that are frustrating software developers, you’re inherently creating a smoother and more effective workflow. Greater efficiency also frees up time for individuals, which they can dedicate to more fulfilling and higher impact tasks. Spending time on their personal and career development means happier developers who are also developing valuable skills.
Think about how worker satisfaction influences your customers and your brand, too. More satisfied developers are more likely to interact with users in a more positive way than if they’re overexerted and disgruntled. They can also act as some of your most important brand ambassadors. How they view your internal workings, your treatment of developers and respect for others, is also what they will transmit to the world now and in future.
Remember, visibility into the software development process cannot stop at the numbers. The best way of determining a developer’s experience is, well, asking the developer. By showing your team you care about how they feel at work, you can develop a far better relationship, and eliminate any roadblocks to productivity before they do too much damage to your team and your business.