Yes, being able to write easy-to-follow instructions (potentially with helpful screenshots) and/or being able to properly walk someone through a fix over the phone are extremely useful skills for anyone providing IT support. I’ve also in the past had non-IT staff in different locations who we’d call “IT contacts” who you could reliably call and walk through doing stuff when you can’t be there in-person. “Go into the server room, look for this particular switch, are the lights blinking on it?” That sort of thing.
That can take the place of remote access tools, and sometimes works when remote access tools are unavailable or just not the most appropriate solution.
Except when you have easy-to-follow instructions with helpful screenshots that don’t match what you actually have. “Click on FUNCTIONS in the top menu, then RECOMBOBULATE”, when there is no FUNCTIONS in the top menu.
This. The bank where I worked had 20-odd branches. Obviously we couldn’t send one of our staff every time there was an issue. We quickly learned who the tech-savvy folks were at each branch, and we contacted them first before dispatching one of us IT folks.
That means you are not good at writing instructions. Or at least in the way an IT person should be.
That also means that if you’ve written them in the past, check every now and then that whatever product you wrote them for hasn’t changed to the point where they don’t work anymore. I have to do that at work all the time.
As a dev it often fell to me to write detailed install & configure manuals for rather complicated multi-server “enterprise” products.
Which was great & generally successful. Until we hired Kevin.
Nice guy, good head for troubleshooting, lotta obscure IT knowledge. Problem was he must’ve been something akin to dyslexic or ADHD.
He could not read an ouline-formatted page of numbered & lettered steps without skipping unnoticed over at least one step.
Unfouling a botched install because step 4.c.3 had been skipped on server 2 only and 6.d.5 had been skipped on servers 1 and 4 was a special sort of torture.
I used to do phone support before the age of remoting in. I asked very specific questions and and insisted on specific answers to those questions. It helped that i was supporting actuaries, who tend to be technical enough to understand why i needed that kind of information.
Ouch, bummer. But yeah, that’s why I became the bane of the first and second level support when I was the last line before we started bugging the devs. I’m going to double check the basics of the work done so far before I set up a lab and try to reproduce the issue. I was burned a few times by thinking “nah, no one is so clueless to miss that step”. I learned my lesson, now it’s your turn.
I am a developer for very expensive systems used by customers with low tolerance for errors. Every install is done by two engineers: one to read each step, and one to do it. You’d think that would prevent problems, and yet…
Yeah! And the programs you had to load on these steam-driven computers came on wax cylinders. You know how easy it is to accidently melt one of those cylinders when you get get it too close to the steam?!
My father died when a supercomputer suffered a double-ended streamline rupture. Some asshole used the wrong kind of bolts (black oxide-coated brass instead of steel) to put it back together after a software upgrade. The bolts failed and an entire section of pipe literally fell off as the processor approached full power during an unusually intense game of minesweeper. He stayed at his post… when the trainees ran.
…in retrospect, he probably should have run with them. Seriously, what kind of idiot stays at his post in the middle of a steam-line rupture?
Sorry, but this was rather triggering for me. There was a steam line rupture at one of the generating stations my company ran. Right outside the employee breakroom. Seven people died and a couple were seriously injured. Very traumatic for the company. Nothing to do with you, of course, it’s just your comment brought that time back full force.
Along with a hull breach, a main steam line rupture was one of the two things I was always aware of that could kill me the fastest in a submarine engine room.
