Dealing With Too Many Voices

When I was a DBA (and, to a lesser extent, now as well) I frequently got into a scenario where I’d have multiple groups clamoring at me to accomplish a request from them on short notice. This sometimes became a problem, such as when there was only x hours in the day and I needed y hours to finish everything that folks were requesting. Or, when I had multiple people demanding immediate service (that never happens, right? Oh wait, it just happened today, that’s why I’m writing this. #Facepalm). Earlier in my career I would tend to get worked up, let my blood pressure go up, and perhaps engage in some creatively worded conversations with the people competing for my time. But after realizing that (a) this really wasn’t helping things, since people still want what they want; (b) all the yelling wasn’t helping my health, I came up with a couple rules on how to handle these, let’s say, explosive situations. In both cases, they’re remarkably effective at both alleviating the confusion over relative priority and lowering my stress level.

First: don’t even try to work out on your own which request is more important. Sure, you can ask questions and try and rank things in your mind according to things like which client things are for, how long things take, etc. Ultimately though, you’re going to be wrong in someone’s eyes and that someone is going to be unhappy with it. And moreover, unless you’re a manager, you’re not paid to determine things like that. You’re paid to get things done and write code, period.

Second: let the competing groups do just that – compete! Send an e-mail to the various requestors stating something like this:

Hi there folks, this is your friendly neighborhood (DBA | Architect | Database Developer) speaking. I thank you all for putting in your requests to me, and I acknowledge that each of you has requested that I handle them immediately. Unfortunately I can only work on one task at a time (unless someone’s developed cloning technology, which would be super!), so I will be doing these in the order which they were received. Before you begin thinking of arguments to get me on your side, I will warn you that this decision is not mine to make, so please do not send me justification of why you need to come first. If you feel that your request should take priority, please work with the owner(s) of those requests in front of yours to adjust their priority. If you all can amicably agree to shuffle things around I’m happy to oblige. I’ve listed the relevant work items below in order along with their owners. If I do not hear back I will assume you are all fine with this and will proceed in the order shown. Thanks!

Let the various people battle among themselves for the lead. Yes, this can sometimes get a little bloody, so you should probably check with your boss to make sure this is allowed before doing it. Which brings us to our third point…

Third: let your boss handle it. Managers are paid to, well, manage! If people cannot agree peaceably (or otherwise) on a pecking order, let your boss hear each of their cases and then tell you what to do. This will take the pressure off you to make a decision that is clearly one at a level above yours. Certainly your boss may (and perhaps should) ask for your input in the matter, but the decision should rest with them.

Since I’ve put the above rules in place I’ve never been more than slightly annoyed when these situations inevitably come along. It may not stop (or even lower) the volume of whining coming your way, but it will let you deflect and delegate all the stressful aspects of the problem.

You Only Have So Much Time – Use It Wisely

Hello there blogosphere… been awhile since I posted!

What’s that you say? Did I lose my motivation? Why no, actually, I’ve been extremely motivated lately. Just not to blog.

You see, I came to a realization shortly after my last post: I’ve only got so many hours in a day, so I’d better use them as best I can. I love blogging; really, I do! But I love spending time with my family more. I love working on our drafty old house, tilling the garden, seeing some tangible results of my work. For some reason, I am finding myself really hung up on the whole idea of producing things with physical presence. For example, for Christmas I spent hours building the simplest little wooden toy for my son. I’m not a natural and not very experienced at that sort of thing, so it was not easy work. But I found immense enjoyment in it, and the look on his face when he saw it come out of the box was nothing short of priceless.

Perhaps this is why I haven’t been blogging much. Writing is wonderful, but if I’m going to be brutally honest, I’d much rather write science fiction than SQL Server. Please don’t misunderstand me; I love my work and learning about SQL Server. When I’m on the job I eat, sleep, and breathe it. I’d say you’d be pressed to find someone more passionate and focused than I am during those 8-10 hours on Monday through Friday. But when work is done, I want it to be done.


The above picture is something that really had some profound impact on my perspective. For a while I felt like I was floundering in my personal life. Things never seemed to really get done. I had my lists, and I was reviewing them, but I lacked focus. I never felt like I had much time to get things done. So, I decided to see just how much time I really had.

Using a simple Excel sheet, I laid out my week, then blocked out sections in color for things I knew I had to do. Green is sleeping, yellow is work, and blue is meals. And when I saw what was left, I was shocked. My feeling that I never had enough time to get stuff done? Boy was I right. Comparatively speaking, my “discretionary” time (that is, the time during which I pretty much choose what I do) was quite small.

Obviously, short of quitting my job or getting less sleep (and believe me, you don’t want to see me in zombie mode), there was no way to increase the time available to me. So instead, I chose to be more deliberate with how I spend what time I have. I sat down and thought long and hard about what is important to me. After awhile, I came up with a list, and while work and SQL Server were definitely on there, they weren’t as high up as I’d have thought. So, I made the conscious choice not to write on this blog, while doing other things.

That word, “conscious”, is a very important one. Whereas in previous hiatuses, the lack of postings was more about my lack of motivation, this one was more about doing what was important to me. And I hope that in sharing this, I might encourage others to do the same. J.R.R. Tolkein famously wrote “All we have to decide is what to do with the time that is given us.” So, if you find yourself mindlessly wandering through your personal life, as I did, stop wandering, and start deciding.

Now don’t fret, dear reader, for I am not abandoning this blog. I’m still going to write, even about SQL Server! But at the same time, I’m going to spend a good bit of time on other things, like writing that novel that’s been sitting at one chapter for over a year now, or tending to my garden (because c’mon, who doesn’t love fresh-from-the-ground veggies?). I hope you’ll stay with me, because I do think I’m still going to write interesting stuff; just a little more diverse than previously. I’m going to work on getting category-specific feeds up, so if you like, you can just subscribe to those that interest you. I also plan on trying to write a few articles for the likes of SQL Server Central or Simple Talk.

Project Resource Scheduling Is Hard

One of the challenges that I’ve never quite figured out is scheduling myself for projects at work. When teams come to me for help, they usually want to know when I can get to them (which usually turns into an argument over why I can’t do it that same day). As a result, I have to develop some method of keeping track of the projects on my plate, who they’re for, how long the various tasks are going to take, and when I’m going to do them.

Interestingly enough, this is one area where I’ve found GTD somewhat lacking. The framework is great for keeping track of ad-hoc “Stuff” that can be done whenever time is available, as well as the “waiting for” and “someday” lists, but it just doesn’t seem to work for the kind if date-based scheduling I usually find myself doing. If I just put something on the list without considering how long it will take to do (i.e. “Install SQL Server cluster (6 hours)”), then plotting out when I have time to do it, I wouldn’t be able to give even a whiff of timelines to the consumers of my services. Naturally, that wouldn’t work very well in a deadline driven environment.

What I’ve been doing as of late is simply blocking out time on my Outlook calendar as projects arise, then letting folks know when I’ll be taking care of their work. It’s fairly simple, and works decently. I would like to figure out a way to make it a little more transparent than it is (I obviously don’t want to share out my calendar to everyone in the company) and easily reportable.

Ultimately though, the biggest problem is that the damn thing just fills up too quickly. Even fully reserving Monday, Wednesday, and Friday for project work (I pre-block out my calendar to prevent meeting invites, or at least discourage them), I’m usually booked solid around two plus weeks in advance. Teams generally aren’t too happy about that, though I have to place some of the blame on their shoulders; you can’t realistically expect a skill resource like a DBA to be able to undertake 10+ hours of work on two days notice. But despite reminding folks of that nearly constantly, they still complain and don’t plan, and I’m left in a bind where either one of two things happen: 1) Their work gets done as scheduled, despite their continued whining, or 2) someone higher up gets involved, priorities are shifted around (which is its own headache), and their work gets done sooner.

If I’m having this much trouble scheduling my own time, I can only imagine what it must be like doing it with multiple resources. Thankfully I’m not there yet, though if this work volume keeps up it might just be the justification (along with the gradually increasing din of complaints) to make my “team of one” a little larger.

How do you schedule your time if you’re a project based resource? How to do handle the inevitable emergencies that arise as well?

That Ever Growing “Someday” List

So you might remember a previous post where I lamented my lack of a “Someday” list. Well, since then, things seem to have swung around to the opposite extreme. I’ve now got a healthy selection of projects-in-waiting, both for work and personal. Partly it’s been because I’ve been better at cleansing my action and project lists on a weekly basis; anything that has laid static for more than a few weeks gets archived and tagged “Someday”. But I’d say with confidence that the growth is largely attributable to a shear lack of time.

Ever since the birth of my son Taylor, things at home have been, well, busy to say the least. It’s been a struggle just to keep up with the day to day work, such as keeping the house clean, the laundry done, and the trash empty. With such little time and energy left over for personal projects, strict adherence to priorities and ruthless cutting of scope has been the rule of thumb. So much for things like learning Perl (though I’m sneaking this in at the gym on the treadmill), building a new Snort server, or even non-geeky work like painting the exterior windows on the house.

Work, while slightly less crazy, has been quite a whirlwind as well. After some purging of wartime troop levels, the remaining force has been tasked with a “lights on” mantra. That’s all fine and good, except you’d be ludicrous to call what we do “keeping the lights on”. Software still needs to be updated, security maintained, systems administered. Yes, some of the excess fluff has been removed: no more long troubleshooting of user issues (is it replicated on a clean system? If not, guess what, you get to re-image your computer) or extra out-of-scope work. But still, there is no shortage of necessary tasks to be had. Combine that with taking on a new product and expanding my role to include some levels of data-guru, and you’ve got a packed agenda.

On the one hand, it is more than a little frustrating to see the mounting list of “not yets” and “maybe somedays”. But at least I can be secure that everything is safely tucked away, waiting for the day when changing diapers isn’t an hourly occurence, or treading water at work less the norm.

The Myth of Priority

When I do my weekly review, I’ve made it a habit to mark items as “priority 2” in Remember The Milk that I’d like to get done in the next week.  This puts a nice blue mark next to them in my lists, so they stand out from the crowd.  In the beginning, it gave me a sense of direction going into the week.

Here’s the problem: I don’t see any reasonable correlation between the assigned “priority” of an item, and whether or not it get’s done in a timely manner.  Priorities shift so rapidly in my life that items never stay in the same category for very long.  This morning’s “priority one” could become this afternoon’s “maybe tomorrow” in the blink of an eye if a fire pops up.  As a result, what I see is things marked as “high priority” piling up, which makes me feel like I’m getting buried even more.  It’s a vicious cycle to be sure.

Perhaps that’s why according to the “true” principles of GTD, priority is really something that gets decided on a moment-by-moment basis.  When faced with a block of time, and no clear indication of how to spend it, GTD suggests examining the following criteria:

  1. Context (where are you and what do you have access to)
  2. Time Available (5 minutes, 30 minutes, 2 hours)
  3. Energy Available (high, medium, low)
  4. Priority (dictated or decided, see my previous post)

Think of the following situation: you have fifteen minutes in between meetings, and are exhausted after a long night up with the spouse talking about some things in your personal life.  You’re sitting outside the conference room of your next meeting, but have your laptop with you.  You can choose between a)starting to work on diagnosing a rather nasty technical issue, b) paying a bill or two online, both of which are due in a week, or b)responding to three e-mails (one of which was marked urgent by the sender) which have been sitting since this morning, and are simple one-and-done questions.   Which is the more productive choice?  I won’t answer the question; you decide based on the list above.

So how does this relate to my original question?  Well, in my case, re-reading about how GTD teaches us to best use these fleeting moments helped me to realize that my use of the “priority” function in my system was causing more confusion than it was clarifying and ordering my actions.  From now on, here is what I intend to do at my weekly reviews:

  1. Ensure that all my lists are current.  All my open loops are recorded, and all projects are present and accounted for.
  2. Any item which has a specific and (relatively) inflexible date by which it must be completed is assigned a due date.  For example, I have to get my taxes mailed before May 15th, or else ol’ Uncle Sam will come knocking.
  3. Any next action that is currently on my next actions list, and has been there for more than three weeks without moving, will be moved to the “someday” list (more on this in an upcoming post).

In addition, at least three times per day, I’m going to stop, and evaluate how I’m spending my time, based on the above four criteria.  Going even further, I am going to write this down, and post it to my Twitter feed for all to see.  I’ll use this shorthand for ease of posting: “c:” for context, “t:” for time available (high, medium, low), “e:” for energy (high, medium, low), and “p:” for priority (high, medium, low).

As my readers, I ask that you hold me accountable for this statement!

How important is it, really?

In my work I’m constantly bombarded with reports of problems.  Given that a high percentage of these come in with an urgent tag attached, I decided some time ago that I needed to come up with a systematic approach to determining their true priority.  After all, I’m only one man, and if I treated everyone’s problems as raging fires, I’d never get anything done.  What I’ve come up with is the following three-pronged approach:

Clarify the scope

In my experience (and I’m sure that I’m not alone), problems tend to be described by end users in global terms: “the system is down”, “we cannot login”, etc. But in reality, the problem may be much smaller. I once had a user e-mail me directly (another no-no) stating “System X is down, I cannot login. Please fix immediately.” When I called the user and asked about whether others in his group were experiencing the same problem, he replied “Yeah, I think so. I didn’t ask.” When prodded to ask further, it was discovered that the problem was limited only to this one user, making it a far lower priority than the original message would have indicated.

What is the impact?

Ok, so you’ve established that there’s a problem, and you know it’s affecting an entire department. But what does the existence of the problem mean for business? Are operations at standstill? Are people being forced to sit at their computers and twiddle their thumbs? Or, on the other end of the spectrum, are people’s widgets not looking as pretty as they should be? I’ve found it helpful to evaluate technology problems in the context of how the functionality of a system is affected. There’s a huge difference between losing a minor feature of a program versus losing the core business requirements.

Is there a workaround?

In today’s world, technology is often about the automation of manual processes. If the automation fails, users can often revert to the (albeit slower, more painful) older methods of completing their work. If the problem has no workaround, however, you obviously have a bigger issue to contend with. Keep in mind though, workarounds are only as good as the user’s ability to carry them out. If your automated trading system goes down at 3:50PM, and no one remembers how to enter trades on the old green screen terminals, you might as well not have those terminals in the first place.