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.

~

Part 9 - Tribbles hate Klingons (and Klingons hate Tribbles).

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

Tribbles are fictional creatures in Star Trek. They are small, soft, and gentle, and producing a soothing purring sound. These traits are said to endear them to all who encounter them, with the notable exception of Klingons, who consider Tribbles to be "mortal enemies" of the Klingon Empire.

Roughly translated, if you don’t like someone, odds are, they don’t like you too. So don’t go around making enemies across your organization. Work on building friends 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. My job has been to knock down the walls and build bridges over the moat to the rest of the campus.

You do that by “opening the kimono” and being transparent (no secrets). We became transparent by actively engaging the campus in information systems decision-making through a broad governance process. Asking clients what they want, and making it happen as promised. Do what you said you would do and get it done. It's not rocket science.

We have had our governance process in place for five years. Business decisions are made by our clients and we simply facilitate the process. We are like Switzerland. We are neutral about the business decisions as long they have fit, utility, and balance. Fit means the decision is aligned with strategic plan of the institution. Utility means the quantitative and qualitative benefits outweigh the costs and risks. Balance means you treat your IT projects like an investment portfolio that is 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.

~

Part 8 - Infinite diversity in infinite combinations.

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

Star Trek's Vulcan world believed in the need to celebrate and support the the 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. They are a particular challenge. 

In the old days we used to handcraft systems. They were built from the ground up and custom tailored to fit every process and client nuance in the organization. We programmed every unique activity and process into the system. So, of course our legacy systems 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 would cost about $45,000,000. It would be perfectly customized to meet the demands of every nook and cranny in the organization's existing processes. But it would bankrupt the organization. 

Instead of building our own unique systems, we buy industry specific solutions like ERPs. The problem with vendor written ERPs is that vendors build them to meet generic organizational needs. They end up not meeting anyone’s needs completely. They try to be one size fits all, but the reality is that one size fits none. 

This situation creates a new problem. You may have saved money by building instead of buying. But now you have a decision. Do you massively customize the product, or implement it off-the-shelf and change your existing processes? The answer typically lies somewhere in between and every organization's solution will be different. 

Whatever degree of customization your organization decides to choose, the role of IT changes. New leadership in IT means we must emphasize integration, not building from scratch. The days of handcrafting systems are over, but the complexity of “one size fits none” requires new skills. As IT leaders, integration skills are needed to manage infinite diversity in infinite in infinite combinations. That’s a tall order, but no one said the job was easy.

~

Part 7 - Having is not so pleasing a thing as wanting; it is not logical but it is often true.

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

"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 mentioned in an earlier post, my university was 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 it be a laptop, desktop, smartphone, or whatever. Therefore making it much easier for us to rollout 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 was a lot harder work than the dream. 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 in the short term based on managed desktops.

We admitted we failed with the anyplace desktop idea, but we did not spend much time on it and we did not dwell on it. We learned a lot and moved on. We may come back to it sometime in the future when the technology is ready for us.

Although we didn’t succeed with our dream, we learned from it. High ambition brought us farther and faster than if we had taken the low road. We can say we tried and the technology was not ready yet. Desire is useful. It helps us to aim high.

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!



~

Part 6 - Live long and prosper.

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

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

For example, sometimes it is amazing how long a piece of software code can remain in production. I wrote the code for a really large logistics system in the 1980’s for a natural resources company. That company was purchased by two competitors who both took copies of the code. For better or worse, I found out just a couple of years ago that both companies were still running heavily modified versions of my code 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 awards for innovation. 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, not on getting the quick hit and moving on. 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 doesn’t do our clients any favours.

I’m 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 someone else the chances. We’ll learn from them and build things using reliable methods and processes done with high quality. That’s 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. They end up being the first to get fired because the kinks have not been worked out of the technology yet. Focus on the long-term quality and you will live long and prosper.

~

Part 5 - There's no such thing as a Vulcan death grip.

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

For folks not familiar with obscure Star Trek episodes, Spock used the so-called "Vulcan death grip" on Captain Kirk as a means to fool the Romulans into believing Kirk was dead, so they could escape without causing suspicion. Afterwards 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.

The Vulcan Death grip was a very effective deception. My experience with this particular Star Trek rule is that you can only use a trick like this one once before folks are on to you. Not telling the truth can be effective, but only temporarily. As soon as someone discovers you’ve been hiding something, you’ll be in worse trouble.

If we were to translate this Star Trek lesson to IT, I would urge caution. I’ve seen an incredible number of IT folks try to baffle non-technical clients with technical jargon. Nobody likes being talked down to. Nobody likes having to bow to the high priest of technology. So don’t pretend IT can perform magic like a Vulcan death grip. Always try to give your clients plain English explanations.

For example, when I interview technical people my favourite question is how would you explain a compiler to your grandmother? The best people I’ve ever hired are the ones who can answer that question in plain terms. If you can’t answer a question like that, you shouldn’t be in a client facing IT department (and in my opinion, we all have clients). In case you were wondering, the best answer I ever heard to this interview question 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 was working at an insurance company. We had an infrastructure department that tried to use the Vulcan death grip approach on their clients. They acted like the high priests of technology. They used their knowledge as power in the organization. Instead of working with their clients to develop solutions, they used it to dictate solutions to their clients. I would characterize their behaviour as using their power for evil rather than good. And here is the thanks they got: they annoyed the organization so badly they were completely outsourced – lock, stock, & barrel. Be wary about using a Vulcan death grip in the real world.

~

Part 4 - Humans are highly illogical.

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

Mr. Spock, the Starship Enterprise's First Officer, was a Vulcan. He came from a culture that prized pure rationality. He was a logician who found human emotions sometimes amusing and always perplexing. Since humans may not always be logical, they are an interesting management challenge.

As Spock would say, humans are highly illogical. That characteristic is what makes managing them and designing systems for them so very interesting. People are more complex than computers and managing people is particularly challenging in an IT shop.

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

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

The key point to the story is that the kind of people attracted to IT jobs tends to be similar. There is a tendency for introverts to migrate towards IT careers. That makes them a different management challenge from a marketing department. You need to be creative about how you motivate and encourage them to get out of their offices and comfort zones and go talk to their customers. 

Your job as a leader is to mentor and coach them on relationship building, bridge building, and open continuous communications. 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. 

~

Part 3 - Keep your phaser set on stun.

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

For those not familiar with Star Trek, “phasers” are the weapon of choice in the future. IT departments can wield a certain amount of control and influence in organizations and the application of this influence should be governed by rules similar to how phasers are employed in Star Trek.

IT's power needs to be used wisely. Like a phaser on Star Trek, you really should keep it set on stun. In many distributed organizations, such as a university culture, there are very few rules about what computing you can and cannot use. But there needs to 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 that desktop computers on campus were as unique as snowflakes. The rough breakdown was 30% Mac, 60% Windows, and 10% “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 PC’s had problems, and Linux was completely unmanageable. We had huge implementation problems for this project because each desktop was unique. 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 to the issues, we stepped back and looked at the big picture. In culture such as an university environment, there is a key equation:

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

We decided to use this to our advantage. We said if folks across campus want to make their own choices about desktops, then the issues with the imaging and workflow software are the price to pay. If clients don’t want this to happen again the future, we need organization-wide desktop and laptop standards. This clarity of choice gave us the ammunition necessary to make a change. We used these results to help justify a desktop standardization program across campus with the support of administrative and academic leaders.

We set our phasers on stun and turned a nasty problem into an opportunity. We leveraged a problem into an opportunity to convince folks that we need better standards across campus.

Another example of this Star Trek rule is how to enforce IT security. Traditional passive policies where you only take action after a security issue occurs are too dangerous to the network. Pro-active polices where you take action as soon as you realize a security issue may exist are necessary. The danger is that a proactive policy is very powerful. Like a phaser set on kill, if you use it indiscriminately you will do more harm than good. If you shut someone's computer access down arbitrarily without warning, you will destroy any future potential relationship with that person. My advice is to apply pro-active policies only as the last resort. They can be used as a threat of shutdown in order to convince someone that they should upgrade or fix their potential security issue. 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 when you can consider breaking the rules. Sometimes you need to set your phaser on something more potent. Several years ago I had been working closely with a department to develop a business case to implement a multi-million dollar system. Everything seemed to be going well until the client told me they would hire their own people to perform the ongoing support and maintenance of the system and manage it independently of the rest of IT. That’s when I set my phaser on kill. I stopped the project dead. They backed down and we were all a happy family again.

There are always exceptions to every rule.

~

Part 2 - Seek out new life and new civilizations.

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

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 was the “Click-to-Call” project at my university. One of our Network leaders, Diane, came to me one day with what appeared to be a crazy idea. The concept was a web-page hyper-link enabling anyone, anywhere to phone anybody at the university for free from a web-attached computer. We struggled a lot with the idea because it seemed to be kind of far-fetched at the time. But we liked to foster a culture of innovation, so we piloted it, tested it extensively, talked to our clients about its potential uses, and 6 months later we became the first university in the world to implement Diane’s crazy idea.

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

1. We were able to put an instant phone link on our Admissions web page. Foreign students and parents could call the university for free to get information. So this tool can help grow enrolment.
2. Researchers could telephone their colleagues at our university for no cost. So this tool supported the University in its strategic mission to become a research-intensive institution
3. Looking up phone numbers on our Directory web page led to click-to-call instead of reading, jotting down the number then dialling ... then realizing you made an error and dialling again! The new capability simply improved the efficiency of our institution.
4. Email 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 email signature. I quite often got calls through this mechanism from folks who were travelling and didn't want to use a hotel phone or incur cell phone roaming charges.

At my university we learned a lot from this Star Trek rule. Our primary discovery was that there is huge business value in seeking out new life and new civilizations; or in other words, always be on the lookout for new opportunities and nothing is crazy if it saves money and works.

Now I have to admit, I’ve noticed one drawback to this system. I had one caller who tried to phone me without a microphone and speaker on their computer. Nothing is perfect and never ignore the human element!

~

Part 1 - Non-interference is the Prime Directive.

(This is part 1 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 the Prime Directive dictates that there can be no interference with the internal development of civilizations. To me, that means support and allow multiple computing cultures to grow on campus. In most university environments there is a central IT group and many smaller distributed IT shops.

My advice to the folks in leadership roles in the central IT organization is to compete in your core competencies, and cooperate everywhere else. So what is a core competency? It is a service that you can perform more efficiently than anyone else on campus. Therefore, you focus on what you’re good at and the institution benefits from optimal use of its resources.

As a central group part of your role should be to enable distributed IT organizations to perform localized specialization more efficiently. For example, we introduced a single email, calendaring, and collaboration tool to our campus. This enabled many distributed IT groups to shutdown their standalone independent email systems and move to the central system. Nobody actually reduced headcount. What we did was enable those distributed IT folks to stop worrying about administering email and begin to focus on IT services that directly improved their functional areas. We helped them move up the food chain while at the same time the University benefitted from greater economies of scale and scope of a centralized service.

To help with these types of initiatives we created something called the Campus Systems Council. We hosted a monthly meeting of leading folks from the distributed IT groups across campuswhere we shared an update on everything the central IT group did. The meeting was a great opportunity to inform them of technology changes. Similarly, they shared their updates with the group too. The meeting becomes a great forum for communication and it helped build trust amongst the various IT tribes across campus.

If you work for a central IT department, don’t interfere with other good IT work on campus. If you want to get involved, look for ways to nurture and support the distributed folks. Non-interference should be your prime directive in areas outside of your core competencies.

~

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

When I was the Chief Information Officer at a large university I found myself in front of many different types of audiences. The audiences I always enjoyed the most were students. I once explained to a roomful of students what a CIO, or Chief Information Officer, did at the university. After I patiently explained the job, one of the students exclaimed, “Oh I get it – you’re the head geek!”

That gave me the idea to link everyone’s favourite geek TV show, Star Trek, to some leadership lessons for the real world. These basic leadership lessons have universal applicability, particularly for I.T.

Now I have to admit, I am a huge Trekkie. To prove it, I own a poster with one of my favourite rule lists, “Everything I needed to know about life I learned from Star Trek.” (I told you I was a geek.). The rules are as follows:

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 (IDIC). 
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 stayed on my wall, the more I wondered: how do these rules apply to creating digital information systems solutions at a university? I originally developed some interesting answers to this question in a presentation I gave a number of times. I decided it would be useful to write a series of 16 blog posts to answer the question in more detail.

My plan is to walk through each of these rules in a separate blog post and connect them to IT leadership challenges in higher education. Each rule will have a separate post, and I will update this posting to contain an index of links to each rule as I write them. Each rule in the list above will become a link to the related blog post.

~

Is Klout Evil?

Klout is embarrassing. I feel guilty when I check my score. Is it just about ego affirmation?

Klout is a roller coaster. I wrote the best blog post of my life and my score went down. I re-posted someone else's funny picture on Facebook and my score soared.

Klout is depressing. I thought I was a reasonably popular guy in the real world. In the time-space continuum of the Internet according to Klout I ain't so cool. Ouch.

Klout is a Harry Potter sorting hat. On Twitter I've automated Klout scores to appear beside every post. Now I only read posts by high scorers - the Gryffindors of the Internet.

Klout is omnipotent. It knows all about you even if you aren't a member. It publishes your score even if you haven't joined. Oh well, thats what you get for living life in the public space of the Internet. Too bad.

But is Klout evil? Hardly.

~

Library Magic

One late evening of the early fall of 1977 I suddenly understood the concept of marginal utility. In an island of quiet surrounded by a sea of fiction I figured it out. In retrospect the discovery was not that complicated. But my days had been filled with running to classes, meeting new friends, and recovering from frosh week. No time for reflective thought. It is amazing what a lonely study carrel can teach you.

This actually wasn't the start of my love affair with libraries. That started many years before. My elementary school library taught me all the things I needed to know about life that Mrs. McKnight, my grade 4 teacher, couldn't teach me. Like why the Cuban missile crisis almost destroyed the world. And why chemistry really led to better living. And why 18th century British infantry wore red. Random stuff. But I was learning to learn. The school library gave me the opportunity to learn what the structured curriculum was never going to teach anybody. It was a portal into new universes.

As I got older I started to do formal research in the library. By high school learning demands were broader. The school's library wasn't big enough. The lure of the downtown mega-library pulled me into its time distortion field. Hours spent wandering through stacks of unplanned knowledge. A small project on polar bears turned into a journey of discovery. Pulling out unrelated volumes on polar exploration and Polish cinema sent my mind into unexpected worlds.

Apparently the library that gave birth to my understanding of marginal utility is changing. I've seen more computers and more team space and more teaching functions come into the library. I've seen new additions to buildings. I've sat on library steering committees and watched money get moved from books to online journals. And best of all, I've seen Starbucks occupy some musty unused corners.

But lets think about those changes. More information. More opportunity for reflective thought. Just not so lonely anymore. Seems like the new things are good and the important things are still there. Yeah. Now it's time for a latte and that new book on Polish cinema. And while I'm doing that I can browse the films on my iPad using the library's wireless. Knowledge, technology, and good coffee. Perfect.

~

BYOC ... Bring Your Own Computer!

I've seen a lot of news recently about Bring Your Own Computer (BYOC) to work. Driven by an abundance of reasonably priced options for smartphones, tablets, and laptops, folks want to bring their access devices from home to work. Given the freedom of choice, most people tend to buy something that meets their personal needs. The problem for the central IT department is that we get comfortable with them. Then we want to bring them to work.

BYOC is more of a cultural problem than a technical problem for central IT. Historically, end-user computer access devices were dumb terminals. No data belonging to the organization was permanently resident on these devices. No functionality to manipulate the data was built into the device. All corporate data was controlled behind the end-user access point. The illusion of control was absolute. Central IT had complete authority over the data everywhere.

Evolution kicks in and processing power comes to the terminal. We replace terminals with PC's. The PC can collect corporate proprietary knowledge, download it, and save it on portable media. Suddenly everything is at risk. Corporate IT departments respond by locking down personal computers. Standardized hardware and software is enforced. External access is limited and monitored. Control is necessary and accepted because the stakes are high.

But today that paradigm is being shattered. The latest stage of evolution is BYOC. Users are demanding choice. Yet if IT can't enforce standard devices, is corporate security doomed? I doubt it. I think we can we learn from history. What succeeded in the day of dumb terminals? It wasn't control, it was trustworthy information. What succeeded in the day of PC's? Greater user functionality and service.

Central IT should worry about protecting proprietary knowledge, intellectual property, and personal privacy. If you build information services with security in mind from the ground up, none of that data should reside on end user devices anyway. Architect your systems to give users the service they deserve on the devices they want.

Absolute control of end user devices was an ephemeral luxury for central IT groups. That luxury is fading into the sunset. Client service is not about the device, but the information systems available. That might be a lot harder to achieve without locked down standard devices. But it sure means your clients are going to be happier. Boxing up a standard, plain vanilla device is easy. Providing real service to your clients is hard. But worth it.

~

Why I Love Google ... and Apple ... and Microsoft

I woke up this morning and realized nearly all my core web services are Google products. Email, calendar, web sites hosting, chat, blog, portal, and yes, even search, are all Google. What astounds me is that almost none of them are best of breed. WordPress is a better blog tool, Outlook has more email and calendar features, and there are many more sophisticated web site hosting environments. Almost all of these non-Google tools have better individual features. But Google wins every time because of integration. Their tools work well together. I login once and have access to everything.

They succeed because they have created an architecture of simplicity. Google has managed to make my online life simple. I reward them for that act of clarity through loyalty. Almost by default I will choose a Google web service over a competing product because they make my life easier. I don't have to do any of the integration work. They do it all for me. I can focus on getting the things done that I want to do. I don't have to fuss with the disparate technologies and jump through hoops to make them work together.

Same goes for Apple. Entertainment in my life could have become incredibly complex. But iTunes on all our family computing devices works seamlessly. We can share our library, add to it, back it up, and so on without thinking about it. Apple seems to know what we want before we want it. No complexity on my part. My Mac is the computer equivalent of a finely tuned Porsche. It works perfectly. Any Apple hardware works with it in perfect harmony. Simple, easy to use integration allows me the luxury of not having to worry about hardware problems.

The difference between Apple and Google: Apple products are best of breed. But you pay a substantial premium for them. Integration comes at a price with Apple. Their hardware may be the best, and you need to be willing to make the investment. I'm willing to spend more on Apple to mitigate the risk of hardware failure. I'm willing to accept weaknesses in Google products because the cost of learning and integrating multiple web services is too steep for me.

I even love Microsoft for much the same reason. Microsoft Office is beautifully integrated. Elegantly consistent across the core Office product lines, the folks from Redmond make my life easy. Without giving a thought to the underlying complexity of the task I can write a detailed Word document with integrated Excel spreadsheets and PowerPoint diagrams. The end result looks perfect. Not a single flaw indicating the contents were built using three very specialized and unique software tools. Microsoft is the original master of embedded integration.

The consistent secret to success for Google, Apple, and Microsoft is integrated architecture. Individual features are easily copied and transcended by competitors. Well-designed, principle-based architectures are unbeatable because they are seamlessly integrated. Now if could just get Gmail to embed my iTunes podcast with a PowerPoint slide show ...

~

Leadership and the Network Effect

One of interesting properties of information technology is the 'network effect.' As more users join a network, the more valuable the network becomes. A network of one node is useless. Image FaceBook without the internet - it would be a pretty boring place. A network of 2 is better. A network of 10 becomes more interesting, and Facebook with a hundred friends is a lot of fun. Add a growing network to FaceBook and it becomes an interesting place.

In our business culture great leaders are often viewed as solo performers. Such notions are emphasized by commonly held beliefs that "it's lonely at the top." Biographies are written about Steve Jobs and Lee Iacocca and Jack Welch emphasizing the strength of the individual and not the teams of supporting players. Yet none of these leaders became successful by being a pure solo artist. Every one of them worked with a network of supporting players.

Their own networks grew over time as they expanded their influence. I would suggest it is a mutually reinforcing affect. As their network of contacts expanded, their career grew and thrived. As their own star rose, more folks wanted to join their network. Successful leaders use the network effect to their advantage. They thrive on having multiple points of view, multiple sounding boards, and multiple connections.

The network affect is an overlooked but critical aspect of leadership success. As we think about future leaders, let's not fall into the trap of looking for solo players and rugged individualists. Lets keep our eyes open for the network builders. Real leaders get things done through an ever-expanding circle of friends.

~

Economics of Cloud Computing in Canada

Cloud computing is primarily an economic innovation. The technology is interesting and important, but cloud computing is fundamentally driven by changes in the economic model of computing. What does this mean to Canada and the higher education community? I gave a speech at the Cybera Summit in Banff earlier this month that included a section on cloud computing in Canada where I addressed this question. I thought the ideas presented there would be worth sharing via a video clip from the Summit.

~

The Secret Sauce in IT Governance

IT organizations are in particular need of good governance. They face a unique degree of resource sharing across the enterprise. IT leaders are brokers of limited project and infrastructure money in the organization. There are many competing demands for a limited pool of resources. An IT leader can either charge for all the services or create a governance model for allocating the shared resources. Non-IT leaders who need information systems resources want a voice in the decision process.

Many organizations tend to have a mixture of chargeback and shared free resources. To prevent the tragedy of the commons around free services, organizations adopt some form of a governance model. Governance sets the criteria for the organization's IT priorities. Then they use these criteria to prioritize resources and projects. Prioritization helps determine what decisions need to be made and who makes them.

I've read some wonderful books, white papers, and internal manifestos on how to launch governance models for IT organizations. They explain the committees, the scope of responsibilities, the nature of the decisions, the criteria for creating priorities, and the individuals involved. With all this wonderful documentation, how could they possibly fail?

Usually governance fails because the meetings are boring. After the initial excitement of the governance launch fades, members of the governance process start to lose interest. Attendance wanes. Within months, people wonder what happened. Discussions are theoretical and abstract. Real influence in the future of IT is not happening at the governance table.

So what do you do? How do you keep the flame of interest alive on a regular basis? There are three secrets to great governance. The first secret is make sure everyone realizes the governance process is the only way resources from IT are going to be allocated. No back doors, no secret deals. Everything is on the table at the governance meeting. That means there is money on the table at every meeting.

If all projects go through the governance model for approval, this process allocates all IT investment money. We all know there is never enough money to implement every idea and project. So the money and resources approved for one project means some other project will not be done. This means the sponsors and stakeholder representatives of initiatives with competing demands must justify their requests at the governance table. IT becomes the facilitator of the debate, not the decision maker.

Governance meetings become interesting because they shape future investment. The winners of the IT allocation discussions are the winners of investment in the future of the organization. That makes the governance meetings particularly fascinating.

The second secret is to make sure the meetings are entertaining. It may sound silly, but no one wants to attend yet another boring and dull meeting. Give your committee members something to look forward to by teaching them, in an entertaining way, about the issues before asking for a decision. Educate attendees on the issues facing IT and engage the IT staff in the teaching process. The organization will learn about the key IT issues and the IT staff will learn about the broader organization's issues.

To keep the education process entertaining, use the IT staff who are closest to the issue to explain it. Make sure their talks are brief, focused, non-technical, and avoid jargon. Using IT staff to explain the issue exposes more people to the governance process. The exposure to new ideas and people from the IT organization helps everyone grow.

The third secret is to open the kimono to what really goes on in the IT organization. Report on progress honestly. Expose your performance metrics and open them up for discussion. If something is working well, tell your governance committees. If something is failing, tell them why and what you are doing to fix it. Listen to their suggestions. Members of governance committees want to have an impact. Make sure you listen and implement the good suggestions.

When IT acts on the good suggestions, your governance stakeholders feel they are being listened to. They feel like they are having an impact and making a difference. There is nothing more engaging than realizing your voice is being heard and valued.

In summary, there are three ingredients to keep your governance process alive and engaging. First, give your governance committees real influence on IT investments. Next, educate them on the issues before asking for decisions. Finally, open the doors to the IT organization and make sure there are no secrets. These three ingredients make the secret sauce of good governance.

~

Optimism: the Ultimate Motivator

Pollyanna was a fictional character from a book of the same name written in 1913. The plot is a about a young girl who always finds something to be glad about in every situation. She has an overwhelmingly and infectiously positive attitude. Her bright personality combined with infinite optimism changes other peoples' lives for the better. As a manager, does the plot seem silly and old-fashioned to you?

Modern management cynics typically view Pollyanna and people like her as naive and ineffectual. Today's managers are supposed to be tough, heads-down misanthropes. But Colin Powell, former leader of the most powerful army in the world, was a Pollyanna. His most famous quote is "Optimism is a force multiplier." He fought in Vietnam in some of the most difficult military operations of the war and he learned the value of optimism under rather grueling circumstances.

Managers often overlook the value of optimism. For example, what employee would prefer to work for Scrooge instead of Pollyanna? Optimism paints a positive picture of the future - it gives staff something to believe in. Optimism creates energy and enthusiasm. Misanthrope managers claim they never have enough staff to get the work done. Optimistic managers may have the same workload and same headcount, but they're looking forward to continuously greater accomplishments with staff who relish the opportunity.

How do you create optimism? As a manager do you just put on a sunny disposition and act happy all the time? Should you hope your clients and staff simply believe there is a silver lining in every cloud because you tell them so? Optimism without substance is hollow and destructive. Successful optimism has two feet firmly planted in reality. The first foot is in rooted in today's immediate success. The second is in tomorrow's long term success. Create faith in the ability to succeed today. Then build faith that today's success will continue. Confidence in today's success builds unshakeable faith in the future.

Start with small successes. Complete small high profile projects that not only exceed your clients' expectations, but your staff's own expectations too. Build confidence that the team can win against local competition before going on the road to play in the big leagues. When you have created self-confidence in the team you can create deep-seated optimism through bigger changes.

The bigger successes take time, but have a lasting impact on your culture. For example, I ran a large organization where we genuinely hired from within. Every director and manager who worked for me was promoted internally. Over time this approach created a sense of opportunity and confidence that personal growth within the organization is possible. When staff see management positions being filled internally they see hope for their own future in the organization. Doing this consistently creates trust in management. Trust + opportunity = optimism.

Once your team has unshakeable optimism, they can accomplish anything.

~

Complexity is easy, simplicity is hard

In management, complexity is an excuse for not really understanding the problem. I find a lot of managers rush into decisions without taking time to clarify the real issue in their own mind. As a manager you need to make the effort to simplify your thinking about a problem. Imagine this approach: to really understand a problem, you need to be able to explain it to your grandmother. Once you have that kind of clarity, you are ready to take rational action to solve the problem.

Clarity of thinking is a rare commodity in all walks of life. For example, the battle of Waterloo was a turning point in European history. Did Wellington win it with a series of complex strategies? Did he outfox one of history's greatest generals through sheer intellectual power? Nope. There are several reasons for the victory, but ultimately Wellington just picked a good place to fight. He picked the right ground and built his battle plan around a defensible ridge. Not complicated. But he decisively changed the course of history.

Hemingway, renowned for his economy of words, was once asked to write the shortest story possible. He used six words: "Baby shoes. For sale. Never used." An emotionally powerful message conveyed with remarkable brevity. Can you have the same effect as a manager? Creating a clear message starts with simplifying the problem. Simplification builds clarity. That is hard work. It is easy to assume a problem is complicated.

What does this mean to a manager facing challenges this morning?

Think about your strategic plan. Is that 100 page strategic plan full of spreadsheets and complicated charts ever going to be read? What if the plan was only 10 pages with lots of easy to read graphics? In any strategy there are probably only 5 or 6 strategic changes you really need. Boil it down to the core principles of needed change. Then explain how you want to get there in clear language.

On a smaller scale, think about that business case for a new project. Do you think you can sell the idea in a 25 page detailed memorandum? I doubt it. No one has the patience to read the whole thing. If your audience isn't paying attention, how can they approve its funding? Keep it short and to the point. Make your case and move on.

Applying lessons to management from writing fiction and fighting wars may seem like a stretch. But these are all human endeavours requiring similar problem solving skills. I think Wellington would have made a great corporate president and Hemingway could have been a brilliant software entrepreneur. What about you?

~

When You Stop Having Fun

As a teenager I played lead guitar in a band. We weren't very good, but we had fun. Over time the rest of the players in the band started to get serious about playing professionally. They wanted to play other people's songs and get the sound perfect. Slowly but surely the fun disappeared for me, as everyone else got serious about the group. As the fun died, so did my interest in the group. Eventually the inevitable happened and my best friend from childhood had to ask me to leave the band. So instead of becoming a rock star I went to university, got a computer science degree and I've been having fun with computers ever since. The band found a new lead guitarist who fitted in and they played professionally for several years.

Hiring and firing decisions are never easy. Whether you're in a band or a large corporation, the decision cannot be taken lightly. In my experience, you have to ask yourself two questions. First, is this termination the right decision for the organization? Second, is it the right decision for the individual being terminated? As a manager, the first question is usually easier to answer than the second. But in my band example, the band did the right thing for the group and the right thing for me. I went on to a career I loved and they got to play the music they loved.

Management requires a healthy balance of understanding of others and self-awareness of your own needs. Balance your thinking before you act. Be aware of the toll on the organization while taking the time to assess the employee. Think carefully about your own biases when making the decision. Empathy is about understanding as much about others as you understand about yourself.

When you have a people problem and you lose sight of both sides' needs you can make several mistakes. The simplest reaction is to ignore a minor staffing issue. It's easy to worry about bigger issues and hope the little ones go away. But when an employee no longer fits in, the problem will fester and grow into a show-stopper that damages both the organization and the individual. Time is lost and both sides suffer.

Be careful in rushing into the decision. Some managers make difficult decisions too quickly. Shooting from the hip and terminating an employee without thinking through the consequences is mindlessly naive. In these situations the manager recognizes the situation is failing the company and simply pulls the trigger. Without understanding the employee's potential value you may have made a mistake. That's why it is worth taking time to understand if the decision is right for the employee too. A good termination is one where both parties benefit from the decision.

Some managers are afraid to make difficult decisions. They continue to support the individual after the person is a lost cause. Investments are made in counseling, the employee is sent on self-improvement courses, and sometimes the whole team is dragged to an off-site team-building session. As a professional manager, you need to know when to stop. Resolving issues around the cultural adaptability of one person is simple: once you are sure the situation isn't working for the company and the individual, take action immediately.

In my band example, what I did wrong was stay too long. I remained in the band long after I was enjoying it. As soon as I stopped having fun, I should have made it easier for everybody and left. I should have left the band before they had to ask me to leave. Managers don't always have the luxury of having self-aware employees. So they have to make some very difficult decisions and have some very tough conversations.

But that is why you are a manager.

~