The Art of SQL Server Database Administration, Development, and Career Skills for the Technically Minded
Ah the French. We like to poke fun at those guys. Even now I struggle to write seriously without breaking into a line from dumb and dumber… “I don’t know, Lloyd. The French are a-holes…”. But aside from wicked good pastries and some awesome ways to make out they also gave us the concept of triage.
The wikipedia article on triage is an enlightening read, and correlates well with why many think triage has an important place in the world of IT. In short, the concept originated from french WWI field surgeons who would trier, the word meaning sort, casualties into three categories in order to utilize limited resources for the most gain.
It’s important to note that the concept revolves around rationing. In a perfect world immediate care would be given to all three groups, but in reality we just don’t have those kinds of resources. Whether you’re a WWI French medic, or a DBA in local government, failure to properly ration the resources you have can and will lead to the death of cases that otherwise might have lived, including your own career.
My thoughts on triage and how it can be successfully utilized in furthering your career as a professional revolve around 3 broad topics.
Establish a methodology. The original 3 category breakdown of triage doesn’t necessarily translate directly to IT. There are a ton of methodologies out there however that can help you prioritize your efforts in a way that does. Most focus on prioritizing by potential impact or severity, a great place to start. For years I have used a 4 quadrant system where I categorize issues into critical immediate, critical non-immediate, non-critical immediate, non-critical non-immediate.
Once you’v established your methodology you should involve documentation. Let me change that, you must involve documentation. It’s important for simple organizational reasons but also critical for the communication phase of triage I outline below. A co-worker of mine really likes using Trello. I tend to use one-note.
Whatever methodology/documentation form you go with, pick one that works for you and your team. If it isn’t working, debrief why, move on, and use another. As emergencies pop up, projects come in, tasks get assigned, be methodical about their assignment.
Self Assessment. It’s one thing to have a methodology, or get the concept of triage, it’s entirely another to actually practice the discipline. How many projects have never made it to the ship-date because developers got caught up in the minitiua of coding a clever solution and failed to make something actually useful for customers. Joel Spolsky’s duct tape programmer post comes to mind.
If you’re a highly detail oriented, obsessive, perfectionist type person – recognize that you might have a weakness for effective triage. Triage is about rationing resources, sometimes you’ll have to walk away from a project, leave something unfinished, let somebody down. As a DBA you might have a complex stored procedure, whose query plan sucks, whose logic depends on a bunch of udf’s and nested views, whose very existence offends you as a professional. Despite all this, you may may have to kill it another day so that a higher priority issue can be fixed right now. That’s reality.
I worked with a cop who would put 20 hours into a stolen bike call, investigating it like Joe Friday. Meanwhile thefts, rapes, and forgeries piled up in the queue behind and other deputies had to pick up the load. The guy wasn’t lazy – frankly he’d have made a great detective. An assignment where case load was more serial. He wasn’t a detective however, he was patrol. When confronted about his inability to triage, he couldn’t honestly self assess and was ultimately let go.
Triage in IT isn’t a new concept. Google it in relation to software development, system administration, or bug management. There’s a ton of good stuff out there. But I regularly see folks who struggle to apply the concept. Be honest with yourself and practice what you know to be true. Rely on your methodology to help enforce your own rules.
Finally, recognize that triage belongs in non-emergency situations as well. Dropping something important for a raid array in the final throes of death is often an easy decision to make. Our natural fight or flight instincts take over and triage becomes second nature. Sometimes however you have to triage your own actions in view of the long term objective, before it requires life support.
Reading up on new technologies is really important, it’s critical to the success of all our technical careers. But if 6 hours a day on books online is keeping you from getting your work done you need to recognize and ration your resources better. Rationing takes place even when no alarms are screaming, mustaches threatening, or 24 hour deadlines are looming. At least a few times a day you should self triage.
Communicate. Ah, here comes the verbal judo – we both knew it was coming. The rationing of resources often means that somebody will be disappointed. You’ll need to skillfully mark projects as casualties without burning related bridges you may still need to cross in the future. In fact, a major obstacle to effective triage is that individuals don’t want to disappoint people up the chain. Instead they commit to more than is humanly possible. The solution to this is communication. In a true emergency communication might have to wait, but don’t neglect it completely. Whether it happens before or after decisions are made, involve stakeholders in your methodology.
When I was at the S.O. we had about 12 staffers who were the rank of Commander. They answered only to their respective department chief, who in turn answered to the Sheriff. They all carried equal rank, and all out-ranked me. It was not uncommon for me to be given an “emergency” by more than one commander at a time meaning it was not uncommon for me to have to inform somebody that not only outranked me, was usually very impatient, but was also typically armed with both a gun and a mustache – that their project would have to wait. How’d I survive that environment?
First, I’d accept the reality that something on the list was no longer going to get done (at least immediately). In order to pick what, I’d put it to them. Having a documented list of priority projects and assigned stakeholders I would present them with my workload and with as much diplomacy as possible I’d inform them, “I am happy to do your project but this is what’s on my plate. Can you identify for me whose project doesn’t get done so that yours does – and then communicate that to them – since I don’t personally have the authority to change their priority”. Many times my priorities were changed by individuals up the chain with the ability to do so, other times they’d say never mind and simply leave (self triage). In all cases however decisions were made by those in a position to do so and my reputation remained intact and professional.
Whatever you do, don’t promise more work than you can actually perform. That not only disappoints but also makes you look incompetent. If your triage obstacle is trying to be a people pleaser, accept that most people are more pleased by honest communication then broken promises or failed expectations. In a true emergency, if you have to make decisions on the fly, articulate why when the time comes, accept the blame if it was wrong, and move on.
Seriously bro, you gotta learn to triage.