This morning I had the opportunity to chat with software engineers and data scientists at the AI Dev World Conference on a topic I just happen to be v...
“Why aren’t we moving faster?”
It’s a question, sometimes with an expletive attached, that rings in lots of leaders’ ears. The old engineering joke used to be: Faster, cheaper, better—pick two.
But in a world eaten by software, where anything the business wants goes through engineering, there’s no choice at all. Faster is new master.
Usually in engineering, we have a readymade answer: “Because we need more people.”
But how do we know? Or if we know, how do we make the case? Appeals for hiring budget can be like appeals in a court of law. It’s not what you know, it’s what you can prove. Even when the evidence seems to be everywhere—bleary-eyed people glued to monitors, the parking lot packed on Saturdays—our cases are circumstantial. Emotional testimony, built on stories of heroic effort.
The key is to be able to show that we’re tapped out...that every single able-bodied person over the age of twelve is quantifiably, undeniably, indisputably at peak capacity.
This isn’t a wind-up in support of “hours worked” or other ancient measures of effort. What’s needed is a way to understand how evenly (or not) work is distributed across people.
In the world of engineering, the 80/20 rule (the Pareto principle, if you’re showing off) has been a longstanding guide for optimizing effort. Agile’s DSDM, to take one example, suggests that 80 percent of an app can be built in 20 percent of the time it would take to finish 100 percent of the app. We use the 80/20 rule as a means for understanding workload balance. Specifically, we want to understand what percent of the available team capacity is involved in delivering 80 percent of the work.
This begs an obvious question: How do you calculate any one person’s work capacity?
We rely on a signal we call Issue Days.* The concept is simple. To calculate Issue Days, we first look at the total number of items a person has worked. We then take that total work and multiply it by that person’s average Cycle Time for those issues. That is, total issues worked, multiplied by the average time it took to complete each, as measured in days from start to finish.
So, if for a given period I worked 16 issues, and it took me an average of 11 days to complete each issue, my Issue Days would be 176.
Issue Days is essentially a proxy for workload—importantly, one that’s based on actuals, not estimates. With Issue Days for each person, we can then begin to see how workload is distributed across a team, or a department, or even the engineering organization as a whole.
This is where the 80/20 rule comes in. Let’s assume a team with ten people. We might see that for a given period, their work was distributed as follows:
We see that six of the ten team members, 60 percent, accounted for 80 percent of the work in the period.
To convert this into a signal we call Workload Balance, we divide that 60 percent by 0.8. Why? Because we’re using the 80/20 rule, and because we want an even distribution of work to score as 100 percent. If eight of ten people on a team are responsible for 80 percent of its work—i.e., a perfect distribution according to the 80/20 rule—then we want to reflect their Workload Balance as 100 percent [(8÷10)÷0.8], not 80 percent. The latter would look a little strange as a perfect score…
Back to the example above. This team has a Workload Balance of 75 percent: (6÷10)÷0.8. Not bad, but still with ample room for a better balance of work across the team.
Knowing and being able to show a team’s Workload Balance makes it possible to quantify the case for more people. There’s just one other ingredient required: a view into how well a team is keeping up with work demand. We measure this through Backlog Change, which simply shows the percent change in open issues for a given period. A negative figure means more issues were closed than opened; a positive figure means more issues opened than closed.
A team with a Workload Balance of 90 percent, and a Backlog Change of 22 percent, has a strong case for more people. (Or less work!) These two scores together show that the team is sharing the effort evenly across people, but is still having trouble keeping up with demand. A high Workload Balance score also suggests the team can be entrusted with more people. They’re doing a good job of maximizing the people they already have.
If Workload Balance is low and Backlog Change is flat or negative, the signals are telling us we need more work, or that some part of the team could be reallocated, or both.
There are other advantages to knowing your Workload Balance. It’s a means of seeing who might be underutilized, and who might be at risk for burnout. Workload Balance may reveal not just imbalances in team size, but also in roles and experience. For example, maybe a team is regularly being given more difficult work that isn’t as easily shared with the more junior resources.
But maybe the biggest advantage is an unemotional, quantified hiring case. When a budget holder asks you to document, demonstrate or otherwise prove the need for more people? You can.
[*] We happen to use Jira, where each unit of work is called an issue, hence the signal name. “Issue” in this context should be read simply as any unit of work as captured in your work/ticket system.
Meet Andrew. He’s our Director of Backend Engineering and is a member of Team Bolt ⚡️ who is currently working on buildi...
Meet Mike. He’s a Platform Operations Engineer here a Pinpoint and member of Team Bolt ⚡️ . who is currently working on ...