A Wandering Mind

A short while ago, I read a great post by Kendra Little (@Kendra_Little on Twitter) on how using some common consulting tricks can be useful even for those not in a consulting role. One item that resonated in particular was the idea of tracking your time, for the purposes of finding places where your time is probably not being used wisely (Kendra uses the example of not planning for disaster recovery, a clear “must-do” for a good DBA). I’ve tried various methods of tracking my time before, including everything from home-grown applications (I suck at GUI programming on a side note) to simple notepad paper. Everything failed miserably for one of two reasons.

It Was Too Hard To Use

My cruddy GUI programming skills aside, I had never found something lightweight enough that I could really use it consistantly without slowing down. In my work I am constantly switching tasks, so whatever method I used needed to not require ten clicks to switch from one task to another. If it was anything less than really easy, I would simply give up after a few days.

It Didn’t Give Useful Data

Recording time is one thing, but of equal importance is the metadata associated with that slice of time. What project was I working on (if there was a defined project, not something that’s always true)? For what client? What “tags” or other little flags were associated with a piece of work (for instance, was my time spent dealing with a “walk-up”, or was it unplanned troubleshooting)? Without this enriched data, simply knowing that I spent from 8 AM to 9:45AM working on task ‘XYZ’ really isn’t very useful.

Well, thanks to Kendra’s suggestion, I’ve finally found a tool that I’m sticking with. Toggl is nothing short of fantastic! It’s easy to use, quick, and allows me to easily tag and classify work without a lot of extra effort. It’s been downright fascinating seeing how my time is really spent, and I’m finding it’s often quite different than what I perceive. I might feel like I’ve spent every waking moment working on a particular effort, only to find that my judgement is skewed simply because I find that particular work unpleasant (nothing to throw off your gut feeling like hating what you’re doing).

Most importantly, it’s enabled true, accurate (at least mostly so) transparency with my superiors and customers. When I report weekly to my boss, I can say with integrity what I have (and conversely, have not) been spending my time (and therefore the company’s money) on. It’s been invaluable in tweaking my workload to better suit our client’s needs, but also in identifying easy automation / delegation opportunities. Clearly a win for both sides!

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?

Update: Mike sent me a link to an article he wrote for SQL Server Central on this same subject, and I wanted to include it here: http://www.sqlservercentral.com/articles/Troubleshooting/66134/

When I was sixteen I became one of the youngest EMTs in the state of Pennsylvania. I was proud to volunteer my time, and found I greatly enjoyed helping people. It was both incredibly humbling and empowering at the same time: on one hand, there were times when you were utterly helpless and could do nothing to help your patients, but other times you clearly saw the immediate impact you were able to have. I can say without question my experiences, both good and bad, changed me as a person.

Fast forward fifteen years, and I find that fellow SQL tweeter Mike Walsh (blog | twitter) also has some background in emergency services. We had a nice little chat about our experiences and how they ultimately help us in our daily work. Thus, I became inspired to write about how my time riding around in an ambulance helps me be a better DBA.

Checklists And Procedures Are Essential

When we arrived on the scene of a medical emergency, we were drilled ruthlessly about a series of steps to assess our patient’s condition in rapid fashion. One of the first tasks was what we called the ABCs- Airway, Breathing, and Circulation. Basically, is the patient have a clear airway (choking, etc), are they breathing, and do they have a pulse. It was simple and easy to remember; two essential things when you’re in an adrenaline charged situation with someone’s life on your hands.

Once we were past the initial basics, we had a written list of additional information to gather: current medications, allergies, existing conditions, injuries, etc. Personally I carried that pad of paper with me in my pocket at all times while on duty, and used it without fail on every call. I don’t know about you but I would not trust someone’s life to my memory.

The same should be true about dealing with SQL Server emergencies (I use that term loosely as you’ll see later). Do you have a documented, step-by-step process to perform an assessment of the issue at hand, and take corrective measures? Is it readily available, clearly written, and has it been practiced? What about recovery procedures? If you get paged at 3AM (after a night at the bar of course) and have to perform a restore of a corrupted page, will you be going off memory or will you be walking down your checklist? Heck, forget you, what about that junior DBA who joined your team a month ago and is taking his first on-call rotation? Do you really want him flying by the seat of his pants?

Sometimes A Calm Voice Is The Best Medicine

I once was called out to a house where we found a young boy who had fallen and broken his arm. Immediately it was apparent that the injury was fairly minor (at least as minor as a broken limb could be), and that the situation was being made far more chaotic by the boy’s hysterical parents. They were yelling and screaming at each other, blaming one another for letting this happen, yelling at us for not taking proper care of their son, etc.

That night it happened that my driver was also my supervisor, a man with over ten years of experience in EMS. He quickly brought the two parents together off to the side, and said in a quiet but authoritative voice, “Ma’am, sir, I promise you we are doing everything we can to help your boy out. What I need from you two right now is to listen carefully to my medic’s questions so we can get all the information the doctors will need. Can you do that for me please?”

That simple request, combined with his soothing tone of voice, settled them instantly and brought them out of their hysteria. Once they had something to focus on they were cooperative, and we were able to get the information we needed and transport the boy to the hospital for treatment.

Similarly, the next time someone (be it a developer, a business user, or whomever) runs up to your desk in a panic, try speaking to them in a calming manner. Assure them that everything will be done to fix their situation, then ask them to help you by answering some simple questions. Is the application totally down, or is there just some functionality that is not working? How many users are affected? Are there any financial or other risks present due to the ongoing presence of the issue? In a lot of cases, those answers may even prove that the situation really isn’t as urgent as they thought.

It’s Not Life And Death

Mike and I both agreed strongly on this one: our time as volunteers gave us a healthy dose of perspective when it came to dealing with IT “Emergencies”. After all, it’s not like we’re dealing with broken bones, blood, or the prospect of a patient dying.

I don’t say this to belittle the problems we deal with as DBAs. We are paid to take care of our users and our servers, and we need to take our work seriously. But at the same time, I think we need to make sure we don’t lose track of the bigger picture of life happening around us. A server going down is not worthy of raising your blood pressure, nor is dealing with “that annoying developer” again worth losing your cool. Ultimately, life will go on, the sun will come up, and you can go home to hug your loved ones at the end of the day.

Note: I do want to single out and commend those of us who truly support mission-critical platforms, such as those in hospitals, power plants, etc, where lives may really be at stake. You have my utmost respect as a fellow data professional.

Maybe some day I’ll return to volunteering my time to help those who have become victims of life. In the mean time, I take solace knowing that the lessons I learned in my time in EMS are with me today, helping me to truly be a better DBA.

More often than I’d like, I get e-mails from various folks late in the evening (the record is about 11pm) somewhere along the line of: “This is really urgent and needs to be done EOD today.” Now, I have to assume that either one of two things is going on here:

1. Their End Of Day is different than mine. Not in the time zone sense (though I do occasionally deal with folks offshore), but just in the sense of they work hours beyond the normal workday.
2. They’re being clever and trying to be the first mail in my inbox the next morning.

Now in the case of #1, obviously they’re not readers of my blog. Otherwise, they’d see my prior post where I was pretty clear about my policy with regards to working after hours: high value and emergency work only. That’s not to say there have not been some cases where the work met one or both of those criteria; just merely that most of the time it doesn’t.

In the case of #2, for one I’d laugh because with the sheer volume of e-mail I get, no matter where you end up it’s most likely not at the top of anything. That, and even if you do somehow manage to be the first thing I read in the morning, that in no way affects where in the queue of actions you’ll end up. Guess they’re not subscribers to the GTD style of organization, huh?

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.

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!

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.