Andrew McAfee is a professor at the Harvard Business School, and he writes some interesting things in his blog about his research and thoughts on the new dynamics of the enterprise. In his latest blog entry, he talked about some of the research behind a new paper he co-authored about how IT is a driver of competition among companies in the same industry. That blog entry and that paper are what got my thoughts going.

This is a column I wrote for Systems Management News that I am reposting here.

Being a manager in IT is an challenging and often thankless job, but there are steps that we can take to make things better. Making things better though involves keeping multiple things in mind - the company, our team, and ourselves. To get things going in "The Savvy Manager," let's look at these components and some of the issues we should have in our thoughts.

The new issue of Systems Management News is out with my latest column. In this month's column, I talk about adding value to your organization by building better understanding of your organization and its industry. As a leader and manager in IT, we cannot sit in front of our computer screens focused on our technical work. We need to get out into the organization in order to gain knowledge and build relationships.

One of my blog's visitors asked me some questions about technology accelerators as described in Good to Great, and she said it would be ok if I posted the response here as well.

If technology cannot make or break a company's level of greatness, but only serves as an accelerator of greatness or demise already in progress, then why did everyone fall in love with technology for technology's sake during the 1990s?

There are three main reasons in my opinion, and some companies might have more than one of them.

In case you have not noticed in the navigation, I started writing a column called "The Savvy Manager" for Systems Management News. The magazine is targeted at system administrators, data center managers, and similar people. It is a new magazine being published by the same company that does SD Times, one of the more reputable trade mags in the industry. My column focuses on the management side of the audience and will cover subjects like business-IT alignment, personal professional development, staff professional development, relationship management, and similar subjects.

One of the things that comes up in tech transfer and in IT all the time is whether something is a good idea or whether it is truly innovative. A podcast I listen to is called "Killer Innovations" from Phil McKinney, and his podcast focuses on an innovation process he has developed over the years. One of the steps in the process he uses involves asking a lot of tough questions about the idea on the table. He has created a set of questions that he uses at HP, and I think the same thing can be done for IT. If an idea does not seem to hold up under the questions, then obviously it needs more work. With a little brainstorming, I came up with these questions.

1. What user complaint or obstacle does this idea address?
2. What are the obvious benefits to users who adopt this idea?
3. What pain that users don't know about will this idea address?
4. What benefits does this option offer over other solutions?
5. What changes will this solution require in user behavior to be considered successful?
6. What impact does this solution have on other systems?
7. How will this solution increase revenue or decrease costs?
8. What organizational goal is this solution going to help accomplish?

These are just a few when you are trying to examine innovative ideas for internal IT services. Thinking about your ideas with these questions will help you understand the real benefits and issues that may face your solution. If you think about these things before you start talking to others in your organization about the idea, you will have the answers to questions that they are likely to ask.

William Oncken, Jr. and Donald Wass wrote an article several years ago for Harvard Business Review about time management called "Management Time: Who's Got the Monkey." As you can imagine, Oncken and Wass use a metaphor of monkeys to approach the issue of time management. Before getting into the specifics, everyone realizes that you can not really manage time. We can manage how we use our time, but there are not any ways to increase the amount of time, move time around, or buy more of it (though we'd certainly like to buy some once in a while). Time management though is really more about priority management and delegation.

Monkeys are a metaphor for the initiative on tasks and responsibilities. A user's printer problem is a monkey. Setting up new user accounts for the staff members is a monkey. Taking a look at the server logs to troubleshoot the backup software is a monkey. Monkeys live on people's back like you would normally expect, and they can be exchanged and moved around from person to person. So how do you manage the monkeys to be sure things are getting done? Oncken and Wass proposed five rules for managing monkeys.

Rule #1: Monkeys should be fed or shot.
While you should absolutely not micromanage, it's important to check in with your people to make sure they are feeding their monkeys with the appropriate attention. If a monkey is not getting attention, it will eventually get angry and demand more attention than if it were addressed immediately. At the same time, it occasionally becomes necessary to shoot a monkey because it is no longer important or required. If you have a monkey that's been sitting around for weeks, maybe it would be better to just remove it as a to-do and move on.

Rule #2: The monkey population should be kept below the maximum number that the manager has time to feed.
Your people will only work on the number of monkeys that they have time to do. A monkey that has been well-maintained should only take five to fifteen minutes of care to continue good maintenance. If your people have too many monkeys, that means you are going to have too many monkeys to care for and feed, too. It is important to know the team and yourself so that no one becomes overloaded. Otherwise, the monkeys will get to be overwhelming. You have seen those Career Builder ads, right?

Rule #3: Monkeys should be fed by appointment only.
If one of your reports walks into your office with a monkey, it is sometimes a good idea to send them away to schedule a time to come back. With the intellectual style of IT work, sometimes we just need a little more time on our own to figure out a problem. It might be a good idea though to feed the monkey a treat by giving the person a thought that might get them approaching the problem from a different angle by which they take care of the monkey themselves.

Rule #4: Monkeys should be fed face to face or by telephone, but not in writing.
If someone sends you an email about a monkey they are carrying that requires a response, who now has the monkey? That's right - you do! The monkey is on the back of the person who has to take the next step. If you are asked a question about someone else's monkey, you want to be careful that they don't get you to take the monkey for them. Even some phone calls can move a monkey to you so be careful how you talk. You want to help the person take care of their own monkey, not let them give the monkey to you.

Rule #5: Every monkey should be assigned next feeding time and a degree of initiative.
While not every monkey is going to be long term or require weeks of work, it is possible that a monkey is not a task that can be completed short term. In that case, you want to check in and feed the monkey once in a while on a regular basis. By assigning how much initiative is needed, you can also set the expectation for how much progress should be made before the next feeding. If you just check in to see how things are going, then maybe nothing will happen. If nothing happens, that could allow the monkey to jump onto the manager's back.

While these rules are a bit extreme when taken strictly, I think it is definitely important to think about who has the monkey on a task. It can become easy to just say you'll take care of something because you know exactly what needs to be done. But what's the impact of that new monkey on the rest of the monkeys you already have?

We're in the process of interviewing candidates for a few technology licensing manager positions, and the method of interviewing always comes up. After this year's Super Bowl, one of the first things I think of when I start preparing to do an interview is this Tide coffee stain commercial:

While we might open with a question for a candidate to tell us about themselves, most of our candidates are asked better questions than in the commercial. However, it can be a real challenge to figure out whether a person would fit well into the organization. For most positions, a candidate will spend an entire day or more with us in interviews with the entire staff and other stakeholders in our department. In the course of that much time, usually you find out what a person is like. The person who talked about skinny dipping in his backyard? Yeah, probably would not have come out in a half-day interview, but it did come out over dinner conversation.

By having these extended interviews, we are usually able to get at the real personality of a person and how they might fit into our department. But maybe there are better phone interview questions that can be asked to try to weed out these poor behaviors before they get in front of the entire group. The best method for this is called behavioral interviewing. The idea behind behavioral interviewing is that past performance and past actions are the best predictors of future performance. In traditional interviewing, the interviewee actually has a lot of control as the questions most interviewers ask are pretty open-ended and move from subject to subject. Behavioral interviewing has the interviewer asking an open-ended question and then more probing questions to get at the details of the answer in order to learn something about the interview subject.

Here is an example of how a set of questions might go in a behavioral interview:

Tell me about a time you had a conflict with someone else in the office.
How did you approach the person to resolve the issue?
What was the discussion about the resolution like?
Whose advice did you seek in evaluating the situation?
What was the atmosphere like between the two of you after the issue was resolved?

Can you imagine how a candidate might answer differently if they were given the first statement and then the interview moved to another subject? The goal of the follow-up questions is to really probe into the behavior of the person you are interviewing. By using this probing style of questioning, you can find out multiple things. You can better judge whether they gave a fully honest answer. You can find out how they really dealt with the given situation. You can maybe get some insight into their personality.

This interview style can even be carried over into technical areas. Here is an example of how you can use behavioral interviewing with technical subjects.

Tell me about a time you had equipment go down that impacted the organization's operations.
What did you say to the server vendor to explain the problem?
What did you tell the non-IT staff about the problem?
How did you decide on a solution?
How long did you think the repair would take?
How did you communicate that to the rest of the organization?
How long was the equipment down and impacting the organization?

Asking these questions will not only tell you a bit about their technical abilities, but they will also tell you how they deal with others during a crisis. The IT field is beyond the days of being a bunch of basement-dwelling, antisocial jerks, and that means it is even more important to know exactly how a new hire will react when you have an emergency or handle day-to-day operations. If someone is just good enough to get through a traditional interview, you might find out too late that they are a really bad fit for your organization.

No, I don't mean talking to ghosts here like a character from an M. Night Shyamalan movie. I mean talking to the other side of the organization, the non-IT side. As technical people, we can easily fall into geek speak that goes way over the heads of people who aren't in the IT field. Imagine you are explaining the difference between hits and visits in the context of a web site to a business person. You might be using pretty standard terms, but does the business person really understand? Might the conversation go something like this?

While we might all be speaking English, we might not be really communicating. There is a lot more than just translating IT-speak into business-speak, and it can take a lot of time to gain the skill to go beyond using the right words and being able to really communicate. While we are all pressed for time, one small thing you can do is to really take the time to understand the problem someone is facing and help them understand the solution. If you don't think your mom would understand what you are talking about, think about different words you could use that would still explain the same concept. Do you talk to your mom about visits and hits? Or do you talk to her about how many people came to the site and how many pages they looked at? If you think the terms you are using might go over the person's technical understanding, avoid the technical terms that might make them shut down. The more conversations like this that you have, the more easily this ability will come to you.

Tech Term Taboo
This is a little game you can play to test out your ability to describe technical issues without using overly technical language. If you have ever played the game Taboo, then you are familiar with the idea here. Get together with another technical person you work with or that you know. Come up with a technical subject or issue, and then think of five to ten taboo words that are likely to be used to explain that topic. One person takes a turn trying to explain or describe the subject without using the taboo words. If they do, the other person buzzes them. Technical terms make a lot of people gloss over which makes it a valuable skill to be able to explain technical subjects without using all technical terms.

I am reading Good to Great at the moment, and it was really exciting to read about the role of technology in a company going from good to great. Every company that really went from good to great had technology play a significant role in every single example. In a few cases the technology was not information technology which reinforces one of the most important points. It is not just deciding on a technology and implementing it that enables the transformation into greatness. The specific application of the technology and how it enables the company and its employees to create competitive advantage is what it takes.

No, those who turn good into great are motivated by a deep creative urge and an inner compulsion for sheer unadulterated excellence for its own sake. Those who build and perpetuate mediocrity, in contrast, are motivated more by the fear of being left behind.

So how can you figure out whether you are missing a piece of technology to really enable that move from good to great? To me, one of the first steps is looking at the processes where there is either hidden knowledge or an opportunity to make processes immensely more efficient. When done well, business intelligence solutions can create major competitive advantage. The data your organization collects is more than just a record of sales or the storage of customer information. The data is a resource as much as an employee is a resource, one that should be put to work and utilized to its fullest potential.

If business intelligence is an area that is only slightly familiar to you, I highly recommend picking up an introductory book or taking a class on the subject. While I understood the potential benefits of business intelligence, it was not until I really dove more deeply into the subject that the ideas starting coming on how business intelligence could really transform the way we do business.