Tuesday, June 11, 2019

As Soon As Possible and Shifts in Priority

Managing Priorities


I have been lucky so far in my career to rarely encounter unreasonable deadlines. Every so often something will force me to weather the storm and bear the pressure as the clock winds down. Some deadlines are soft and self-imposed (e.g. hoping to deliver on a new feature by next month). Others are firmer and come from promises made to clients, or fixed dates mandated by third parties.

If you've been in the same position for a few years, it's likely that you balance your time between developing new software and features and supporting existing products with troubleshooting, bug fixes, and other software maintenance. This, of course, means making choices about which tasks to take on first. The act of prioritizing between live issues and valuable new features is by no means trivial. Simply spending the time to analyze the potential impact, costs, and benefits of each task can take as much time as a simple bug fix. Even after events have played out, it can be difficult to evaluate whether you made the correct choice.

As a team leader, I am also tasked with building and maintaining an effective team. Part of that responsibility is prioritizing and assigning work for the members of my team. This includes communicating project status within my own team, and answering to those in other departments, who also have their own requests and expectations.


As Soon As Possible


Every so often, someone will ask for something "as soon as possible" (ASAP!). This is a slightly less demanding way of saying that they want it right now! This can be understandable if it happens rarely. Every once and a while deadlines sneak up or catch a person off guard -- the unexpected may happen and needs to be dealt with quickly. The problem comes when ASAP is used too often or by too many parties all at the same time. As the villain, Syndrome, from The Incredibles says, "when everyone's super, no one will be."

A big problem with ASAP is that there is an implied caveat that comes with its use. ASAP generally means as soon as possible without causing unreasonable harm. The problem with this caveat is that everyone has their own definition of what unreasonable harm might look like.

This kind of request is practically guaranteed to cause friction between the two parties, with great potential for tension and conflict. The person requesting help may see their own problem as far more important than a mild interruption to the other party, while the person whose time and attention is being requested is likely to see the request as a significant imposition on their already busy schedule.

This implied caveat is also dangerous due to its implications towards prioritizing two simultaneous ASAP requests. Not causing unreasonable harm also implies not interfering with something that is of greater importance or higher priority. Unfortunately, when I see two ASAP requests without much context, they can both appear to have equal status. This conflict cannot be resolved without gathering more information beyond, "because I said so." The burden of sorting out priorities often falls to the person who's attention is already stretched thin.

Interrupting a focused worker with an unexpected urgent task can have terrible results. This breaks their flow, the ramifications of which are not to be underestimated. It also prevents them from whatever they were working on. Presumably, a task at the top of their to do list because it is a high priority. In addition to interfering with the task in progress, unexpected urgency and stress can impact the quality of work on the new task as well. This often leads to rushed work, cut corners, and overlooked errors that might otherwise be avoided.


Setting Deadlines


One method to avoid the perils of ASAP requests is to set clear deadlines. This allows the requested party extra flexibility to fit the task into their schedule where it makes sense and provide feedback or ask for assistance if they feel the deadline will be missed.

Deadlines seem a reasonable suggestion when there is a clear motivation for a specific delivery time and enough lead time to allow for flexibility. They are not always reasonable when the required delivery time is unclear or is obviously needed sooner than can allow for the flexibility of lead time. It's not reasonable to set a deadline for the ambulance to arrive when someone has been severely injured in a car accident. This is the truest definition of ASAP.

Effectively setting a deadline is a difficult problem. It is much simpler to set a deadline when a project dependency has a clearly defined deadline already. For example, task A must be completed before task B and task B is due three weeks from today. If task B is estimated at one week, then task A must be completed no later than two weeks from today. However, if task B is simply an interesting new feature, then there is no compelling reason to set a hard deadline for task A. Yes, we want this, but we don't necessarily need it "right now". Setting a deadline In this example, and for many others, becomes difficult.

When missing a deadline does not have immediate negative effects, prefer a soft deadline or target date. Distinguishing between hard and soft deadlines helps to express a rough prioritization of tasks, allowing for flexibility to accommodate unexpected changes and requirements. When it becomes apparent that a soft deadline might be missed, there is an opportunity for evaluation. Perhaps the original project estimates were too optimistic, or a different priority interfered with the schedule. This gives all interested parties an opportunity to observe the situation without creating undue pressure and interfering with focused work

Team Building


Teams are emotional beasts. We sometimes like to think of our coworkers like cogs in a machine, with each piece working together to produce the functions of the whole. While this might be a nice analogy, the truth is usually far messier. Each team member is a human with emotions and needs. Some days team members show up in a grumpy mood or become distracted by the many details of their complex lives. Just keeping team members satisfied, focused, and productive can be a full time job and requires not just technical expertise, but excellent social skills and awareness. Like it or not, the morale of the team is strongly connected to the quality of work they will produce.

A leader's actions can make or break effective teams. Choosing to interrupt a project already in progress signals that a deeply engrossed team member's work is not really that important. Choosing to do so frequently or reversing decisions every other day can kill team morale and compromise the team's perception of their leader. Think hard before reassigning an urgent task to someone who is already engaged and focused. There are certainly circumstances that call for an urgent shift in priorities, but this should be exceedingly rare.

The words we choose are often just as important. There are usually many ways to phrase something. Your choice of words, tone, and even medium (e.g. email, phone, in person) can send important signals. Choosing appropriate words and methods of communication can build rapport and improve morale. Handing down ever-changing edicts from above can erode even the best of teams.

My recommendation is to avoid ASAP like the plague. In the rare case where priorities must shift urgently, take the time to communicate with your team Choose appropriate words to frame the situation and help your team understand the rationale for the change. Discuss this in person, if possible. If you are not able to address questions and provide reasonable feedback, the minds of your team may begin to imagine things are more dire than they truly are. Use tact and draw on all of your social skills to reassure the team that this is a rare emergency and the time has come to pull together, not fall apart.



Do you have any stories of an ASAP gone wrong? Can you think of a time where you successfully navigated an unexpected shift in priorities? What happened? Tell me your story in the comments.

Cheers,

Joshua Ganes


No comments:

Post a Comment