"Calm down, it's not that urgent," my manager told me. She had assigned a task due two days later that required a subtask: creating a new piece of software.
The task and subtask were small, and per the company's structure I had assigned the subtask to an IT group we'll call The Misc. Dept. I'd also given it the high-priority status of Blocker, though it actually wasn't one. My line manager told me to lower the status in urgency.
My manager was very good at managing emotions and team dynamics, and she had good intentions in calming me down from the stress she believed I was under. However, I had set it to Blocker not because I was panicked, but because this was necessary to get the subtask done anytime soon. One of the company's big failings was that the managers were unaware of workflow problems with The Misc. Dept. that complicated even the simple task of prioritizing accurately.
But under pressure with other tasks, reluctant to contradict my manager, and because it would take precious time to explain otherwise, I lowered the status of the subtask to a level she suggested as more apt -- though I could've anticipated the outcome. I was fully aware that The Misc. Dept. prioritized its tasks by status only, the extent of its workload, and its permanent understaffing.
Stuck in the past
The Misc. Dept. was one of the internal service groups on which the product departments relied -- in fact, it was the most important group. Our company had grown tremendously over the past couple of years, adding several million customers and about a dozen product departments. Yet The Misc. Dept. had not changed.
Despite the company's growth, management had not adapted internal workflows and performance measurements. Instead, a constant sequence of restructurings about every half year only changed lines of reporting and introduced more middle managers by the pile. Staff members regarded this as mere paper exercise, ignoring it where they could -- a severe case of change fatigue.
As was done before the explosive growth, tasks for The Misc. Dept. were queued in a ticket management system. Overall performance was simply measured in financial earnings for product departments, meaning there was no performance indicator for The Misc. Dept. that could've given rise to concern or consequences. This all led to a permanent sense of urgency among its team members. Due to the resulting stress, at any given time about a third of them were ill.
Other departments were affected by this lag. Thus, whoever gave a task to The Misc. Dept. automatically set its status to Blocker. Normally, Blocker was reserved for tasks that, if not done immediately, would lead to massive losses of money -- blocking the business and its customers.
But with this team it simply meant: Please, I hope this task gets completed while I still work for this company. Any other status meant it'd be permanently lost in a dark hole.
Two hours after I lowered the status of said subtask, I received an email from The Misc. Dept.'s tech lead informing me it had been prioritized and the wait time until delivery had been calculated. Based on estimates of all tasks in front of it and expecting no sick leaves, the subtask would be completed in two years, four months, five days, and four hours.
Naturally I had to inform my line manager because now it was obvious there was no hope of fulfilling my task due two days later while simultaneously sticking to her recommendation regarding the status of the subtask. She was bewildered and told me to change the status back to Blocker.
The subtask was delivered five days later. To complete it, a tech from The Misc. Dept. had gotten his application for leave canceled. He'd been able to squeeze it in while waiting for another Blocker task's compile cycle to complete.
Shortly thereafter, The Misc. Dept.'s tech lead introduced further measures to prioritize tasks and get a grip on the queue and on requesters' impatient checks: a Scrum sprint planning meeting. There, everybody who had created a task that stood a chance of being fulfilled anytime soon had to mutually discuss and coordinate preference as Scrum Product Owners -- no matter the size of the task.
However, this only increased pressure for the product teams. And after several middle managers fell severely ill due to high stress, workflows and performance indicators were finally identified as problematic and changed. However, adding staff ranked low among priorities for executives seeking to shore up The Misc. Dept. -- because it wasn't a profit center.
Take it from someone who's been there: Don't wait to make workflow changes until stress grows larger than staff can handle. Crew members are likely to grit their teeth and try to bear the load -- for a while anyway. If your company grows, adapt workflows and performance indicators accordingly. And make sure any internal support department has enough resources to do their jobs.