You have 1 article left to read this month before you need to register a free LeadDev.com account.
7 minutes
Bridging the gap between the different ways that engineers and managers think about productivity.
Software engineering leaders want their software developers to be as productive as possible. However, it’s not uncommon to hear developers commenting that the systems, tools, and processes that are put in place to improve productivity are actually doing the opposite.
To unearth where this mismatch stems from, we ran a small developer productivity survey with our dev community to uncover how they are thinking about their productivity.
The results are ones that engineering leaders must understand because shipping meaningful code directly correlates with developer morale and overall performance at work. The end goal of engineering management is to empower devs to do their best work, meaning that managers can’t afford to be in the dark about productivity perceptions.
Developer productivity is more important than ever
Gone are the days of overflowing budgets and stacked-up dev teams – at least for now. Software development teams worldwide are all experiencing shared challenges, including budget cuts, back-to-work mandates, and mass layoffs.
Given the industry volatility, understanding dev productivity will help managers create better working environments to help devs do more with less, but it’ll also help identify where there’s waste in current developer processes.
For example, if tools and time-consuming expensive meetings are making it harder for devs to be focused on work, then cutting some of those things could offer a win-win: cost savings and happier devs.
Leaders may not realize that the exact systems put in place to boost productivity, like status check-in meetings, may actually make it more difficult for devs to thrive. On the other hand, these measures can also help leaders understand which processes and systems are actually improving dev productivity. Most commonly, alignment meetings and no-meeting days have a positive impact on developer productivity because they enable developers to spend time focusing deeply on coding as opposed to working in short bursts between meetings. But every team is different – it’s best to ask engineers in 1:1s what has the biggest impact for them.
Developers want to be productive just as much as their managers want them to be
Our developer survey highlighted that devs are at their happiest and most satisfied when they feel they’re getting work done at a solid pace. Developers want to be productive, just as much as their managers want them to be productive.
Flow state refers to those moments when engineers are fully immersed in their work, operating at a high level with sharp focus. This term isn’t just a buzzword – it’s a real state of mind and pace of work that developers thrive in. When developers experience interruptions or processes that prevent them from entering a flow state, work will feel more chaotic, cumbersome, and unsatisfying.
It’s equally as important that developers feel they are making meaningful, significant contributions to the code base. One developer provided this quote in our survey saying, “I like to feel like I made an impact either within my team or in the larger org. Lack of productivity, underemployment, or working on trivial stuff makes me frustrated.”
Another developer shared, “If I cannot be productive, I find it harder to work and enjoy my work less. When I’m productive, the day goes fast and I enjoy what I am doing.”
When devs feel they aren’t being productive, the resulting frustration and dissatisfaction could lead to them becoming more unengaged, less motivated, and less passionate about their work. None of these are good things if you’re trying to run a great developer experience program and ship great products.
Measuring developer productivity at a team vs. individual level
While productivity is often measured at the team level quantitatively, individuals tend to favor qualitative measurements.
Most organizations are purely focused on metric-driven measurement, like code changes and story points which are then communicated up the ladder to senior leadership. However, our survey results uncovered that developers measure their own productivity using qualitative indicators, such as time spent on planned and unplanned work.
There remains a strong case for leveraging both in different scenarios. For example, measuring how a team is improving in productivity over time by comparing the story points delivered per sprint six months ago versus today is a helpful metric to determine if you’re trending positively or negatively. Whereas more qualitative measures such as time spent debugging issues reported ad-hoc or transferring knowledge to colleagues could be more impactful when team-level productivity measurements aren’t meeting expectations.
When to use team-level measurement
The most traditional way to measure developer productivity is at the team level. For most teams, this looks like using story points, velocity, or issues/tickets closed as a benchmark for how the team performed that sprint or time period.
These macro-level metrics are a critical part of evaluating overall, holistic team performance. This method helps decision-makers see how a team is tracking over time and provides more predictable velocity data, through consistently measuring story points over time, allowing for a more confident estimation of lead times. It can also help leaders understand and track the impact of having team members away on vacation or other factors that may impact capacity.
However, team-level metrics don’t paint a complete picture of how developers are feeling and may not be as effective for measuring individual performance. If 1:1 conversations are focused only on how many story points were shipped, you could be missing a huge part of the narrative. A developer may have had too many meetings that week, they may have been uninspired, or they may have encountered major blockers. This is why addressing qualitative productivity measures is also important.
When to use individual-level measurement
A team is made up of individuals who have different motivators, family circumstances, and stress threshold levels. Because of these nuances, a one size fits all approach to motivating everyone won’t effectively work at a team level. Thinking about productivity at the individual level can lead to more actionable insights than at the team level. Individual-level measurement includes time in flow, time spent working on clear priorities, and shipping new features.
It’s also important to remember that metric-based, team productivity measures can sometimes be lagging indicators of individual productivity issues. So it can be helpful to look here first.
Measuring individual productivity: Where to start?
Productivity is subjective to a developer’s own experience. Here are some respondent’s thoughts on what productivity means to them.
- Focused, uninterrupted time to work on a task: “To me, being productive means being able to focus well on the current task, like a feature or a bug fix.”
- Moving forward without taking steps back: “Making steady progress on the main priorities without frequent backtracking due to quality issues.”
- Feeling like they have and see an impact on wider company goals: “Business impact generated. It’s not about story points or PRs sent or number of commits, those are misguiding indicators. It’s about how much this moves the business metrics.”
- Seeing actual, meaningful improvements in the code base: “I like to see visible improvements in the code base (GitHub differences) and completed features in deployment.”
The key themes here are developers being able to focus and be uninterrupted for an extended amount of time, being able to visualize their impact on the code base, and understanding how their work contributes to overall company goals.
As a leader, being cognizant of these themes can help you enrich your productivity-related conversations with developers. Approach these conversations with curiosity and ask powerful questions to help uncover how developers are feeling in light of these themes.
For example, you could ask a developer in a 1:1 if their schedules are overpopulated with repetitive meetings or tasks that are negatively impacting their productivity every week. You could alternatively ask them about how they feel about their contributions to the code base and if they are seeing the impact of their work. These curiosity-based questions will start painting a picture of where you, as a manager, can help developers feel better about their personal productivity. Combine these insights with team-level, metric-driven insights to develop a rich picture of the health of your team’s productivity.
Unfortunately, not everyone is in a situation where they have managers who will ask these questions. In that case, advocating for yourself and how you feel towards these core themes is incredibly important.
Final thoughts
Improving a team’s productivity requires looking at both team-level and individual-level factors. Though team-level metrics show how teams are performing while also offering predictability, individual-level measures help debug places where team-level metrics are trending in the wrong direction.
