4 ms·

I was once put in exactly this position. Our IT Manager was fired and I was put in charge of about a dozen sysadmin and helpdesk people. They had over 130 open

I was once put in exactly this position. Our IT Manager was fired and I was put in charge of about a dozen sysadmin and helpdesk people. They had over 130 open tickets and claimed to be too busy to do anything. Bear in mind I knew little about infrastructure (I was an applications dev and tech lead who had become a 3rd line application support leader). I spent a month doing triage, and sorting out their process (they were doing triage, but gave it to a relatively weak member of staff who couldn't spot patterns or kill off tickets effectively). The number came down to 30, and the team was far more focussed. I also got to see who was helping and who wasn't, and sacked another member of staff who bullied less knowledgeable members of the team (while doing literally nothing but spreading FUD). The point (obvious to anyone who's read The Goal, which I hadat that point) is that the graph doesn't tell you jack about what's going on. You have to go and look. The incoming tickets pipe was the first place to go because it's the simplest firehose to plug. That gave people space to get off the ticket treadmill and work on longer term tech debt.

sandal 11y ago
That's absolutely right... on its own, the graph tells you nothing at all. However, if you know for sure that there are tough problems going on (related to growth, limited dev capacity, code quality issues, etc), then having well-functioning planning tools can be useful. A tracker that looks like this, and the process that leads to this trend is a problem that is worth fixing in that situation. So that's what my follow up essay will cover. How to put a very simple process in place that gets you back to the point of reliable project prioritization and measurements, without putting in a large time investment. Because I think even smart, capable teams can end up in this situation due to various forms of external pressures, knowing how to dig out is pretty important, and ideally long before it hits the tipping point I had been at when I started helping with this particular project.
Spooky23 11y ago
Support orgs and networking groups are really vulnerable to this kind of bullshit when the line management is too comfy or someone clueless or inexperienced is put in charge without adult supervision. One place a support manager told me that he couldn't keep his indcident queue under control without 10-15 more people. The tickets weren't being assigned and the staff was doing nothing. (The manager dude was trying to get people promoted and gumming up the works for ticket assignment) Another case a network org had a 20 business day turnaround time for trivial firewall changes. The average request took 40 calendar days, and a small sampling we did showed that many had to be reopened several times -- in one case a DBA's request took ~200 days from open to close.

sandal 11y ago

That's absolutely right... on its own, the graph tells you nothing at all. However, if you know for sure that there are tough problems going on (related to growth, limited dev capacity, code quality issues, etc), then having well-functioning planning tools can be useful. A tracker that looks like this, and the process that leads to this trend is a problem that is worth fixing in that situation. So that's what my follow up essay will cover. How to put a very simple process in place that gets you back to the point of reliable project prioritization and measurements, without putting in a large time investment. Because I think even smart, capable teams can end up in this situation due to various forms of external pressures, knowing how to dig out is pretty important, and ideally long before it hits the tipping point I had been at when I started helping with this particular project.

Spooky23 11y ago

Support orgs and networking groups are really vulnerable to this kind of bullshit when the line management is too comfy or someone clueless or inexperienced is put in charge without adult supervision. One place a support manager told me that he couldn't keep his indcident queue under control without 10-15 more people. The tickets weren't being assigned and the staff was doing nothing. (The manager dude was trying to get people promoted and gumming up the works for ticket assignment) Another case a network org had a 20 business day turnaround time for trivial firewall changes. The average request took 40 calendar days, and a small sampling we did showed that many had to be reopened several times -- in one case a DBA's request took ~200 days from open to close.