Tuesday, April 14, 2009

Illusion and Control

As a geek and a fan of sci fi, I often amuse myself by drawing parallels between real life situations and my favorite TV shows...remember the pilot episode of Star Trek (the one with not-James Kirk)?

The situation:

Let's say that you spend a lot of time managing your staff, telling them how to get work done, making them do the work over because it isn't the way you wanted it and getting frustrated at how impossible the situation is...it never gets better, and you're overworked, having to handle the load. It's a shame that they can't benefit from your experience and wisdom - how ungrateful they are!

Sound familiar? The hard truth is that you are a micromanager. Really. The good news is, you can't help it - it's how you're wired, and nobody blames you...(well, I don't, anyway).

A solution:

Eventually, this behavior is brought to your attention (by a friend, Human Resources, whatever), and being such an evolved and emotionally mature person, you accept this feedback and decide to take action.

As a newly self-aware person, you understand that, while it's OK to believe that folks are doing it all wrong, it's not OK to share this insight. You learn that, while you cannot change what you believe, you can change your behavior.

With this new understanding, you back off, and let your folks figure out what works for them. Your new plan of operation:

  • set achievable goals and deadlines for staffers
  • ask for (and listen to) feedback
  • remove roadblocks to support staff efficiency

Moral of the story:

Whether you are a manager or supervisor, if you have the ability to affect the work life of anyone in your organization, it is important to remember that, like the Talosians in Star Trek: The Cage, it is important to maintain the illusion of control.

Not a Star Trek fan? Here's the non-geek Moral of the story:

Give your staffers control (or the illusion of control) over things that affect how they work. Do they need...better status updates...fewer meetings...blue pens?

Ask them what they need to be effective - gather their requirements. They'll usually tell you things you never expect to hear. Things that cost you little, and reap big benefits.



Thursday, April 9, 2009

Change is Good...right?

When we buy something new, we generally know what we're getting: something newer, cooler, faster. Whether it's a breakfast cereal or a car, it's better in some way, and we're excited, because it's all upside. The cereal has bigger, crunchier bits. The car has great lines, goes fast and gets you from place to place, in style. What's not to like? It's the same, but better. 




Folks everywhere become accustomed to doing things a certain way, and so have the expectation that things will improve, but stay the same. New, improved cereal with nuts and berries? I'll take a box! New, improved tofu cereal in a tube? Not so much.



In the business world, and with software in particular, it can take weeks to learn a new system and get back to doing work efficiently. Think about the growing pains organizations endure when they convert from a (home-grown) legacy software system to a new system (like a financial application for purchasing /payroll /reimbursements, or a human resources system to manage personnel records, benefits and training certifications). To a user, it's like buying a new car and finding the accelerator and brake pedals are swapped - yikes!


With new systems, users must get up to speed quickly in order to meet goals and quotas. While users are generally willing to accept the new new thing, they don't expect to have to re-learn everything - it slows them down and they may actually break something during the learning process. No one likes to fail. No one likes to lose control. 




The typical solution is something called "Change Management". When done right, CM introduces someone to the project who is familiar with user needs and the project goals, and has responsibility for building a bridge between the "app that was" and the "system that will be". These folks are communicators, and do the heavy lifting to build the means to transition users to the new system. 


Depending on the nature and complexity of the system, CM can be as easy as a cheat-sheet taped to the monitor, or as complex as a month-long training program for users, managers and administrators. The method varies, but the goal is the same...define how to transition from "X" to "Y", and provide users with the tools they need to become effective in a new applications environment.


It's all about setting goals, planning and communicating:

  • check in often to keep everyone in the loop
  • a whiteboard mock-up is more reassuring than a multiple-page email
  • be comfortable saying, "...I/we don't know yet..."
  • listen and accept all forms of feedback (good, bad or otherwise)