(This is part 14 in a series of 16 posts about IT leadership in higher education titled Everything I Need to Know about IT Management I Learned from Star Trek. See Part 0 - Introduction for the full list.)
The Starship Enterprise, Scotty the engineer was the technology "goto" guy. If anything broke, everyone relied on Scotty to fix it. He could fix a warp engine with duct tape while the universe seemingly imploded around him. Every IT department also typically has a technology "goto" person. Some places call her or him the "architect." Other places may simply say the "guru." At previous organization I worked at, he was called Ron, not Scotty.
It's good to have someone like that as long as Scotty isn’t a one-person show. The real concern here is with single expert syndrome. Scotty needs backup. But Scotty is a rare breed, hard to find, and you can’t always afford two in a cost-conscious IT environment. So there are a couple of solutions. First, create resource pools to enhance knowledge sharing. Second, recognize that heroes are bad.
Let me explain the hero problem first. We all love Scotty from Star Trek because he solves seemingly impossible situations with innovative solutions. But these are exceptional circumstances. Situations that have never been experienced before and cannot be predicted nor planned for.
The problem in an IT shop is that we are not travelling through strange new worlds. In our world, a hero is an indicator of a bad thing. It reflects a lack of process. We are all familiar with the classes of problems that occur in IT and there should be a process in place to handle these problems. If you need a hero, it means you don’t have a good process. Ron was a superstar because be puts process in place to deal with major systems outages, or as he liked to call them “technology appreciation events.”
Another example is the project management process we implemented. There were no project managers who were heroes. We had project managers who were superstars because they excelled at executing our project management processes.
The resource pool idea solves a key staffing issue. Depending on the size of your organization, you may not have the kind of funding that is available in large banks or insurance companies to hire in depth to create redundancy of key positions. You need to do the next best thing and create resource pools. Software development groups and other project-driven organizations can benefit from such a structure.
In a resource pool, each key functional area is assigned a notional allocation of developer person-days. No names are specifically allocated. Bob isn’t permanently assigned to Finance and Betty isn’t permanently assigned to Student. They belong to a shared pool supporting all administrative systems. That way you have the option to move people around at your discretion.
This approach increases staff personal development opportunities because they learn more systems and technologies allowing you to grow the intellectual capital of your organization and give you greater depth. It also keeps your staff happy and growing so they’re more interested in their jobs. From a management perspective it gives you greater depth to cover multiple systems with a limited staff size. It also gives you the ability to adapt to changing demands across multiple client groups. Finally, it prevents your clients from developing the mistaken idea that they control specific resources (such as Bob always works for Finance, so Finance begins to think they own him).
In conclusion, it is okay to have a Scotty, but be wary when someone says Scotty is a hero! He needs to be part of team with folks who can fill his shoes when the need arises.
~
No comments:
Post a Comment