CIOs, local workstation admin rights and culture…

I received a simple question yesterday that I’ve had before: “What do most school districts do regarding local administrator PC rights for staff members?” To allow or not to allow, that is the question. Let’s blast through the options really quickly:

Do NOT grant local admin rights to staff

PRO – Staff members can’t “mess up” the workstation with bad product installs requiring a reformat. Tech staff can more easily maintain a standardized environment for their users. Advocates will tell you that, with limited staff, it’s critical to make best use of tech staff members’ time and this potentially saves them time from correcting errors made by some users.

CON – Staff members can’t install software that they deem necessary for their day-to-day use. Tech staff members are asked to install products on a regular basis, which could create more work tickets and more work for staff.

Yes! Grant local admin rights to staff

PRO – Staff members can install the products they deem necessary. Techs aren’t being bothered by install requests and can focus on other things.

CON – Some staff members create problems by inadvertently rendering their computer unusable. Techs have to dedicate time to rebuild the machine or otherwise correct the problem that, in theory, might have been otherwise avoided.

What’s the right answer? Depending on how it’s implemented, either scenario can work… or can fail miserably. Based on what I’ve seen and heard, I would lean toward a scenario that grants local admin (or at least some type of product install) rights to staff members. I intentionally left out a pro/con from the scenarios above. It involves culture and trust. I’ve talked to users in several school districts where some level of technology concerns existed. One pretty common theme was a fracture between the technology department and the staff, with the belief that one group didn’t “trust” the other. When administrative rights are not provided, the staff members believe that the techs do not trust them to install software. The techs sometimes validate this, pointing out that some staff members have proven that they shouldn’t be trusted with these rights based on past incidents.

We’re just completing a week where I’ve seen SEVERAL users show no concept of when to use or NOT use the “reply to all” function in email. It indeed shows that some users don’t “get it” when it comes to certain aspects of technology use. Even with that fresh on my mind, a few thoughts come to mind on this topic:

• What is the technology department’s purpose?
• Do you know how your staff thinks of you or your technology department?
• What does your policy on topics like this and Internet site access say about the culture you’re trying to build in your district?

As tech leaders, are we here to lead? To teach? To protect? To serve? It’s all of that, right? You can lock down the computers to protect your users. As one technician once told me, though, “…you can lock down a computer to the point that it’s no longer a computer.” It’s a fine line, but the lock-down scenario creates a perception that shows up in other aspects of the job. How willing will your users be to ask about a concern they have? Will they open work tickets when they should? Each time a user tries to do something and is “locked out” by policy, that memory gets filed away and leads to the assumption that the technology department doesn’t want that user to use the computer.

Let’s go the other direction for a moment. How difficult is it to correct the install problems that a user might create? If you’re spending HOURS at a user’s machine when a problem arises, then you would certainly want to “protect” everyone by preventing the problem from occurring. However, if you have a standard workstation image that can be deployed relatively quickly, it might not bother you as badly if a user has a self-created mess on their desktop. In this scenario, the real “problem” to solve might be the one that leads to the most efficient correction plan rather than the most fool-proof protection plan.

We learn and grow through failure. It stinks, sometimes, but it’s true. Basketball fans know that the great Michael Jordan was motivated in his high school years by not being allowed to play on the varsity team as a sophomore. J. K. Rowling was an unemployed single parent struggling through life before creating the Harry Potter series of novels and becoming one of the wealthiest women in England. If you don’t like rags-to-riches stories, look at nearly every video game that kids play. Their character gets shot or crashes or fails in a quest. They see what they did wrong and process that as they’re then allowed to return to that level of the game. Do you enjoy being told that you CAN’T do something? Neither do  your users.

There’s a time and place for prevention, but the successful tech environment will strive to balance that with a good dose of service and teaching… perhaps through some sort of failure. Your environment may be different from your neighbors’, but try to take an honest look at your culture and see if it matches the culture that you want to create. Seemingly small items like this are building blocks toward that culture. Take care!