Using Data to Boost Developer Happiness

Romain Dupas, director of software engineering at Code Climate, discusses how data can be used to increase developer happiness and engagement, which is crucial for retention and recruitment in an ever-worsening developer shortage. 

Objective data can help managers remove productivity blockers, provide opportunities for growth, and create a safe environment that encourages risk-taking. The article provides examples of how data can be used to improve standup meetings, hold meaningful 1:1 conversations, and cultivate a blameless culture.

You may not be able to put a price on happiness, but you can quantify its ROI. In an ever-worsening developer shortage, developer satisfaction and engagement are key to retention and recruitment, which means they are critical to a company’s bottom line.

Both academic researchOpens a new window and industry surveysOpens a new window indicate some common factors driving developer engagement. Developers want:

• To feel productive: not blocked by opaque or shifting priorities or stuck doing work with unclear value.
• Meaningful opportunities: the chance to grow and do work with a visible impact.
• A safe environment: the confidence to make suggestions and take risks without fear of punishment for upsetting the status quo.

It’s difficult for leaders to know when their organization is missing the mark on these factors. The farther away they are from their team’s day-to-day work, the harder it is to get a true sense of what their team is dealing with and how they might feel about it. 

Objective data can help managers better support their team’s emotional needs. With the right information, leaders can spot and remove blockers to productivity, provide opportunities for meaningful growth, and create the safety necessary to encourage risk-taking.  

Adopt a Data-Driven Approach

Feeling unproductive at work is the leading cause of developer unhappinessOpens a new window . But productivity is more than meeting deadlines and shipping features; it’s also about how work moves through the software development pipeline daily. 

Consider this — an engineering manager notices that her flat team of ten engineers seems disengaged during daily standups. People are zoning out, on their phones, and not engaged in discussion. She brings it up with individual team members during 1:1s and finds that people think standups are inefficient and a waste of time. She hypothesizes that the flat team structure isn’t efficient and wants to check this hunch against data. She looks at Pushes per Day over the previous six months and confirms that efficiency is decreasing monthly. 

The action plan is to roll out a new practice of proactive standup preparation and opt for smaller team meetings hoping to boost engagement. 

Before the meeting asks herself the following questions:

• What did you do yesterday?
• What will you do today?
• What (if anything) is blocking your progress?

Instead of starting with basic team updates, she dives right into weightier discussions. By allowing the data to speak for itself, she can facilitate important discussions without wasting time rehashing information. This approach leads to more fruitful conversations and a swifter, less stressful transition to problem-solving. This new standard practice sets a cadence for the meetings to be more productive by skipping past basic updates.

She brings this insight to the leadership team with the human context and the data and suggests a solution — break up the 10-person team into groups of three or four engineers, so everyone isn’t bogged down by long meetings. The smaller meeting was inherently more dynamic, and the team had more valuable and, therefore, more engaging conversations and people were tuning in and participating. She hypothesizes that individual engineers will be more focused, and smaller teams can have more engaging and productive stand-ups.

It turns out she’s right. The shift to smaller teams and the standup prep leads to letting engineers do more of what they love (coding) and less of what they hate (pointless meetings). Over the next few months, the smaller teams increase their average Pushes per Day by more than 80%, confirming the hypothesis.

Have More Impactful 1:1s with Senior Engineers

Engineers at every experience level report highly valuing growth opportunities, but it can take time to effectively upskill senior engineers. Their skill gaps are harder to spot than entry-level engineers, and progress is difficult to quantify. Engineering metrics can help team leads identify opportunities and hold meaningful 1:1 conversations about career goals. 

For example, data may show that engineers have been committing most of their time to a narrow set of tasks. If the engineer is feeling stuck in a rut, their manager can create opportunities for hands-on learning by seconding them to a different project. An EMP can also show when a team can afford to reallocate project resources and where additional help is most needed.

During performance reviews, an EMP can ensure that a manager knows which projects and initiatives an engineer has touched on. They can also frame an individual’s contributions in terms of business impact, e.g., “You led X, which had Y effect, and impacted our business in the following ways…” Modeling this for engineers helps them advocate for themselves and increases their sense of productivity and job satisfaction.

See More: Human Error Doesn’t Have To Be A Single Point of Failure

Build a Blameless Culture

Psychological safety is a prerequisite for innovation. Before engineers can push themselves and question the status quo, they need to feel confident that it’s acceptable to ask questions, experiment, and make mistakes. 

Framing problems in terms of discrete work units can help keep conversations grounded. Using objective data, the team can define the issue specifically and narrowly, spot recurrences, and avoid singling out individuals for criticism by keeping focus on the work itself. This helps cultivate the blameless culture crucial to continuous improvement and high developer satisfaction. In a blameless culture, developers know they can draw attention to an issue without fear of reprisal toward themselves or a teammate. Instead, there’s a constructive conversation and an opportunity for learning. Problems don’t fester, and the team practices trust and collaboration.

As these examples show, data is more than just a decision-making tool. It can also help engineering leaders steward team culture and protect developer morale. Engineering managers have had to rely on qualitative clues to assess their team’s happiness for decades. That human insight is still essential, but now leaders have objective tools to alert them to potential issues and guide team interactions. 

A data-driven approach can help business leaders keep their most valuable employees engaged. Objective data, combined with the context of personal observations, can help managers make choices that benefit their team and keep their most valuable employees happy.

How are you ensuring that your developers are engaged and happy? Share with us on FacebookOpens a new window , TwitterOpens a new window , and LinkedInOpens a new window . We’d love to know!

MORE ON DEVELOPERS

• Developer Burnout Is Real, Here’s What To Do About It
• The Three As of Supporting Your Development Team
• Retain Your Development Talent with The Power of Clean Code
• How to Use Progressive Deployment to Address Dev Team Burnout
• Why Building a DevOps Culture Is Critical to Digital TransformationOpens a new window Opens a new window