HN Explorer

Ask HN: How to quantify that a team is overworked

15 points by ccostes ↗ HN
As the title says, my team has way too much on our plate and I am trying to make the case for hiring another developer, but I'm struggling to find a way to quantify the problem for management.

Any advice or strategies that have worked well for others?

9 comments

[ 3.1 ms ] story [ 31.2 ms ] thread
petervandijck
Some relevant numbers could be:

- size of backlog

- overtime

- time new requests spend in queue

- cost of delays to the business

flukus
A lot of those sound like good proxies for technical debt too.
spoonie
If you're into it, do an Agile/XP planning & estimation workflow. You can show that you are being requested to do 30 points of work per week but only achieving 20 points.
ccostes
Our development process is currently fairly unstructured. I think this would be a good way to get a better picture of how we're spending our time, but I'm worried about introducing too much overhead.
svisser
Would adding structure help in managing the work better?

It can become difficult to convince management of hiring (paying) more people when there are improvements that should be made first.

FullMtlAlcoholc
My team for essentially solved this problem by using a time tracker. I highly recommend trying out toggl
svisser
- Determine who you need to convince on this matter

- Find out what metrics they care about (time lost, money lost, potentially employees lost, clients lost).

- Formulate your proposal in a way that emphasises how those metrics will improve by hiring more developers.

brudgers
One simple way to measure it is with a feedback loop.

For example if the company starts paying all developers time and a half for hours beyond forty per week then it is practical to measure the amount that the developers work in dollars/pounds/pesos and compare that measurement to the dollars/pounds/pesos hiring another developer would require.

liquidcool
I give a talk on programmer productivity a few times a year, and measuring it (related to this) is very hard. That said, there are a few things worth keeping an eye on.

The biggest is turnover. Are people quitting because of workload or general dissatisfaction? Turnover is crazy expensive (I should know, I'm in staffing.)

You have others related to technical debt, which is what you get when people are overworked.

- Estimate accuracy (estimate vs. actual). Are you increasingly surprised at how long things take?

- average hours per issue (not great, but worth keeping an eye on)

This assumes you've got good practices like issue tracking, estimates, etc.