Etiquette of Troubleshooting Problems In The Workspaces Of Others

Question

A visibly upset colleague approached our technical support team this morning. She noted a member of our team had changed her workspace:

1. Her monitor was turned off (she expected standby mode).

2. Her chair settings were changed.

3. 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.

Answer 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.

Answer 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'.

Answer 3

I think the most important thing is to leave a note.

From your story, it sounds like the user deduced that her computer had been messed with by IT, rather than having been informed. Chances are that a note that said something like "I'm sorry, but we were forced to log you off of your computer in order to perform some required maintenance. Please contact us if we created any problems. Signed, IT" would have at least ameliorated the situation. And don't email it; leave it on a PostIt stuck in the middle of the monitor. You need to inform them that something has changed before they notice that something has changed.

Of course, the best thing is to not need console access at all. This question is about when you do need access, but you should make sure your admins have as many tools and as much knowledge as possible about remote administration to avoid needing console access.

That said, I have a technical note. Administrators not being able to dismiss a locked screen without logging the user out is one of the worst GUI decisions that Microsoft made with Windows. When you do need console access to click one button, you always have to weigh the unknown impact of shutting down all of the user's running programs against what you need to accomplish. Fortunately, someone created a way to get around this, called RemoteUnlock. The source code and binary is long missing from the site, so I uploaded an archive I had to Launchpad: RemoteUnlock on Launchpad.

Answer 4

This is more personal opinion and varies a lot in importance depending on the mood of the user but in general there is one guideline: The end user is your customer.

To address your specific issues:

1. Power save policies negate the need to turn off a user's monitor and turning it off for them in an enterprise more than likely just causes a help desk call (it seems strange to the sys-admin, but it can actually confuse people).

2. Having the user logged out may be required to fix the problem, but most things could probably be changed running something as the tech's user leaving the end user logged in.

3. There is no reason to change someone's chair settings at their cube or office for the short amount of work being done.

When you think of the user as a customer you want to fix the problem while changing as little as possible.

Answer 5

At least 2 of those, switching off the monitor and leaving the PC in standby are more a user education problem.

1. Why is she wasting energy leaving the monitor on overnight? Depending on the type of monitor it could be a lot. If it is not then why was it turned off? Make policy for one way or another and get everyone to follow it.

2. Avoiding a virus scan which runs at login is all very well until she comes back complaining that a virus has deleted her work. Rather than try and avoid her problem with it by creating another one, it would be far better to come to IT support with it so that something could be done. Eg. moving it from login to scheduled at lunchtime or something like that.

Also making it clear that PCs might be maintained/rebooted/powercut overnight and that users should save their work in case they are logged out is sensible.

Answer 6

The simple rule that I always followed was to respect that you were, in effect, entering someone's personal space, and to act accordingly. Fiddling with belongings, changing anything that didn't absolutely need to be changed, etc -- all big no-nos. I also liked to have the user around, so I could explain what I was doing and ask permission to do anything that would persist beyond my presence there (including logging off, etc). I could also build a steady rapport with the user which helped to defuse those sorts of situations.

Answer 7

My numbering is not related to yours. I just wanted to "bullet point" my points.

1. Don't touch or adjust anything at the users workspace. Their workspace is theirs, not yours.

2. Don't touch or adjust anything on their computer that's not related to fixing the problem at hand, maintaining the computer, or making sure it's in compliance with company standards. If they like large icons, 640x480 resolution, and dinosaur mouse cursors, that's their business not yours.

3. If a tech must log on to the computer in order to perform their job, notify the user beforehand so that they know to check\change the username when they log in. The tech could initiate the logon dialog box after they're finished and type the users username in, but depending on your settings (power, screensaver, automatic updates, etc.) the username might not be there when the user shows up to log in.

If the machine is clean of malware and you have a good real-time, on-access AV product, why do you need to run scheduled scans?

Answer 8

In regards to #2, it is one of those things that again seems silly to admins. However, in environments where there are not shared workstations and so the username is always already typed in for the user, a lot of users forget their username. So when someone else logs in and out of the system they don't understand why their password isn't letting them in.

To alleviate this, we often set the group policy for not saving the username on the login screen. That way the user has to type their username and password when they login and will then be able to do so when they go to another workstation or if someone has used theirs.

Answer 9

As a few other people have mentioned, one and two are a matter of treat your users workspaces as you would like them to treat yours if you were in the same position, although turning off a monitor really is a reflex when you're used to doing it on your own workstation.

With regards to number three, I can't speak for the specific situation, obviously not being there, but it's important to remember etiquette swings both ways. If I had £1 for every time I'd told a user I'd come and see them at a certain time and they've decided to disappear off the face of the earth at exactly that time (including when I've said I'll be there in 2minutes) I'd have enough to retire.

Setting the don't display last login name in the GPO is a good idea to make the users remember their own user name. Our field service engineers have all been given a pad of "Sorry we missed you" post-it notes which are handy to leave a note that either someone has been and gone, and for them to rearrange another visit or to tell them something has changed.

Answer 10

<humorous>

I can't really speak to the other stuff because I'm going into a meeting in 5min but I will say this...

Anyone who changes MY chair settings qualifies for an instant KeelHauling.

We can talk about the other stuff after they come up for air. >;-)

</humorous>