Everything I Need to Know about IT Management I Learned from "Star Trek"

Key Takeaways

• Given the technical and budgetary challenges facing higher education institutions, Star Trek's basic lessons are especially relevant for IT leaders today.
• Several rules relate to dealing with diverse civilizations and can inform relationships within an IT department as well as those between IT staffers and alien creatures in the larger institutional environment.
• Timely decision making — often with incomplete information — is crucial in outer space; studying Star Trek strategies can also facilitate better decision making here on earth.

As the chief information officer at a large university, I spoke to many different types of audiences, but the ones I enjoyed the most were made up of students. I once explained to a roomful of students what a CIO does at the university, after which one of the students exclaimed, "Oh, I get it — you're the head geek!"

That gave me the idea to link everyone's favorite geek TV show, "Star Trek," to some leadership lessons for the real world. These basic leadership lessons have universal applicability, but are particularly relevant for IT in higher education.

Putting Star Trek's 16 Rules into Practice

Now, I have to admit, I am a huge Trekkie (a.k.a., Star Trek fan). In fact, I even own a poster with one of my favorite rule lists, "Everything I needed to know about life I learned from Star Trek." (I told you I was a geek.) That knowledge is summed up in 16 rules:

1. Non-interference is the Prime Directive.
2. Seek out new life and new civilizations.
3. Keep your phaser set on stun.
4. Humans are highly illogical.
5. There's no such thing as a Vulcan death grip.
6. Live long and prosper.
7. Having is not so pleasing a thing as wanting; it is not logical but it is often true.
8. Infinite diversity in infinite combinations.
9. Tribbles hate Klingons (and Klingons hate Tribbles).
10. Enemies are often invisible — like Romulans, they can be cloaked.
11. Don't put all your ranking officers in one shuttlecraft.
12. When your logic fails, trust a hunch.
13. Insufficient data does not compute.
14. If it can't be fixed, just ask Scotty.
15. Even in our own world, sometimes we are aliens.
16. When going out into the Universe, remember: "Boldly go where no man has gone before!"

The longer this poster hung on my wall, the more I wondered, How do these rules apply to creating digital information systems solutions at a university? I developed some interesting answers to this question, created a presentation on them, and eventually wrote a series of blog posts to address the question in more detail. This article is an attempt to bring these ideas together and connect them to IT leadership challenges in higher education. I hope you have as much fun reading this as I had writing it.

Non-Interference is the Prime Directive

In Star Trek, the Prime Directive dictates that there can be no interference with the internal development of other civilizations. Most university environments have a central IT group and many smaller distributed IT shops; to me, our prime directive is to support and allow these multiple computing cultures to grow on campus.

My advice to the leaders in the central IT organization is to compete in your core competencies and cooperate everywhere else. A core competency is a service that you can perform more efficiently than anyone else on campus. As the central group, part of your role is to help the distributed IT organizations perform their localized specializations more efficiently. For example, we introduced a single e-mail, calendar, and collaboration tool to our campus, which let many distributed IT groups shut down their standalone e-mail systems. The centralized system let the distributed IT folks stop worrying about administering mail and focus on IT services that directly improved their functional areas, and it gave the centralized service greater economies of scale and scope.

To help with these types of initiatives, we created the Campus Systems Council, which hosts monthly meetings of leaders from distributed IT groups across campus. These meetings update attendees on the central IT group's activities and inform them of technology changes, as well as let distributed groups offer updates on their activities. The meetings are a great forum for communication and have helped build trust among various IT tribes across campus.

If you work for a central IT department, non-interference should be your prime directive when it comes to other good IT work on campus outside of your core competencies. If you want to get involved, look for ways to nurture and support the distributed folks. As a result, the institution benefits from optimal use of its IT resources.

Seek Out New Life and New Civilizations

For IT folks, the Star Trek rule "seek out new life and new civilizations" means there are always new technologies available, so experiment, play, and learn from them.

A great example of this rule in action was my university's "Click-to-Call" project. One of our network leaders came to me one day with what appeared to be a crazy idea: establishing a web page hyperlink that let anyone, anywhere call anyone at the university for free from a web-attached computer. At the time, the idea seemed far-fetched, and we struggled with it. Preferring to foster a culture of innovation, we piloted it, tested it extensively, talked to our clients about its potential uses, and six months later became the first university in the world to implement this "crazy" idea.

What made this new idea so interesting was its impact on four areas of our business:

1. We put an instant phone link on our Admissions web page so foreign students and parents could call the university for free to get information. Thus, the tool could help us grow enrollment.
2. Researchers could telephone their colleagues at our university for no cost. The tool thereby supported the university in its strategic mission to become a research-intensive institution.
3. Looking up phone numbers on our Directory web page led users to Click-to-Call, which connected callers directly. The new capability improved the institution's efficiency in a simple way.
4. E-mail tag lines made it easier to return messages with a quick person-to-person call. I had this link to my phone embedded in my e-mail signature and often got calls through this mechanism from folks who were traveling and didn't want to use a hotel phone or incur cell phone roaming charges.

Our university learned a lot from this Star Trek rule. Our primary discovery was the huge business value in seeking out new life and new civilizations; or, in other words, in always being on the lookout for new opportunities.

Now, I have to admit, I've noticed one drawback to the Click-to-Call system: callers sometimes try to use it without a microphone and speaker on their computers. Clearly, nothing is perfect — and you should never ignore the human element!

Keep Your Phaser Set on Stun

For those unfamiliar with Star Trek, "phasers" are the weapon of choice in the future. A university's central IT department can wield a certain amount of control and influence on campus; the application of this influence should be governed by rules similar to those covering phaser use in Star Trek.

IT's power must be used wisely, so keep it set on stun. In a university culture, there are few rules about what computing you can and cannot use, but there must be some policy around things like standards and security. My advice is to play nice, but don't tolerate complaints caused when someone consciously chooses not to follow your standards.

For example, at my university we implemented an imaging and workflow project. The big problem was the multiple types of desktop computers on campus. The rough breakdown was 30 percent Mac, 60 percent Windows, and 10 percent "other." To make matters more interesting, most machines had a unique software image, so even Windows PCs weren't "standard."

When we rolled out the new imaging and workflow software, Macs didn't work, many PCs had problems, and … don't even ask about Linux! The project had huge implementation problems. Software and hardware variety across campus made it nearly impossible to deploy enterprise software quickly and efficiently. Serious concerns were raised about the project and the software quality.

Instead of reacting in a knee-jerk manner, we stepped back and looked at the big picture. In a university culture,

Freedom of Choice + Academic Independence = High Cost + Loss of Functionality

We decided to use this to our advantage, stating that if folks across campus wanted to make their own choices about desktops, then the issues with the imaging and workflow software would be the price they paid. We used the problematic results of the project to help justify a desktop standardization program across campus that both administrative and academic leaders supported. By setting our phasers on stun, we turned a nasty problem into an opportunity.

Another example of this Star Trek rule relates to enforcing IT security. Traditional passive policies that let you take action only after a security issue occurs are too dangerous to the network. In contrast, proactive polices let you act as soon as a possible security issue is detected. The danger is that proactive policies are very powerful. Like a phaser set on kill, if you use such policies indiscriminately, you will do more harm than good. If you shut down someone's computer access arbitrarily without warning, you will destroy any future relationship with that person. My advice is to apply proactive policies only as the last resort, using a threat of shutdown to convince users to upgrade or fix their potential security issues. You can have the policy in your back pocket, but don't use it unless you must. In other words, try to keep your phasers on stun wherever you go on campus.

Of course, there are times to consider breaking this rule. Sometimes you need your phaser set on something more potent. Several years ago, I had been working closely with a department to develop a business case for implementing a multimillion-dollar system. Everything seemed to be going well until the clients told me they would hire their own people to perform ongoing support and maintenance of the system and manage it independently of the rest of IT. That's when we set our phasers on kill — we stopped the project dead. They backed down, and we were all a happy family again.

Humans Are Highly Illogical

Mr. Spock, first officer on the starship Enterprise, was a Vulcan and came from a culture that prized pure rationality. A logician, he found human emotions sometimes amusing and always perplexing.

Several years ago, I did a Myers-Briggs personality assessment of a software development team, a dysfunctional organization with considerable interpersonal conflict that I had just assumed responsibility for managing. I hired an external facilitator and brought a roomful of 30 IT people together for a day-long assessment process. I came in at the end of the session to ask about their experiences during the day and what they thought about the results.

Standing up front, I asked the participants for their opinions. No one said a word. So, I flipped over the chart that mapped out the personality types of everyone in the room to get the conversation going. Although Myers-Briggs has 16 personality classes, this entire software development department — and I mean everyone — was classified as "INTJ." Basically, they were introverted, shy, risk-adverse perfectionists. Of course no one was willing to publicly volunteer an opinion.

Introverts tend to migrate towards IT careers, which makes IT departments a different management challenge than marketing departments. Your job as a leader is to mentor and coach them on relationship building, bridge building, and continuous open communications with their customers. Look for opportunities to pry your introverts away from their computers and help them see the value in socializing with their clients. In IT, leadership means managing humans' highly illogical nature.

There's No Such Thing as a Vulcan Death Grip

For folks unfamiliar with obscure Star Trek episodes, Spock used the so-called "Vulcan death grip" on Captain Kirk to fool the hostile Romulans into believing Kirk was dead so they could escape. Afterward, when informed of the incident, the ship's nurse exclaimed, "But there's no such thing as a Vulcan death grip." Kirk replied that the Romulans did not know that.

In translating this Star Trek lesson to IT, I urge caution. I've seen numerous IT folks try to baffle nontechnical clients with technical jargon. Nobody likes being talked down to, and nobody likes being deceived. Don't pretend IT can perform magic; always give your clients plain English explanations.

When I interview technical people, my favorite question is: How would you explain a compiler to your grandmother? The best people I've ever hired are the ones who answered that question in plain terms. If you can't do that, you shouldn't be in a client-facing IT department (and, in my opinion, we all have clients). In case you're wondering, the best answer to this question I ever heard was, "It takes words we understand and translates them into words a computer can understand."

Another example, with a not very happy ending, occurred when I worked at an insurance company. In our infrastructure department, we had people who tried to use the Vulcan death grip approach on their clients and acted like high priests of technology. They used their knowledge as power in the organization; instead of working with clients to develop solutions, they used their knowledge to dictate solutions to their clients — that is, they used their power for evil rather than good. They annoyed the organization so badly that it completely outsourced their jobs.

Live Long and Prosper

To me, applying the Star Trek rule of "Live long and prosper" (Spock's typical greeting) to IT means to look for long-term, quality solutions, not quick and dirty ones.

Sometimes, for example, a piece of software code can remain in production for an amazingly long period of time. I wrote the code for a really large logistics system back in the 1980s. A few years ago, I found out that a heavily modified version of my code was still running in production. My basic code has lived long and prospered. It wasn't brilliant or creative programming, and it wasn't going to win any innovation awards. It was just painstakingly tested, with excruciatingly simplified logic. And it still works. I'm kind of proud of that.

I think the lesson here for IT is that we need to focus more on the long term and on the quality of what we do. It is not about the latest technology — it is about doing it right. Let's face it: we do tend to be trend-hoppers in IT, constantly moving to the latest next best thing. That attitude doesn't do our clients any favors.

I'm also a big fan of mitigating unnecessary risks. I used to work for a CIO who said, "Pioneers have arrows in their backs." What he meant by that was, let other people take the chances. We'll learn from them and build things using reliable methods and processes aimed at creating high-quality results. Doing so is the best way for your systems to live long and prosper.

It is also the best way to keep your job. I've seen too many IT leaders get caught up in a vendor's exciting sales pitch about the latest and newest technology. They try implementing something new so they can be the first — and they end up being the first fired because the technology's kinks weren't yet worked out. Focus on long-term quality, and you will live long and prosper.

"Having Is Not So Pleasing a Thing as Wanting; It Is Not Logical but It Is Often True"

This advice came from Spock when he was giving away a valued possession to someone who desperately longed for it. From an IT perspective, it is easier to dream about a new system than actually build it.

As I noted earlier, my university included a mixture of Windows, Mac, and Linux. Nearly every desktop image was unique. I liked to say we supported "desktop multiculturalism."

But I had a dream — the "anyplace desktop." In this dream, we would deliver a standard virtual desktop productivity environment to any personal computing device, whether a laptop, desktop, smartphone, or whatever. It would therefore be much easier for us to roll out enterprise applications. We would use server-based terminal services to deliver the environment.

It was a great dream. We piloted it in a few places across campus. Reality, however, was much harder. Complexity in the backend server implementation forced us to re-think our approach. Ideas are easy; implementation is hard. So we moved to a different strategy, based on managed desktops, in the short term. While admitting our failure with the anyplace desktop idea, we did not spend much time on it — and we did not dwell on it. We learned and moved on, with the idea of coming back to it when the technology was ready.

Desire is useful. It helps us to reach for the top — and, even if we miss, we still grow. Another example is the vision we set for ourselves at my university: "We will be the best Canadian university information systems department." We set the bar high, and it always gave us something to shoot for. "Wanting" is good; dream big or go home!

Infinite Diversity in Infinite Combinations

The Star Trek world celebrated and supported a vast array of cultures and variables in existence throughout the universe. They summarized this belief in the phrase "infinite diversity in infinite combinations." To an IT department, infinite diversity in infinite combinations means "one size fits none." Specifically, I'm thinking of vendor-written ERP systems, which are a particular challenge.

In the old days, we used to handcraft systems, building them from the ground up and custom tailoring them to fit every process and client nuance in the organization. Our legacy systems naturally met our needs perfectly. Today, we can't afford that approach. I've heard estimates that to build a new student information system from scratch for a medium-sized university would cost tens of millions of dollars. It would be perfectly customized to meet the demands of every one of the organization's existing processes — but it would bankrupt the organization.

Instead of building our own unique systems, we buy industry-specific solutions, such as ERPs. The problem with vendor-written ERPs is that they're built to meet generic organizational needs. That is, they try to be one size fits all, but in reality, one size fits nothing.

This situation creates a new problem: Should you massively customize the product or implement it off-the-shelf and change your existing processes? The answer is typically somewhere in between, and every organization's solution will be different.

Whatever degree of customization your organization decides on, the role of IT changes. Given today's financial constraints, IT leaders must emphasize integration over building from scratch. The days of handcrafting systems are over, and the complexity of "one size fits none" requires new skills. As IT leaders, we need integration skills to manage infinite diversity in infinite combinations. That's a tall order, but no one said the job was easy.

Tribbles Hate Klingons (and Klingons Hate Tribbles)

In Star Trek, Tribbles are small, soft, gentle creatures that produce a soothing purring sound. These traits are said to endear them to everyone they encounter, with the notable exception of Klingons, who consider Tribbles "mortal enemies" of the Klingon Empire. Roughly translated, if you don't like someone, odds are, they don't like you either. So, don't go around campus making enemies. Work on building friendships and constantly improving relationships.

At my university, the Information Systems department used to be called "Computing and Systems Services," so CASS was the acronym. But everyone across campus called the department "Fortress CASS" or "Fort CASS." Needless to say, it wasn't a popular department. As a new CIO, my job was to knock down the walls and bridge the moat to the rest of the campus. To do that, you have to be transparent — no secrets. We became transparent by actively engaging the campus in information systems decision making through a broad governance process — we asked clients what they wanted and made it happen as promised. Basically, you do what you said you would do.

Our governance process was in place for five years; our clients made the IT business decisions, and our central IT department simply facilitated the process. We were neutral about the business decisions as long as they had fit, utility, and balance:

• Fit means the decision aligns with the university's overall strategic plan.
• Utility means the quantitative and qualitative benefits outweigh the costs and risks.
• Balance means you treat your IT projects like an investment portfolio that's appropriately weighted across the institution.

Combining this governance model with a robust project management culture has been key in building bridges and developing trust across campus. Building trust takes time, but eventually even Klingons and Tribbles can learn to trust each other.

Enemies Are Often Invisible — Like Romulans, They Can Be Cloaked

In Star Trek a defensive technology called a "Romulan Cloaking Device" made Romulan 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 — think of viruses, spam, and malware. Although cloaked, they can be defeated. However, you can't defeat them with just technology; 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. To dramatically enhance your defensive posture, you need three nontechnical soft tools: policy, communications, and coordination.

• By policy, I mean a university-wide security policy that gives you the right to enforce campus-wide IT security (which I touched on earlier). Obtaining the mandate to do something like this can be tough in a university environment. In my experience, it's helpful to ask for an external security audit. This might seem like a bad idea; we all know how potentially vulnerable a university can be to determined security threats, and such a study might be embarrassing. My advice is let the auditors be as negative as possible because it gives you, the IT leader, the ammunition needed to request greater security authority through policy measures.
• The second soft skill is communication. For example, you can help prevent phishing attacks by educating users to never give out their passwords. I told folks on campus not to give anybody their password, including our staff members. (IT already knows your password, so why would we ask for it?) You can't over-communicate this point. Phishing attacks are increasingly sophisticated and focused. Spammers are constantly learning more about your environment and make the phishing messages more realistic all the time — including using university 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 so you can work together to fight campus threats. At my organization, we had a team of folks from central IT and distributed IT departments that worked together as an extended security team coordinated by the central IT security manager.

In many of my favorite Star Trek episodes, Captain Kirk didn't win battles with superior technology; he often ran into aliens with far superior technology. But he won his battles by outwitting them. Star Trek is a success because it focused on our humanity, not on technology. The technology was often a gimmick to facilitate the human story. So keep your wits about you, and don't let a cloaking device or any other advanced technology fool you.

Don't Put All Your Ranking Officers in One Shuttlecraft

According to Star Trek you should never put all of your ranking officers in one shuttlecraft. In IT management, I interpret this rule as being about diversifying your risk while at the same time learning from the diversification.

The key to applying this rule is to make 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 or having a team of people who do everything the same way. Create a leadership team of people with different personalities, broad perspectives, and unique problem-solving techniques.

As the leader, this makes your job harder in the short term because you need to blend a highly diverse set of skills. Your job is easier in the long term, however, because you get more bandwidth and capacity to handle a broader range of complex issues. Varying perspectives might require more effort to coordinate, but they keep you out of trouble and help prevent bad, narrow-minded decisions.

Early in my career I worked for a manager who insisted that everyone on his software development team have a computer science degree from the same university. Given this common background, we were able to gain consensus very easily and quickly. But we also had a very narrow view of the world that 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. As a result, our brilliant solutions were nearly impossible for normal human beings to use.

Don't use one shuttle craft; use many. Spread out your risk and learn from a multitude of different voices that come from very different places to sing together in one choir. As a manager, your role is to be the conductor, the teacher, and the mentor who builds that choir.

When Your Logic Fails, Trust a Hunch

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 facing 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. All three must be in agreement.

The part of this rule that bugs IT folks is that logic is not enough. Getting comfortable tapping into all three of these decision-making inputs is tough for people who typically rely completely on logic to solve computer problems. But leadership is very different: You never have all the information at your fingertips, and you usually have to deal with shades of gray. 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 LMS products across campus, and it seemed like every department had its favorite. Needless to say, it was a very expensive situation, and no one seemed willing to compromise.

However, I noticed that we had pockets of strong support for a particular open-source product. I also had someone on my team who was excited about championing that product. After doing our homework, this product looked like a winner. It seemed to be getting more popular throughout the industry and was pulling away from the pack, but only by a bit at that time. Also, we had some concerns. Back then, there were many risks and unknowns associated with open-source software. I was also nervous because we didn't have a lot of open-source experience. On the other hand, the vendor support for our largest proprietary LMS was disastrous, and we needed another solution.

My internal dialogue on the issues was as follows:

Head: "We are seeing a trend, but nothing definitive."

Heart: "There are a lot of people I trust who are advocates."

Stomach: "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 two 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 percent. This meant that faculty members were not only adapting quickly to the new system, but that more of them were generally willing to use an IT tool to enhance their teaching. After three years, we had nearly 1,000 courses on the new system. By the fourth year, the client community chose to make the new system the university's standard LMS, moving us from "one of each" to one.

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

Insufficient Data Does Not Compute

A key management lesson from Star Trek is that you often must make decisions with insufficient data. After all, you can't move forward if you don't make decisions. You will never have all the information, so you need to settle for making decisions with enough information. Insufficient data may not compute, but as a leader, it is usually all you have to work with.

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 the existing data center was out of space, power, and air conditioning because of explosive growth in research computing, yet we wanted to attract new researchers to meet the university's mission — so we needed to develop a new computing facility. Development of the business case for a brand-new, state-of-the-art data center was a challenge because it was a multimillion-dollar project.

Before we could proceed, the University Board had two questions. First, Why did we need a new data center? Second, How big should it be? The "why" was easy. We had all the facts about why our existing data center was too small. We drove the point home by giving board members a tour of the old data center before we asked for any money. After the tour, the board chair (who was nontechnical) 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 any more 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 time periods, fundamental hardware technology requirements change, as when mainframes changed to standalone servers and those changed to rack-based blades. Also, trends such as virtualization and cloud computing might dramatically alter what currently looks like a continuous growth curve.

With all that variability, our best guess based on trends was that we needed about 5,000 square feet over five years. After that, all bets were off as there was no way to draw any conclusions beyond that time frame. Still, we didn't want to build another data center five years later, so we decided to build a 10,000 square-foot building, using half of it as a data center. The other half was set up as warehouse space that we could convert to a data center as needed.

The result: in nine months we filled 35 percent of the data center. At that rate, the built-out half of the data center would be completely filled in three, rather than five years. Because we included the additional warehouse space, we had a built-in contingency to handle an overflow likely to occur sooner rather than later.

To recap, we did not have all the information we wanted, it was a multimillion- dollar decision, and we moved forward without being paralyzed by indecision. If we had not made a decision, we would have lost significant amounts of research funding.

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

If It Can't Be Fixed, Just Ask Scotty

On the Starship Enterprise, Scotty the engineer was the technology "go to" 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.

Almost every IT department seems to have a technology "go to" person. Some places call that person the "architect," while other places call him or her the "guru." At a previous organization I worked for, he was called Ron. It's good to have someone like that as long as your Scotty/Ron isn't a one-person show. The real concern here is the single expert syndrome. Scotty needs backup. But Scotty is a rare breed, hard to find, and you can't always afford two Scottys in a cost-conscious university IT environment. So, you basically have two solutions:

• Create resource pools to enhance knowledge sharing.
• 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 such situations are by nature exceptional; they've never been experienced before and can neither be predicted nor planned for.

In an IT shop, however, we are not travelling through strange new worlds. In our world, a hero is an indicator of a bad thing: a lack of process. We are all familiar with the classes of problems that occur in IT, and we should have processes in place to handle them. If you need a hero, it means you don't have a good process. Ron was a superstar because he put processes in place to deal with major systems outages — or, as he liked to call them, "technology appreciation events."

The other solution — the resource pool idea — solves a key higher-education staffing issue. Depending on your institution's size, you might not have the kind of funding to hire in depth and create redundancy of key positions. So, you need to do the next best thing: create resource pools. Software development groups and other project-driven organizations can benefit from such structures.

In a resource pool, each key functional area is allocated developer person-days without naming names. That is, 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.

This approach increases personal development opportunities for your staff members because they learn more systems and technologies, which lets you grow the intellectual capital of your organization. It also keeps your staff members 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 and lets you adapt to changing demands across multiple client groups. Finally, creating a resource pool prevents your clients from developing the mistaken idea that they control specific resources (if Bob always works for Finance, Finance begins to think they own him).

So, it is okay to have a Scotty, but be wary when someone says Scotty is a hero! He needs to be part of team of people who can fill his shoes if the need arises.

Even in Our Own World, Sometimes We Are Aliens

In a university IT environment, you face a vast array of technologies. With many different technologies come many different subject matter experts. For example, almost all higher education 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; you must invest your own intellectual capital wisely. I recommend becoming an expert in the high-priority stuff and letting someone else learn the rest.

The hardest part of moving into an IT leadership role is to let go of technical skills, even though the temptation to retain those skills is always there. For example, one evening, I was working late while one of our programmers was trying to solve a nasty mainframe data-conversion issue (we were running a project to shut down the mainframe). Because I used to have some mainframe skills, I offered to look at the issue. Together we solved the problem, which was good. Unfortunately, he told everyone else, and that was bad. The last thing I wanted was other staff members asking me for help with their mainframe problems. Sometimes it is good to be the alien!

When dealing with your clients, you don't want to be an alien. You want them to feel like you are one of them and 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. For example, we initiated an institutional analysis (IA) reporting project, working closely with IA to build a development environment and reporting system. Their folks and our folks worked as a single team to deliver systems such as an enrollment-reporting cube that was ecstatically well received by our clients. We succeeded because we were a team and not aliens. From the client's viewpoint, you could not tell the difference between IA and IT staff.

Another example was a desktop standardization project in which IT, accounting, purchasing, and advancement all worked together to standardize our institution's computer purchasing process. We developed a process that we all had a stake in:

• The computing standards fit our IT architecture.
• The ongoing acquisition model streamlined the purchasing process.
• The transaction processing model met the accounting group's needs.
• The strategic alliance with the vendor met the advancement department's needs.

We merged four very different "alien" cultures into a single team to develop a model that benefited the entire university.

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

"Boldly Go Where No Man Has Gone Before!"

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. That is, it is good to experiment with new technologies in beta test mode, but we have an obligation to our institutions to treat production as sacred. Experiment to learn, but be cautious about what you give 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.

For example, I worked at a Canadian university 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, sorted out legislation concerns, and created the first contract of its type in Canada. Once the first-mover problems were sorted out, the way was paved for simpler and smoother implementations at other institutions.

The second caveat is related to the period during which the original Star Trek aired — today, you should boldly go where no person has gone before!

Conclusion

Star Trek has many lessons for IT leadership in higher education. I encourage you to learn from others and then make your own rules. Think independently, and interpret rules as guidelines for broader and deeper thought. As a head geek at your institution, it is your responsibility to manage all the different facets of your role to the benefit of your campus. Star Trek is merely one source for inspiration.