The One Where Team Workload Helped an Under-Served Team Advocate for Itself

Previously on Tales From a Journey Around Metrics

We last interrupted our Managing Metrics episodes by going over the value of measuring Team Workload. Before that, in Episode 7 Mojtaba recounted a team increasing its autonomy with aid of metrics.

An Under-Served Team

At the last organization, we had an “Ops” team that was critically under-served. It was a small team of very dedicated folks that jumped from fire to fire and helped several teams. They were on-call for some things and also the customer point of contact for some services. They were chronically busy, and burn-out was a real threat. The team was just too busy to try and advocate for itself effectively.

When executives questioned them on their missed deadlines or un-improving processes, they would cite all the workload and the myriad interruptions and surprises, get a sympathetic reply - and then they would go back to their ways.

Make Work Visible

To get out of the vicious cycle of fire-fighting, the team began by “making work visible” (a tenant of the Theory of Constraints). There is no hope of a team trying to quantitatively articulate its workload and pain-points, if its work is not visible. Example of ‘invisible’ work and how they made it ‘visible’:

• Slack message of an adjacent team that turned into a long thread and investigation of a problem: make it a JIRA issue
• A manager/director asking for work that takes more than a few minutes: make it a JIRA issue
• Question and comment in a document that turned into hours of work to answer: make it a JIRA issue
• Customer phone calls on the phone that takes hours to resolve: make it a JIRA issue
• An on-call event that took a while to resolve: make it a JIRA issue

The above requires the team to create what is sometimes called an ‘in-take’ process: a process by which a team agrees on what work is worth creating (JIRA) issues for and what can be simply ‘overhead’. Different teams can come up with their own rules, but the goal remains the same: to track workload that the team deems significant enough to track.

Simple Workload Tracking

Once the team started to follow an intake process, it was able to compile some high level metrics around “number of JIRA issues by Issue Type” where, for this particular team, Issue Type constituted the source of the workload (internal, support team, customers directly, sales, development, cloud on-call, etc.)

It was a very crude measure of its workload because different JIRA tickets do not have the same weight. A 20-minute phone call with a customer was not the same as several hours spent debugging an operational script, but it was a start!

On the next episode

Tune in next episode to see how even this overly simplistic Team Workload tracking helped the team begin to dig itself out of a vicious cycle.

[ Guest post from Mojtaba Hosseini ]