Leveraging Engineering Analytics for Developers’ Well-Being

The context

Change happens constantly and gradually. Unless we’re speaking about events that upend our normal way of life, say a pandemic, for example; most large changes happen as an undercurrent without our deliberate awareness. And then, suddenly, we find ourselves in a completely new normal. 

The problem

In software development teams, such gradual changes have now led to the new reality of remote work, globally distributed teams, and SaaS sprawl. This change has helped dev teams to become faster, more productive, and more successful. However, it has also created a new challenge to engineering managers and leaders - EMs face the challenge of not having informed and deep visibility into their team’s work activities, well-being, and productivity. Furthermore, dev team leaders are unable to manage their SaaS sprawl and the processes that their teams use. Without this visibility, engineering managers and leaders are unable to understand how their teams work nor find avenues to help their coworkers to perform better. This obstructs their ability to gauge bottlenecks and prepare for process improvements. Even though many remote teams adopt 1:1s to combat the challenge, the lack of personal connection and bonding opportunities have made remote 1:1s less effective. 

For developers too, remote work and SaaS sprawl have brought on a new stream of new challenges. For most developers, the unplanned shift to remote work and the swift, unorganized adoption of SaaS tools has created uncertainty around processes, commitments, measurements, and management. An increasing tool stack inevitably leads to notification overload that can create threats to developer efficiency and flow and cause increased instances of context switching. As developers switch between apps and tasks, they develop the habit and find a need to stay “always-on” or digitally plugged in to complete their tasks and accommodate the different demands of distributed working. All these lags in productivity add to the many stresses of adapting to working from home, contributing to the growing problem of developer burnout. 

The solution: Data-driven engineering management

What can leaders and managers do to combat this snowballing impact of poor visibility? 

One solution that has captured the imagination of leaders and proven as a potent way forward is the use of data-driven engineering management. Using de-identified data and work analytics from a dev team’s tool stack, engineering managers and leaders are able to get factual operational visibility into their teams, processes, and technology. 

Visibility into engineering workflows and metrics

Software development workflows can be tedious and complex. With data-driven visibility into engineering workflows, managers can optimize their processes for success.  

Work activity heatmap

A heatmap of work activity can help managers visualize and understand a developer’s or team’s work outside of regular work hours. This can help managers gauge how much and how frequently engineers have to work outside work hours and more importantly, this data can help answer why team members have to work too many hours. In many cases this data can identify process flaws such as poor collaboration across different time zones that lead to a developer waiting on a code review from a team in a distant time zone, or when developers have scheduled meetings at non working hours. Other times, this data can draw attention to the threat of burnout owing to cases where incident alerts or pages from Pagerduty that keep developers working at odd times.

Cycle time

High cycle time has far reaching consequences to developer experience and their well being. Understanding the nuances of why the cycle time metric is high can help engineering managers optimize their processes. For example, high workload or large PR sizes can lead to increased pick up times that leads to high cycle time. Similarly, when developers have to wait long periods of time for code reviews, this can be an indication of low team involvement or the logistical problems of reviewers and authors being spread across different locations or timezones, or even long CI time or flaky builds/tests where authors might be quick to create code but they have to wait hours for automated tests or the builds to pass to be able to get a stamp of approval by the machines for the reviewers to pickup the PR for code review.

Cycle time could also be high when the response time from authors or reviewers is high. In such a case, managers can measure the response time of reviews which indicates the average time it takes for reviewers and authors to respond to comments. Sometimes, this can show that pickup time (or first review) happens quickly, but it’s often that the authors and the reviewers take long to respond to review comments thus increasing the time it takes to get the code approved. 

Interview load 

Hiring never ends for most companies and for growing teams, it is often the case that engineers spend a lot of time interviewing potential new team mates. Managers should be cognizant of the time and effort that their team members spend in interviews and factor this task into their effort and workload allocation to balance workload management.

Incident load  

Incident alerts are high-stress events. They are even more stressful if they keep developers up at night to resolve incidents. In fact, incident management is a leading cause of burnout in growing companies and they degrade developer experience significantly. Managers should use data to get a comprehensive understanding of which team members are tasked with high incident loads and use work analytics to allocate the load across the team fairly. This can ensure fair contribution and reduce the risk of stress and burnout for developers. 

Pre-empt burnout

Developer burnout is increasingly becoming commonplace in the new normal of work. In fact, a survey showed that 80% of developers that responded to the study experienced burnout symptoms. Loss in productivity, missed deadlines, and lack of involvement are leading indicators of dev burnout and are becoming a factor of great concern to managers. Data and work analytics can help managers identify signals of stress, exhaustion, burnout, or dip in productivity. This can equip managers with the necessary data to structure well-being programs, or employee experience programs to build more resilient and healthy teams. (More on how to manage burnout in your remote teams). 

Maker time and deep work 

Highly productive engineering teams are able to provide 70% of the workday as maker’s time to their developers. In order to preserve and promote maker’s time, managers can measure how much time their team members are able to spend on focused, deep work without context switching. Data can provide a viewpoint into the breakdown between focus time and collab time, giving managers an opportunity to schedule meetings or other collaborative tasks on days or in time slots that do not risk their teams’ maker’s time.

Run async standups using work snapshots 

Almost all software development work is done using tools in the digital workplace. This has eliminated the need for synchronous stand up meetings where managers inquire about what their team members are working on. Especially, when managing teams that are distributed across locations or even across time zones, sync check-ins cause more damage to productivity since they hamper flow and risk maker time and deep work. A better solution is the use of async work and adapting this process to run async stand-ups. Managers can use work visibility to be in the loop, using data to stay cognizant of their team’s work activities, task roadmap, sprint progress, and blockers, if any. Using data to inform of work progress, allows managers to use the async stand-up as an avenue to focus the meetings towards addressing issues like blockers and other activities that are better done synchronously.

Effort allocation 

Good engineering managers are adept at gauging overwork in their teams. Does one developer have too much work assigned? Are developers getting a healthy breadth of work? Or are some contributors spending most of their time bug fixing without a roadmap? Data about effort allocation can help managers gauge the spread of resource allocation across projects so that their team members have a meaningful work experience that strengthens their professional learning and growth. Smart use of this data can help managers allocate work to allow their team members to build expertise without which developers usually work on several varied projects that can lead to context switching and might result in lack of subject matter expertise.

Workload index  

Data-driven visibility facilitates managers to allocate and balance workload in a fair and transparent manner. This allocation can take into account their teams’ existing work share, location/time zone, and past indicators of learning and progress. Going beyond tasks, engineering managers can use data to allocate PR reviews, incident management or even interview load such that the team can plan productive work time that allows for individual well-being, growth, and goals.    

Data-driven 1:1 meetings

Data can help managers structure 1:1 meeting agendas that are relevant, action-oriented, empathetic, and targeted to each developer’s needs. When managers use data from work analytics, they can get a viewpoint to their team’s work activities and workloads, communication and collaboration activities, and workflows. Using this data, managers are able to gain insights into patterns that cause bottlenecks or those that lead to sustainable success. This understanding can help a manager offer the right support to their teammates. Creative, empathetic, and committed leadership in using data to inform meeting agendas can contribute to sustained individual and team success. 

Ensure developer experience

Developer experience is a measure of developer’s satisfaction with their tasks, the tools they use, and the processes that their teams use. It highlights the interrelated nature of work, well-being, and productivity. Well-being metrics from work analytics capture the satisfaction index of developers and how their work affects their health and well-being. Going beyond being just a happiness index, developer experience metrics capture how teams work together, cohesively, to create value and how team culture impacts individual performance. 

Data can create visibility into how teams interact and help managers identify gaps in communication to optimize and support better team performance. 

Visibility is a challenge as we navigate remote and hybrid workspaces that use a sprawling number of tools to get work done. However, there is inspiring potential in using data-driven engineering management to create better processes and workflows that propel teams to sustainable, long-term productivity. 

💡 With over 60+ engineering metrics, Hatica is an engineering management platform that equips engineering managers with visibility into their team’s workload, contributions, and processes to help them manage work effectively without burnout.