Software development teams have been on a journey over the last several years to improve productivity. Whether that’s by cutting down on the time spent coding by introducing AI-powered coding assistants or implementing collaboration tools, it’s clear that teams are on a mission to be more productive.
However, that drive for productivity may actually be making things worse by introducing more “gray work” into their processes. Maya Palfreyman, product marketing director at Quickbase, defines gray work as anything that gets in the way of your day-to-day job, like chasing down information or people.
“It’s all the little stuff that you might think takes five or 10 minutes here and there, but you realize as you look at the day or the week that it all adds up and you’ve spent a lot of time doing what you might consider not so meaningful to the impact you’re trying to drive in your job,” she said on a recent episode of the SD Times podcast.
Palfreyman leads the company’s research on gray work, and in the recently released Quickbase Gray Work Index, it was discovered that 59% of the 2000+ respondents spend more than 11 hours per week chasing down information from different tools, an increase from 45% in 2024.
And it’s not just time spent chasing down information in tools that contributes to gray work; it’s also the time spent waiting on information. “You’re sitting there wanting to move on to the next step, but you need to see where the progress is, and you’re waiting on that person to respond,” she said.
The effect on individual developers
This wasted time doesn’t just lead to delays, it can also impact developer wellbeing because it’s stressful knowing you have work to do, but not actually being able to do that work because you’re waiting on information.
According to Palfreyman, it can lead to not enjoying the work as much as you might have, potentially leading to burnout.
“And at the end of the day, you’re just not getting as much done because you’re having to kind of go through all these gray. When I think about gray work, that’s not what I’m measured on. I’m measured on the impact that I drive.”
Factoring gray work into planning
While it would be great to eliminate gray work entirely, that’s not the world we live in today. Therefore, managers should really be factoring this into their planning cycle and how it impacts deadlines and budgets.
If workers are spending hours of their day on gray work rather than development work, that’s going to lead to delays.
“When you are making commitments during planning, it is important to see, is there gray work that is going to slow us down? Is there gray work that we can potentially eliminate to help meet our goals in a better way? I think that it tends to catch a lot of teams by surprise.”
Key takeaways from the Gray Work Index
This is the third year that Quickbase conducted research on gray work, and looking at the trends year-over-year, workers are actually getting less productive and tool investment is increasing.
“That is the biggest takeaway for me, because something doesn’t add up,” said Palfreyman. “The fact that these lines are moving in different directions is pretty interesting to me.”
The researchers also found that there’s been consistent themes around data fragmentation and silos over the years. Organizations are interested in eliminating these challenges, but are mainly just doing so by buying more tools to try to solve the problem.
“These are hard conversations, and these are big projects that need to be taken on in terms of consolidating software, thinking about how things connect in the right way. But I am hopeful. Each year I love doing this research to see what else we can learn,” said Palfreyman.
The post The impact of gray work on software development appeared first on SD Times.
Source: Read MoreÂ
