Etiquette of Troubleshooting Problems In The Workspaces Of Others
A visibly upset colleague approached our technical support team this morning. She noted a member of our team had changed her workspace:
Her monitor was turned off (she expected standby mode).
Her chair settings were changed.
She had been logged out, with one of our team member's names in the Windows log-in box.
The first issue seems to have led to confusion and frustration as she wondered why she did not see her PC resuming from standby node.
The second issue seemed to have been a trigger for a need for respect and comfort; apparently it takes her some time to find just the right setting to feel comfortable.
The third issue seemed to stem from her desire to wrap up work prior to a three-month leave in 1-2 days. It can take 1-2 hours for our corporate virus scanner on her older PC to complete a weekly scan, which seems to be triggered on log-in. This reduces her productivity.
After she felt heard about why our team might have needed to do these things, she returned to a pleasant state. But I wondered what "etiquette" might have avoided/minimized triggering all these reactions in her.
A cursory Google search and a search here returned nothing especially insightful. So I thought I would invite reader responses to generate a list of best practices when troubleshooting problems in the workspaces of others.
Thanks in advance for any contributions.
Solution 1:
There are three concerns as I see them: Changes to the physical workspace, changes to computer-specific properties, and changes to user-specific properties.
I would tend to err on the side of treading lightly re: changes to the workspace. Common sense says that making any changes to the physical workspace is a bad idea, IMO. That would include changing chair settings, moving items not directly related to the work being performed, rifling through papers on the desk, etc. That strikes me as rude.
Altering ergonomic settings for a short visit is probably a bad idea, too. Changing monitor brightness / contrast settings, for example, would be ill advised (unless the settings are so far off that you can't see to work).
Religious dogma aside, the axiom "Do unto others..." rings true here for me. I wouldn't do anything to someone else's workspace that I wouldn't want them to do to mine.
A robust remote control solution would take care of a lot of this. Sometimes you have to go out and lay hands on a computer. A user should be prepared to have the computer they use pulled out of their workspace, if necessary. It's not their computer-- it's the company's computer. It's not their workspace-- it's the company's workspace. Your example didn't have such a scenario in it, but users should be expected to understand that some failures could result in the computer in their workspace being removed and replaced and they should deal with that.
If I did have to pull a computer from a workspace I'd try very hard to inform the user before I did it. If I couldn't, I'd leave a large note w/ contact information and details on what work was done.
I'm less likely to tread lightly re: changes to computer-speciifc properties. It might disorient somebody to have their monitor turned off, but I think assuming basic computer familiarity re: turning on a monitor is well within the expectations of a computer user. Likewise, the last logon name (a personal peeve of mine, and one of the reasons why I have the "Don't show last logged-on user name" group policy setting deployed at all of my Customer sites) isn't a showstopper that a computer literate person should be unable to handle. The guiding principle re: computer-specific properties should be something like "Can a computer-literate person be expected to deal with this change w/o asking for help?"
Making changes to a user-specific properties is like making changes to their physical workspace, to me. You should tread as lightly as possible here, too. Think about what changes you'd want someone else making to your user-specific settings w/o your knowledge, and apply that judgement.
Solution 2:
I will generally try and avoid needing to physically access a user's machine where possible. Technologies such as RDP and VNC generally allow a large amount of problem solving to be done remotely, often with the user present.
However there are times when there is no substitute to being physically at the PC. In these cases I will try and let the user know in advance that we will need access to their PC, and that we will more than likely need to log them off and probably reboot the machine. That way users are able to save everything they need, and are not suprised when they come back to their machine to find it at the logon prompt.
While working at the machine I try to avoid altering the user's environment at all, it's their workstation, I'm just a guest. I'll probably sit in their chair, but I won't change how it's set up, I won't alter their desk if I can avoid it, and if I have to move things I'll try and put them back where they were.
Whilst it might seem like a silly thing to the engineer, altering the user's work environment can upset some people quite a lot. Ensuring that you change as little as possible not only helps prevent upsetting the users, but also means they will be happier for you to come back and deal with other problems, rather than thinking 'every time IT comes I have to spend 2 hours re-arranging my desk'.