Working with Queue and Stack people

My colleague and friend Clinton told me once about himself (I’m paraphrasing): “I’m a stack, not a queue”.

This is not a post about queue and stack data structures, but about people and their behavior biases toward task management. I’m focusing this discussion on tasks that represent defects to be fixed, quick-win feature additions, and other short-term tasks. These are tasks that can probably be completed in a few hours to a few days.

I’ll describe these biases and how they manifest for different types of people in their emotional and behavioral responses to incoming tasks. I’ll also describe how these different responses can create conflict on teams, with a goal toward helping managers and colleagues understand the behavior, how to work well with people of different task management bias, and how to create conditions for success for these different types. My audience comprises coworkers, managers, and project managers on software teams, although this probably applies to other fields.

Until Clinton described himself as more of a stack, I hadn’t thought of people’s dispositions toward task management in that way. Importantly, and I hope obviously, these are not rigid slots into which people fall; rather, they’re biases or defaults, and people distribute across the spectrum.

We can use these biases as a lens through which to view how new tasks cause joy and pain for queue and stack people.

Disclosures

1. I consider myself a queue person, though certainly for much of my career as a programmer I treated all production bugs as stop-the-world events
2. The behaviors described here are amplified for clarity

Queues and Stacks

When you’re standing in line to order coffee… that’s a queue: first come, first served. If you have a long, narrow, single-door, multi-car garage that fits a single-file line of cars… that’s a stack: last in, first out.

In the context of task management behaviors, queue and stack people respond differently to a new incoming task that meets the criteria described above (think: fast food, not catered wedding), both emotionally and behaviorally.

When a new task comes in, a queue person prefers to quickly prioritize and position the task in the list of work to be done, or leave it unprioritized and put it at the end of the list for future prioritization and eventual completion. In terms of emotional response, a queue person is generally comfortable leaving new work undone.

A stack person, on the other hand, treats incoming tasks differently. Instead, new tasks must be dealt with swiftly. A stack person is generally uncomfortable — sometimes greatly so — leaving new work undone.

We all seek joy and avoid pain; let’s look at how that plays out in the context of queue and stack people at work.

Shared motivations

It’s obvious, but probably bears repeating: very few people actually enjoy a constant barrage of critical production bugs. Some might thrive in this environment, but they’re outliers.

By and large, most people derive joy by delivering high value, not fixing broken things under pressure. Both queues and stacks share this positive motivation. Delivering value by executing on a prioritized list motivates queues and stacks alike.

Queue Motivations

Queue people are pained by seemingly important tasks that languish for months or years. They want to see important tasks get their fair shake and are frustrated when other tasks “butt in line”, especially at the front. Constantly shifting priorities infuriate queue people. Queue people are generally pained, not pleasured, by firefighting emergencies.

Stack Motivations

Most of the above motivations apply to stack people, as well. The differences are that stack people are either particularly pained by, or derive significant joy from completing, new tasks that, as I wrote earlier, represent defect or quick-win. For the former, they’d rather alleviate the pain of the new task as quickly as possible, so that they can get back to deriving joy from whatever they were working on. In a bad case, this person gets hit with multiple new tasks, and spends hours or days trying to end the pain.

For the latter type, new tasks often represent a quick opportunity to accomplish something. Whereas a queue person might prefer to hold off on the quick win in favor of completing the currently highest-priority task, a stack person is more willing to stop the current work and get the quick win because it’s incredibly satisfying (I suspect there’s a chemical component… adrenaline rush, for example).

How queues frustrate stacks

Queue people frustrate stack people when a queue person doesn’t drop what they’re doing to attend to some new problem. It plays out like this:

Stack: “Hey, we have a problem. We should not have this problem.”

Queue person responds by trying to determine the urgency of this problem. Is anyone dying or at risk of death or imminent harm? What is the consequence of not working on this problem right now? Upon determining life and liberty are not at risk: “OK. File an issue and we’ll prioritize it and deal with it when it’s appropriate to do so”

Stack: “But it’s a problem now! It’ll just take a few minutes to fix it. We shouldn’t let these kinds of broken windows stay broken. Paint over the graffiti. Avoid the technical debt! We’re better than this! Be brave! Be bold!”

Another way this might play out is in the arrival of a quick-win opportunity.

Stack: “Hey, check out this awesome thing we can do to increase performance by 25%!”

Queue person knows that any performance boost is welcome, but it’s not really urgent right now and so is willing to backlog it. Queue might also be thinking about all the implications of the fix, the testing effort, and so forth. That kind of trepidation is particularly relevant in less mature, more brittle production environments where the risk of deployment is higher. “That’s great! It’s not urgent right now but it’s great you’ve identified a win. Let’s talk about it next sprint”

Stack: “But I can fix it in a few hours!”

Stacks can perceive queues as lazy, risk-averse, timid or even cowardly, unresponsive, slow, and unconcerned about the present, sometimes failing to seize opportunity, with their eyes so far down the road that they don’t see the bear that just jumped out in front of them.

How stacks frustrate queues

Stack people frustrate queue people when a stack person drops what they’re doing to attend to some new problem, especially when that problem is not urgent.

Queue: “Hey, we have a problem. We should not have this problem. But it’s not urgent, so I filed an issue and we’ll prioritize it during our next team planning session.”

Stack person looks at the new task, knows exactly how to fix it, knows it won’t take long. Stack person responds several hours later: “I fixed that problem.”

Queue person is now conflicted, because the problem being gone is certainly a good thing. However, it came at the expense of whatever the stack was currently tasked with, and that task was probably agreed on by the team as high priority. In this case, the queue is frustrated because a lower priority task was worked instead of a high priority one.

Another form of conflict arises when a stack delivers a quick-win, especially when it benefits the queue coworker. In this case, the queue is obviously grateful for the stack’s work, but knows it came at the expense of something else. The queue person also might feel envious or left out because he had hoped to work on that task when the time was right.

Another way stacks frustrate queues is by pestering the queue to deal with an issue that the queue has decided is not a priority.

Queues can perceive stacks as unfocused, reckless, too eager to please, wanna-be heroes who focus on short-term tasks at the expense of long-term goals. Stacks can also be perceived as miracle workers.

Implications for teams

Knowing that a coworker has a different bias toward task management is probably the first step toward developing empathy for that person’s response to new tasks.

Queue people need to understand that a new task, for a stack person, represents considerable potential pain or joy. For tasks that represent pain that must be immediately alleviated, it’s not that the stack feels I must fix it; rather, this must be fixed. The task is painful not because the stack must fix it, but because it exists, period. In software, this typically manifests as bugs in production or as a new-found opportunity to improve some broken or suboptimal thing. When that production bug comes in, the pain is particularly acute when there’s simply no one else to solve the problem. A stack person will have a hard time doing anything else until they fix it. Regardless of whether the pain is emotional or  physical (pit in the stomach, headache, etc), it’s very much real. A well-staffed, diverse team is a great defense here. If the stack person knows it’s Johnny’s week for triaging production bugs, that’s probably good enough for this problem to not be such a painful distraction.

Stack people need to understand that a new task, for a queue person, will put their current prioritized task at risk if they drop it and attend to the new thing. Stacks must understand that queues derive joy from working on prioritized, long-term goals and are pained by any new thing that interferes with its completion.

What are teams to do when staffed with a mix of these personality types? How does a team deal with the potential conflict?

Some ideas:

• Building large blocks of time, uninterrupted by meetings, into team members’ schedules
  • This is especially helpful for giving stack people enough time to get so far into a challenging problem that a new task’s potential pain/joy is less than the joy derived from solving the current challenge
  • Likewise, it benefits queue people by giving enough time to make good progress on tasks that take days/weeks to complete
• Rotating bug triage and collectively sharing bug fixing
• A separate, rotating team of people whose purpose is to respond quickly to new tasks
• Bug reporting mechanisms that don’t immediately put bugs on the team’s windshield (i.e. goes to manager or support team first for classification, prioritization, even assignment)
• Building time into software schedules for fixing broken windows / paying down technical debt
  • These are all helpful for stack people who either must alleviate the pain of new tasks and who derive joy from quick-win improvements
• Strong team leads whose priorities don’t shift with the wind
  • This is especially helpful for queue people pained by constantly being bandied about
• Having these different working styles pair on quick-win tasks can help queues alleviate their frustration at a stack who otherwise would’ve done the work on his own; this pairing also helps the stack get insight into what the queue considers valuable
• Also for quick-win tasks, when possible seek alignment with longer-term goals. It’s often easier for a team to absorb the absence of a stack who spends a few hours or a day getting a quick win if they know it will pay off on something that is already prioritized
• Delegating both urgent bugs and quick wins to junior staff when possible, or at least as triage. This helps develop talent and trust, helps keep queue people focused and stack people not driven mad.
• Driving down the risk of deploying quick wins.

The subject of heroics deserves closer inspection. A toxic work culture encourages and even rewards team members for prolonged or frequent engagement in the unhealthy behavior of “going the extra mile”. Tally up the extra nights and weekends worked over the course of months, and you’ll get a quick gauge of this in a team. Occasionally this is necessary, but when it’s a pattern, it’s cancerous. You see these patterns in teams that are either constantly fighting production fires or trying to get new features out the door ASAP for deadlines real and imagined. See http://burnout.io/ for help.

Organizations should discourage this heroic behavior. But there’s an implication here especially for stacks. Clinton tells me about himself, “I love being the hero.” I do not believe this means “teams should encourage unhealthy behavior to give others an opportunity to be heroes”, and I don’t think Clinton meant that, either. For stacks in particular, wiggle room is helpful and motivating as long as it doesn’t turn into a pattern of disruption. For example, if a new quick-win task comes in that a stack is psyched about, and which delivers value in some way to the team / product / customer, healthy teams should build enough wiggle room in the schedule that, in consultation with the team / project manager, the stack is cleared to work on that quick win. High fives all around and back to business.

The risk here is that it becomes pattern or disruptive. High-trust, high-communication team culture is essential for striking the balance. For example, I need to be able to say to a stack, “I know you’re jazzed about XYZ that just came in, but we really need to ship the feature we’ve been working on for a few days. After that, we’ll revisit XYZ.” The stack needs to trust that XYZ will not fall into a hole, too. Another risk here is that too much of this — especially with praise for these types of tasks that is not equal to praise for daily gittin-it-done, can pressure queues to start engaging in more quick-win seeking because that’s where the rewards lie.

Simple structure may be the best guardrail here. For example, allocate a certain number of hours or points per sprint / time period for quick win features and paying down technical debt.

In short, provide wiggle room for quick wins but tread carefully and warily and monitor impact on the team.

All of these will probably seem obvious. I think it’s interesting to look at them from the perspective how they help address the needs of queue and stack people.

Implications for managers

Managers must be aware of these different task biases and how they motivate people, but especially when it comes to performance reviews, ratings, incentives and reward structures, and so forth. A manager who generally tends to reward heroics and quick completion of new tasks, or who doesn’t empower people to say “No” to incoming tasks, for example, puts queue people at a  disadvantage.

Likewise, managers must understand for stack people just how debilitating the effect on morale and job satisfaction can be if the environment is one where all things must be dropped to deal with every production bug. Whereas some are content with backlogging noncritical bugs, a manager who expects that all production bugs get addressed immediately will wear the team out in no time, and the stacks will likely bear the brunt because they are traditionally the ones hailed as the go-to fix it people. Just because a person frequently saves the day doesn’t mean they like it or that it creates an environment in which they want to work.

If job satisfaction is a top predictor of a high-performing team, then managers will do well to understand the motivations of queue and stack people and how to create conditions for both types to be comfortable and successful.

Thanks

Special thanks to Clinton Dreisbach for critical feedback.