6 Steps to Keep Your Developers Productive and Happy – InApps 2022

The world has roughly 27 million software developers, and that number will grow to 45 million by the year 2030. 

If you are one of them, you have an outsized impact on the world — and more so if you manage a group of developers. A study by Stripe found that developers’ inefficiency, just “the stuff that gets in their way,” subtracts about $300 billion annually from global GDP. In 2018, bad code alone — just debugging and refactoring — wasted $85 billion of their time. Salary wasted on developer inefficiency — often due to having the wrong tools or processes — was estimated very conservatively at over $30,000 yearly per developer in the US.   

On the other hand, developers’ contribution to a company’s growth can be vastly larger than their salaries, by enabling new systems and business growth. 

There’s a Team for That

Happy developers are more productive. As Nicole Forsgren of GitHub writes, “developer productivity and satisfaction are intricately connected.” Productive, focused developers push technology progress faster. We aren’t proclaiming “Make a developer happy, and save the world” but we recommend that companies establish Developer Productivity and Happiness (DPH) teams. In dealing with thousands of developer groups, we’ve observed that having a DPH team correlates to higher productivity and better task prioritization and completion. 

The DPH team’s mission is to measure, communicate, recommend, and evaluate success/progress with feedback loops. The team does this by continually assessing the current state of developer productivity, identifying factors that impact it, and addressing the challenges identified. 

To some in the C-suite, a “happiness team” might sound new age, but developers are a unique class of essential employees, and DPH teams are an effective tool to address something you shouldn’t leave up to chance. Elevating developer satisfaction may entail giving them new, much-needed coding and QA tools that reduce time loss and help meet deadlines. It’s often a case of spend a little, gain a lot. 

DPH teams let you address the range of issues that negatively impact developers’ work, including:

• Frustration about suboptimal developer tools 
• Confusion about goals and what skills are needed for project success. e.g: a CI/CD infrastructure team may not have enough visibility into language-specific testing infrastructure
• Conflicting priorities. For example, when frequent tweaks to a website design interrupt focus on new product development

There are many subtle and changing contributors to DPH. An entire body of literature focuses on them, but we offer these six simple steps that we believe best help you leverage DPH teams and save $300 billion — or at least your piece of that.

#1. Spin Up a DPH Team and Assign Its Mandate

Who should be on the DPH team? Individuals who have seen the full range of development and project challenges are essential. Include representation of your developer demographic; people with some insight into their thinking and challenges. If you have developers offshore, include them in the DPH team as well. Developers working in remote geographies experience additional challenges that need to be understood — like high latency to web services, sub-optimal hardware and other material difficulties. Those developers can make great members of the DPH team.

 #2. Survey Your Developers

Your initial assignment will probably be to survey your developers. The DPH team will recommend solutions, so their broad experience and industry knowledge will come into play. 

To design a survey of developer productivity and happiness, some pointers: 

Think of the answers you need, and then devise the questions to elicit the useful responses needed. Starting with the question often yields subpar data. Asking “Do Zoom meetings break your workflow and diminish productivity?” will not get you the useful, actionable results that GitHub obtained from surveys during the pandemic. GitHub found that with: 

• 1 video meeting in the day, developers were 99% likely to output very good work
• 2 meetings, that dropped to 74%
• 3 meetings, good output collapsed to 11%

To get there, GitHub asked 40 developers these two questions every day for two weeks: “How many video meetings (Team, Zoom, etc) did you have?” And “Was your day very, somewhat, or not productive?” 

To obtain high participation, two questions is a good length. Participation will fall as you add questions. That said, it’s often good to use a combination of standardized scoring (evaluating on a five-point scale) and free-form text responses to obtain quantifiable results and reveal unknown issues. 

If your survey respondents speak English as a second language, the international members on your DPH team can ensure the survey is written in “global English” – English that is unlikely to be misunderstood by non-native speakers.  

In all your attempts to get developer feedback, consider safeguarding anonymity, so they can speak their mind. LinkedIn promised not to publish comments from any development team of five or fewer people, for example. 

#3. Identify Key Initiatives

In addition to surveying your developers, the new committee or team can also identify key initiatives and plan projects to work on key research findings. 

For example, development and testing tools may be ranked and critiqued — and gaps in the tool assortment could come to light.

Or the committee might decide to create a forum for feedback from developers so that there’s always a place for them to go to point out inefficiencies and voice their thoughts about what’s working or not working. 

Another possible initiative is to do a listening tour to proactively hear what developers have to say. Schedule time with 5-10 developers and ask them questions about their work frustrations and joys.

#4. Communicate Survey Results to Leadership and the Engineering Organization, with Recommendations

To convey results, it helps to describe the context of the survey or other initiatives, its scope and purpose, and who the respondents are, before going into the findings.

Here is where your carefully worded survey questions pay off, allowing you to focus on actionable findings. Quantitative results tying challenges to developer outcomes, as in the Github survey example, will be harder for the executive team to ignore. Pair your results with recommendations, for example, if an organization (like GitHub) found that exceeding two video meetings was a death blow to productive work, it could issue a directive to “empower” engineers to decline meetings. 

Actionable findings are those which can support recommendations such as a policy change, a process change, or acquisition or development of new tools. Actionable results enable clear, simple recommendations that can be quickly approved, debated, or rejected. 

#5. Enact Measures, Acquire New Tools Identified as Good Investments 

This is simply the phase of putting improvements into place. They could entail better equipment — bigger and better laptops for use at home during the pandemic — as well as new environments for testing and sharing builds. 

Changes could also be to processes, for example — to increase consistency between local development and cloud infrastructure. 

For engineering onboarding, bringing new employees up to productive levels, valuable recommendations could include better documentation and self-service tools.

Allan Leinwand, SVP of Engineering @ Slack, gave this recipe for DPH in a recent podcast: “Let developers solve big challenges at scale, see their solution put into use, and don’t make them work with jerks.”

#6. Feedback Loop; Follow-up Surveys to Evaluate Progress

The work of the DPH team is never finished; you’ll want to measure success of the team’s recommendations via follow-up surveys or other fast feedback loops. Repeat surveys also track shifting needs; for example, project codebases expand as software apps mature and are improved, so testing tools or methods need to accelerate. 

The frequency of follow-up is based on the tradeoffs you’d expect: the cost and time involved against the value of detecting inefficiencies and ideas to remedy them. As one example, in 2019, LinkedIn switched from annual to quarterly developer happiness surveys, and looked for opportunities to poll its developers about their satisfaction with the tools they had available. 

Other feedback mechanisms can include polls embedded in apps or delivered via email. 

The Takeaways

DPH teams are a straightforward way to improve developer productivity and satisfaction, as well as engineering outcomes. Going logically, step by step, allows you to look for the opportunities to “invest a little, but gain a lot” where all that’s needed is an adjustment to tools available, process modification, or more accurate prioritization of tasks.

Feature image via Pixabay.