Navigating the Developer Productivity Crisis: Burnouts, Context Switching, and More
This article discusses the reasons behind low developer productivity in tech and ways to increase productivity through engineering analytics platforms.
Join the DZone community and get the full member experience.Join For Free
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.
Engineering hirings are a mess despite an uptick in the average software developer's salary. 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. Yet, while nine out of ten engineering managers struggle with low engineering efficiency, they just don't know how to resolve it, despite humongous willingness.
What Kills Developer Productivity? All Questions Answered
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. Developers often face imposter syndrome- making them their 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 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 five to ten hours a week and is the third top reason for developer frustration globally.
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. Unfortunately, both teams bring different expertise and goals to the table, and prioritizing which ones to focus on first becomes a bone of contention. Moreover, the two teams often work with completely disparate mindsets: working independently, splitting attention, and, thus, deviating from the core product vision.
Even sometimes, engineering managers cannot articulate their mission well to the techies and how their work fits into the bigger picture. As a result, 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 indefinitely shelve your project's release- 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.
Overflowing Non-Core Tasks
In an ideal world, a software engineer's primary job includes writing code and running software. But, 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, the engineers must also lead the Ops: service stability, fix bugs that escaped QA, develop productivity tools and CI/CD workflows, and manage 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. In addition, constant hiring calls from the top tier leave most engineers alienated from their core coding duties, causing frustration and even chronic developer burnout.
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 ten minutes, they unwillingly extend to an hour. Attending meetings isn't an issue for others, but their unsustainable daily distribution 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 two-hour work session per day.
Low developer productivity might snowball into a high product backlog, low quality, and difficult customer retention- negatively affecting the brand consensus. However, productivity is not just about filling checkboxes every week; 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 by 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. An engineering analytics tool offers managers visibility into their team's work activities so meetings become more data-driven and work highly productive.
Qualitatively speaking, developers must also retain some time dedicated to growth and innovation from their schedule. The practice helps create more well-rounded developers and increase personal profiles, 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.
Published at DZone with permission of Avya Chaudhary. See the original article here.
Opinions expressed by DZone contributors are their own.