Well, I finally did it. 

Last week I finally allowed myself to let go of a support issue that I

didn’t need to continue supporting.  I’m

sure most techies would agree that sometimes it’s just tough to step away from

a task and let someone else handle it.  Who

better to fix something than you, right? 

You’re never fully confident someone will do as good a job as you would

do; it’s called human nature.  And at the

center 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 isn’t being sent.  Who better to fix that?  The answer, of course, to all of these

questions is the person staring back at you in the mirror – YOU. 

But then again, if you’re 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 a

problem; 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 build

notes 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 isn’t much glory in pasting Print

Screens in a Word document and creating a Table of Contents with

hyperlinks.  But if you don’t 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 what’s worse, until it’s complete, you will be the one person

supporting the system.

That’s 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 it’s 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 didn’t bother to share support information.  Some of this is because I was too lazy to

document, and some is because sometimes it’s just quicker if I fix it myself.

Or at least it seems to be quicker.  In reality, it’s 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 find

yourself unable to juggle adequate support alone.

The solution is to trust your colleagues, empower them

through communication and adequate support documentation, and realize that it’s

not a good thing to hold a monopoly on all the systems you’ve been given

responsibility for.  It’s 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. 

It’s okay to let go.  Really.