[

🎉

G2 Spring 2024 Report] Hatica does it again! Wins Momentum Leader, Best Est. ROI and Users Love Us badge among many!Read More ->

Productivity2022-12-08

4 Reasons Behind Low Developer Productivity in Tech

The blog post talks about the reasons behind low developer productivity in tech, and ways to increase productivity through engineering analytics platforms. 
Developer Productivity Crisis

Developer productivity has become a global phenomenon with even the trillion-dollar giant, Google talking about it. Recently, Google's Pichai talked about the endless, million-dollar productivity crisis, with an ambitious goal to up the numbers by 20%. However, Google isn't the first or the last tech company to talk about EngProd. 

Despite an uptick in the average software developer salary, engineering hirings are a mess. Even though 2022 produced 373 tech unicorns, the year also saw the great engineering resignation kicking in. This structural dualism in tech has a core reason: The developers are unhappy, unsatisfied, and, even somewhere, unproductive. 

Today, most businesses are at a loss of $300 billion annually due to low developer productivity. While 9 out of 10 engineering managers struggle with low engineering efficiency; they just don't know how to resolve it, despite humongous willingness. 

In this blog we will explore the reasons behind low developer productivity in tech, and ways to improve developer productivity through engineering analytics platforms. 

Let’s get started!

What are the Reasons Behind Low Developer Productivity?

Reasons for Low Developer Productivity in Tech

We'll look at a few factors that contribute to low developer productivity. By exploring these reasons, we aim to provide insights into how organizations can create an environment that improves productivity and empowers their developers to deliver exceptional results.

1. A Clogged SDLC and Inefficient Dev Workflows 

An ideal SDLC is not just about writing and shipping code to build running applications but also takes care of code reviews, maintaining information feedback, and releasing code on time (and not just writing it).

Developers are efficient at writing code, but not all code written sees the light of production days. For engineering managers, it is a matter of concern how much of the code is finally released into staging and production. More often, developers face imposter syndrome- making them their own worst critics. The lack of confidence in their code is further aggravated by a broken code review cycle- taking us to the second part of the problem. 

Most organizations lack an established and documented code review process; there is no proper record of who does what. Traditionally, software teams don't consider code reviews as a primary task- so no official work hours are allocated for the cumbersome process. Sometimes, a code will be shelved for days, either because domain experts are unavailable or developers don't trust the code they write. 

Waiting for code maintainers or peers for code reviews blocks developers for hours and eventually harms team cohesion. In other scenarios, the reviews done might be ineffective, and the process will have to be picked by other developers from scratch. This broken feedback cycle costs an average developer 5-10 hours a week and is the third top reason for developer frustration globally. 

2. Alignment Challenges: Are Your Business and Engineering Teams On the Same Page? 

A successful product is built with the collaboration of engineering and business teams. Both teams bring different expertise, and goals to the table, and prioritizing which ones to focus on first becomes a bone of contention. Most times, the two teams work with completely disparate mindsets: working independently, splitting attention, and thus, deviating from the core product vision. 

Even sometimes, engineering managers are unable to articulate their mission well to the techies and how their work fits into the bigger picture. Without any proper context, most engineers either shift to working on shadow projects with minimal business value or feel disenchanted with the product itself. This estrangement is so rampant that 16% of engineers have started feeling actively disengaged from the product (and the process) they are building. 

Moreover, a lack of developer alignment might even shelve your project's release indefinitely- making all the spent money, time, and human resources a colossal waste. The process can have severe consequences especially when the recession is at our doorstep and businesses, especially tech, are cutting down costs and freezing hiring. 

3. Overflowing Non-Core Tasks 

None-core tasks of a software engineer

In an ideal world, a software engineer's primary job includes writing code and running software. Ironically, an average engineer only codes around 30% of the time. So where does the rest 70% go? Most engineers spend their major work hours handling the business side of things, including software maintenance, and modernizing legacy infrastructure. In addition, if an organization is at a lower DevOps maturity level, it is the engineers that also have to lead the Ops: service stability, fix bugs that escaped QA, developing productivity tools, CI/CD workflows, and managing pre-commit testing.

Another non-core task that hampers developer productivity is hiring, taking interviews, and retaining software talents. Numbers speak volumes here- 40% of engineers disparage attending interview calls and terms the process too heavy to follow. Constant hiring calls from the top tier leave most engineers alienated from their core coding duties, causing frustration and even chronic developer burnout

4. Context Switching: High-Cost, High-Impact Productivity Killer 

In 2021, core coding days for engineers went down to 1.6 days a week. For engineers, constant meetings across a workday take most of their maker time. An average developer has almost 87 interruptions a day, and each interruption takes away another 10-15 minutes before the developer can get back to rewriting code. Most of these interruptions are caused by constant paging alerts and standup notifications. 

While modern-day standups are supposed to last 10 minutes, they unwillingly extend to an hour. For others, attending meetings isn't an issue, but their unsustainable distribution across a day is. Another issue is skewed resource mismanagement towards KLTO. Devs are already under tremendous pressure to release complex products. On top of it, constant maintenance and operational tasks keep them hooked even outside work hours. This frequent firefighting to keep systems up and running overburdens developers and create well-being issues. In the past six months, 82% of engineers experienced burnout and severe health concerns. The numbers speak for themselves here!

All this constant toggling leaves developers no time for deep work. On average, a programmer only gets one undisturbed 2-hour work session per day.

[Read: How to Prevent Software Engineers' Burnout?]

Parting Note 

Low developer productivity might snowball into a high product backlog, low quality, and difficult customer retention- negatively affecting the brand consensus. Productivity is not just about filling checkboxes every week; rather it means enjoying working and growing in an environment while taking care of your well-being. 

So, how can engineering managers drive developer productivity? The best way to start with the burning issue is through identifying what prevents developers from doing their best work; for some teams it is higher communication debt, while for others, it is an unstreamlined SDLC. The real reasons could only be determined through higher visibility into the engineering system. Using an engineering analytics tool, like Hatica offers managers visibility into their team's work activities so meetings become more data-driven, and work highly productive.

The standard Hatica dashboard helps team leads identify developer heatmaps, interview and incident load, conduct async standups, and drive actionable insights from collated data reports. Hatica also combined external metrics like DORA to measure efficiency, while ensuring an effective maker schedule

Hatica developer dashboard

Qualitatively speaking, developers must also retain some time from their schedule dedicated to growth and innovation. The practice helps create more well-rounded developers, and increase personal profile, which can later snowball into developer happiness and higher developer experience. Larry Page advises blocking 20% for side hustles. That's how Gmail was created in the first place. 

Achieve 40% higher developer productivity with Hatica. Schedule your free Hatica demo today!

Subscribe to Hatica's blog

Get bi-weekly insights straight to your inbox

Share this article:
Table of Contents
  • What are the Reasons Behind Low Developer Productivity?
  • 1. A Clogged SDLC and Inefficient Dev Workflows 
  • 2. Alignment Challenges: Are Your Business and Engineering Teams On the Same Page? 
  • 3. Overflowing Non-Core Tasks 
  • 4. Context Switching: High-Cost, High-Impact Productivity Killer 
  • Parting Note 

Ready to dive in? Start your free trial today

Overview dashboard from Hatica