Well, I finally did it.
Last week I finally allowed myself to let go of a support issue that I
didnt need to continue supporting. Im
sure most techies would agree that sometimes its just tough to step away from
a task and let someone else handle it. Who
better to fix something than you, right?
Youre never fully confident someone will do as good a job as you would
do; its called human nature. And at thecenter of it all is a little thing called trust.
Who better to fix the interface server with the transactions
backing up? Who can get that SQL Server
cluster back up the quickest when it loses connection to the SAN? Outbound email isnt being sent. Who better to fix that? The answer, of course, to all of thesequestions is the person staring back at you in the mirror YOU.
But then again, if youre always busy saving the world each
day, who is installing the new systems and upgrades? Who is performing health checks on your
directory services infrastructure and mail servers? Who is reviewing system logs and keeping up
to speed on all the latest security patches released by Microsoft this month? If the answer is still you, you may have aproblem; if not now, then soon.
At some point, we have to transition a new system or upgrade
from the installation and baby sitting phase to the general support and
maintenance phase. The anyone on my
team should be able to troubleshoot this phase. That is, of course, assuming you posted buildnotes and support documentation for each of your installed systems. You did do that, right?
Yeah, I thought so, me too.
Who has time to take screen shots and document support procedures for a
system that is newly installed and, at the moment, stable? It is agonizingly time consuming and boring
not nearly as interesting as saving the world from certain peril. We generally exist in the workplace to rush
around and extinguish fires and high-five our successes. There isnt much glory in pasting Print
Screens in a Word document and creating a Table of Contents with
hyperlinks. But if you dont do it
relatively soon after a new installation, you may later find yourself
scratching your head and sifting through notebook pages and emails to figure
out what to include in the documentation.
And whats worse, until its complete, you will be the one personsupporting the system.
Thats pretty much the scenario I often find myself. I work a few months or longer to get a new
system in place, and then, as soon as its complete and stable, I move on to
the next project. Documentation is an
afterthought. But sooner rather than
later the system will hit a bump, and I will get the privilege of fixing it
because I didnt bother to share support information. Some of this is because I was too lazy todocument, and some is because sometimes its just quicker if I fix it myself.
Or at least it seems to be quicker. In reality, its more costly to the end users
and me. I end up with too many irons in
the fire so to speak. I get stretched
too thin and find myself unable to respond to support issues in a timely
manner. Think about it. Implement several new systems each year at
multiple sites, multiply that times a few bygone years, and you quickly findyourself unable to juggle adequate support alone.
The solution is to trust your colleagues, empower them
through communication and adequate support documentation, and realize that its
not a good thing to hold a monopoly on all the systems youve been given
responsibility for. Its easy to believe
that by holding onto knowledge that no one else has, you are more valuable to
your company. But in reality your job
performance suffers and you become a liability.Its okay to let go. Really.