The intensity continues…
Posted by Josh | Posted in GTD, The Rookie DBA | Posted on 03-19-2010
Tags: GTD, rookie DBA, Stress
5
So as I previously wrote, the new gig is turning out to be a little bit more intense than I expected. And while I’d love to say that I have it all under control, that, in truth, would be a flat out lie.
The last few days I’ve done my best to keep track of how many interruptions I get on a given day; today I lost count at over ten. Ten in eight hours of work! That means I averaged more than one interruption per hour. Of all of them, only one was actually worthy of breaking my concentration. The rest were either simple questions or related to non-emergency work, such as ongoing testing or requests in queue.
I have to say, I’m at a loss how to put an end to these, or at the very least, reduce their volume. I’ve tried gently redirecting people to send the team an e-mail, forcefully redirecting them (which is usually met with a resentful glare or a “but it will only take 30 seconds”), even putting on my headphones and doing my damndest to ignore anyone who walks up to my desk. It’s gotten so bad that my senior DBA has called a SWAT meeting next month with all of my unit’s team leads to discuss how this situation can be rectified. Without something on the side of a drastic change, my team is going to have a really hard time getting things done.
Even trying to triage everything in queue is difficult, because inevitably, everyone argues valiantly (and rather stubbornly at times) that their issue is the most important and must be looked at first. And most have valid reasons: client impact, loss of functionality, etc. The problem is, there are so many to pick from at a given time that we simply cannot take “My problem has client impact so it must be looked at ASAP” at face value. Otherwise, we’d be constantly shifting in work and never able to focus on our larger goals. Here again, I’m really hoping next month’s meeting will help to clarify and ease this nasty task. At the very least, we need to have some kind of objective framework by which to determine the true priority of requests / issues, similar to the various trauma scales I learned years ago as an EMT.
Yes, I really did just compare my work to dealing with traffic accidents, gunshots, and various other forms of critical illness. The way things are around here, you’d think we were really dealing with life and death scenarios, instead of mere dollars and cents.
I’m interested in seeing what can be done to alleviate the pressure of the normal work so that the emergency work can be tended to. Of course the reality is that if normal work is tended to then the right things get done right and we have fewer emergencies
One of the ways I’ve tackled this issue in the past is to more properly space projects so as to allow for slack for dealing with pop-up issues. For example scoping out a 4 day project to 8 days may not look good as an elaplsed time but it has many benefits: emergencies can be handled without putting other projects in jeopardy, changes in the projects can be handled, my team is not over stressed which leads to a morale boost, when we deliver a day ahead of schedule we look pretty good.
Another way to handle the issue is to have a duty desk such that all non resource-specific issues should be handled through the duty handler. For example if a requestor does not have a specific DBA resource assigned to their question, then they need to discuss with the duty handler who is not doing project work during the assigned time(s).
I agree though that it needs to be a team approach to dealing with what often comes down to issue management and resource issues. Good luck!
Have a look at a talk titled Time & Attention a guy called Merlin Mann gave at Google last year – should be up on Youtube. He’s also heavily influenced by David Allen’s GTD methodology, which I personally use. It relies on some investment in time and effort on the front end, but pays dividends later
@Michael – Actually, I’d kind of like to see it the other way ’round; get rid of the “emergency” work so we can focus on the important, non-urgent stuff, like benchmarking and review of the code base. I really and truly believe that getting into proactive mode will be the best in the long term.
@James – thanks for the link, I am going to check that out. Merlin’s “Inbox Zero” talk is actually what first turned me on to GTD!
@Josh.
Yes – precisly what I meant by “Of course the reality is that if normal work is tended to then the right things get done right and we have fewer emergencies”
@Josh.
Yes – precisly what I meant by “Of course the reality is that if normal work is tended to then the right things get done right and we have fewer emergencies” but on the other hand we cannot put off the emergencies (if they are truly emergencies)
The point about making sure projects have enough time also helps to illustrate to business buyers the lack of resources available to handle their business needs to either 1) do things right in the first time – hence the emergencies or 2) handle the emergencies and what should be the normal projects at the same time.
It is through the burden of pain that eyes are most open. Putting all the burden on your own shoulders alleviates the need for others to open their eyes.