Part 16 - When going out into the Universe, remember: "Boldly go where no man has gone before!"

(This is part 16 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.)

Every episode of the original Star Trek began with the proclamation to "Boldly go where no man has gone before!" For folks working with technology, this statement is a natural assumption. But there are two caveats.

First, I’m a big believer in early to beta, late to production. What I mean is that it is good to experiment with new technologies in beta test mode. But we have an obligation to our organizations to treat production as sacred. Experiment to learn but be cautious about what you give to your clients who trust you for reliable production-ready solutions. No matter how much we like cool new toys; we must ensure they will work reliably in production.

For example, I worked at a Canadian organization where one of our peers moved some services to a foreign cloud computing service. At the time there were huge potential privacy and legislative compliance concerns about moving personal data out of the country. Although we wanted to do something similar, the legal and technical analysis was expensive and time consuming.

Pioneers have arrows in their backs, so we let them go first. They figured out the privacy issues, they sorted out legislation concerns, and they pioneered the first contract of its type in Canada. Once the first-mover problems were sorted out, the way was paved for cheaper, quicker, and less painful implementation at other similar organizations.

That was caveat #1. The second caveat is related to the time and period when the original Star Trek was aired. It was a product of the mid 1960's when political correctness was only beginning. You should boldly go where no person has gone before!

~

Part 15 - Even in our own world, sometimes we are aliens.

(This is part 15 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.)

In any IT environment you always face a vast array of varying technologies. With many different technologies you will be faced with many different subject matter experts. For example, almost all IT shops have a mixture of Windows and Linux servers. If you are an expert in one area you will inevitably be an “alien” in terms of technical expertise in another area. As a manager, you can’t know everything about every technology. So invest your own intellectual capital wisely. Become an expert in the high priority stuff and let someone else learn the rest.

The hardest part of moving into a leadership role in IT is to let go of technical skills, but the temptation to help out is always there. One evening I was working late and one of our programmers was trying to solve a nasty mainframe data conversion issue (we were running a project to shutdown the mainframe). Since I used to have some mainframe skills I offered to take a look at the problem. Together we solved the problem, which was good. Unfortunately, he told everyone else, and that was bad. The last thing I wanted was other folks asking me for help with their mainframe problems. So sometimes it is good to be the alien!

But when dealing with your clients, you don’t want to be an alien. You want them to feel like you’re one of them. You want them to feel like you’re on their side. I strongly recommend looking for ways to lose the alien “IT guy” tag. Build partnerships and positive relationships anywhere and everywhere you can.

As an example, we had initiated a statistical analysis reporting project. We worked closely with the business unit to build a development environment and reporting system. Their folks and our folks worked as a single team to deliver systems such as an interactive reporting cube that was ecstatically well received by our clients. We were a success because we were a team and not aliens. From a client point of view you couldn't tell the difference between the business unit and IT staff. First prize.

Another example was a desktop standardization project. Information Systems, Accounting, Purchasing, and Advancement all worked together to set standards for an organization-wide computer purchasing process. We developed a process that we all had a stake in. There were computing standards that fit our IT architecture. The ongoing acquisition model streamlined the purchasing process. The transaction processing model met the accounting group’s needs and the strategic alliance with the vendor met Advancement’s needs. We merged four very different “alien” cultures into a single team to develop a model that benefited the entire organization.

For those times when you are working closely with your customers, you must overcome that “alien” label. When you need to distance yourself from the day-to-day technical details, it can be useful to be an alien. As a manager, the trick is to know when to be an alien and when not to be.

~

Part 14 - If it can't be fixed, just ask Scotty.

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

~

Part 13 - Insufficient data does not compute.

(This is part 13 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.)

Although insufficient data does not compute, a key management lesson from Star Trek is that often you must make decisions with insufficient data. You can’t move forward if you don’t make decisions. You will never have all the information, so you need to make decisions with enough information. Insufficient data may not compute, but as a leader, usually that is all you have to work with and you need to make the best of it.

The trick is to understand what is “enough”. As IT folks we are rational and logical so it is hard to make major decisions without all the data. For example, at my university we completed a brand new state-of-the-art data centre. Development of the business case was a challenge because it was a multi-million dollar decision. The existing data centre was out of space, power, and air conditioning because of explosive growth in research computing. Yet we wanted to develop a computing facility to attract new researchers to meet the university’s mission.

Before we could proceed, the board had two questions. First, why did we need a new data centre? Second, how big should it be? “Why” was easy. We had all the facts about why our existing data centre was too small. We drove the point home by giving the board a tour of the old data centre before we asked for any money. After the tour the board chair, who was non-technical, came out and was quite surprised. She said to me “I thought I just turned on my computer in the morning and it all just worked. I didn’t realize we needed all this. And by the way, it looks like you guys haven’t got anymore room!” That tour made the basic business case an easier sell.

“How big” was much tougher to answer because it was based on future predictions. Forecasting in a university environment has many problems. Research grants vary dramatically from year-to-year, so demand is unpredictable. Over long periods of time fundamental hardware technology requirements change such as mainframes to standalone servers to rack-based blades. Trends such as virtualization and cloud computing may dramatically alter what currently looks like a continuous growth curve.

With all that variability, our best guess said we needed about 5,000 sq. ft. over 5 years based on trends. After that, all bets were off. There is no way we had enough information to draw any conclusions past that time frame. But we didn’t want to build another data centre 5 years from now. So we did not have an air tight forecast. We decided to build a 10,000 sq. ft. building with one-half built as a data centre. The second half was setup as warehouse space that could be converted as needed to a data centre.

The result: in 9 months we filled 35% of the data centre. At that rate the built-out half of the data centre will be completely filled in 3 years, not 5 years! Because we included the additional warehouse space we have a contingency built in to handle what will likely be an overflow sooner rather than later.

We did not have all the information, it was a multi-million dollar decision, and we moved forward without being paralyzed by indecision. Based on the current utilization rate, we are glad we did. If we had not made a decision we would have lost significant amounts of research funding.

Insufficient data may not compute, but that does not mean you cannot make a good decision.

~

Part 12 - When your logic fails, trust a hunch.

(This is part 12 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.)

By observing Star Trek's Captain Kirk we inevitably learn that when your logic fails, trust a hunch. This is great advice for IT leaders when fixing stubborn problems. But you need to take it to the next level. You should always make decisions in three places: your head, your heart, and your stomach. The head is logic. The heart is emotion. The stomach is intuition (“gut” feeling). All three must be aligned and in agreement.

Now here’s the part that bugs IT folks: logic is not enough. Getting comfortable tapping into all three of these decision-making inputs is tough for IT folks who are typically completely reliant on logic, day-in and day-out, to solve computer problems. But leadership is very different. You never have all the information at your fingertips. You usually have shades of grey. That is where emotion and intuition come into play.

I had an interesting decision to make several years ago. I worked in a university where the learning management system (LMS) strategy was inadvertently “one of each.” We had major implementations of six different products across campus. It seemed like every department had it own favourite and we had one of every possible learning management systems available. Needless to say, it was a very expensive situation and no one appeared willing to compromise.

However, I noticed we had some pockets of strong support for a particular open source product. I also had someone on my team who was excited about championing that product. We did our homework and our best guess was that this product looked like a winner. It seemed to be getting more popular throughout the industry and the product looked like it was pulling away from the pack, but only a little bit at the time. There were concerns. It was open source software and there were a number of risks and unknowns associated with that type of product at the time. I was also nervous because we didn’t have a lot of experience in this area. On the other hand, the vendor support for from our largest proprietary LMS vendor was disastrous and we needed another solution.

In summary, my head said: “we are seeing a trend, but nothing definitive.” My heart said: “there are a lot of people I trust who are advocates.” My gut said: “we need to do something now.” Putting it all together, my hunch was: let’s invest in the open source system. So we bought a server, gave my product zealot a full time job, and launched a pilot with 15 courses. Within 2 years we had 400 courses on the new system – more than any other LMS on campus! Plus, the total number of LMS supported courses grew by 50%. This meant faculty were not only adapting quickly to the new system, but more faculty were generally willing to use an IT tool to enhance teaching of their courses. By the end of 3 years we had nearly 1,000 courses on the new system. The total number of LMS enhanced courses grew dramatically and many LMS users voted with their feet by moving to the new system.

This original “hunch” led the university to recognize the need to move from the old “one of each” strategy. By the fourth year, the user community chose to make the new system the standard learning management system on campus. We had moved from "one of each" to one.

In any decision, you need to make sure your head, your heart, and your stomach are all telling you the same story. Then trust your hunch, invest in it, and support it!

Part 11 - Don't put all your ranking officers in one shuttlecraft.

(This is part 11 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.)

According to Star Trek you should never put all your ranking officers in one shuttlecraft. If we were to apply this rule to management, I would suggest this rule is about diversifying your risk while at the same time learning from the diversification.

We don’t normally use shuttlecraft at work, but I like to think this rule is about making sure your leadership team isn’t all thinking the same way. In other words, diversify your risk by diversifying your team. Look for ways to avoid groupthink. Look for ways to prevent your whole team from having a similar mindset and doing everything the same way. Create a leadership team of differing personalities. You want a leadership team with broad perspectives and unique problem solving techniques.

For you as their leader it makes your job harder in the short term because you need to blend a very diverse set of skills. But it is easier in the long term because you get more bandwidth and capacity to handle a broader range of complex issues. Varying perspectives may require more effort to coordinate, but they keep you out of trouble and help prevent bad, narrow-minded decisions.

I worked for a manager early on in my career who insisted that everyone on his software development team have a computer science degree from the same university. With that sort of similar background we were able to gain consensus very easily and quickly. But we had a very narrow view of the world. That tendency prevented us from trying different approaches and solutions.

As a team, we came up with technologically innovative algorithms and elegant back-end systems. But none of us had any user interface design experience or training. Our brilliant solutions were nearly impossible to use by normal human beings. Diverse skills and attitudes would have prevented this problem from happening.

So don’t use one shuttle craft, use many. Spread out your risk and learn from a multitude of different voices. Voices whose hearts and souls come from very different places to sing together in one choir. As a manager, your role is the conductor, the teacher, and the mentor who builds the choir.

~

Part 10 - Enemies are often invisible – like Romulans, they can be cloaked.

(This is part 10 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.)

In Star Trek there was a defensive technology called a “Romulan Cloaking Device” that made their ships invisible to their enemies, much like Harry Potter’s invisibility cloak. From an IT perspective, you need to be aware that your enemies are often invisible. Like Romulans, they can be cloaked.

Viruses, spam, and malware are similar to Romulans. They can be cloaked, yet they can be defeated. But you can’t defeat them with just technology. Admittedly, you need great technology, but you also need to fight the battle on multiple fronts. The interesting lesson from Star Trek is that it is not just a technology game. There are three non-technical soft tools that can dramatically enhance your defensive posture: policy, communications, and coordination.

Let me explain what I mean by policy. You need an organization-wide level security policy giving you the right to enforce IT security (I’ve talked a little about this in Part 3 - Keep your phaser set on stun). To get the mandate to do something like this can be tough. My experience is to ask for an external security audit. You might think that is a bad idea because we all know how potentially vulnerable any infrastructure can be to determined security threats. Such a study might be embarrassing. But my advice is let the auditors be as negative as possible because it gives you, the IT leader, the ammunition necessary to request greater security authority through policy measures.

The second soft skill is communication. For example, prevent phishing attacks through education about never giving out passwords. I tell folks not to tell anybody their password. IT already knows your password, so why would we ask for it? You can’t over communicate this point. Phishing attacks are daily and they are increasingly sophisticated and focused. Spammers are taking the time to learn more about your environment and make the phishing messages more realistic all the time – including using your own logos and timing the attack to coincide with planned system outages. So I advocate communicating relentlessly about security issues.

The third soft skill is coordination. Integrate closely with your non-central IT folks to work together to fight campus threats. At my organization we had a team of folks from central IT and otherwise that worked together as an extended security team coordinated by our central IT security manager.

Most importantly, in many of my favourite Star Trek episodes, Captain Kirk didn’t win battles with superior technology. Quite often he ran into aliens with far superior technology. But he won his battles by outwitting them.

As a matter of fact, Star Trek isn’t an enduring TV show and movie franchise because it is cool science fiction. It is a success because it focused on our humanity and not on technology. The technology was often a gimmick to facilitate the human story. For example, the transporter beam was invented by the writers to conveniently switch scenes as part of a story telling technique. So keep your wits about you and do not let a cloaking device or any other advanced technology fool you.

~