Last Friday was an interesting point in the IT@Illinois discussion. Together with Craig Jackson, Chuck Thompson, Dan Jacobsohn, and Kelly Bridgewater, we organized the Friday morning caffeine break to be an open dialog of the IT@Illinois project. It turned out to be really valuable. These are some thoughts I had coming out of the discussion.

The top priority for everyone is getting the mission actors what they need and not taking away the people they have locally positioned. All the concept authors want to give the faculty, staff, and students the tools they need to do their work. This core value translates into a needed agility at the mission actor level in order to be able to provide them what they need as quickly as possible.

This post is going to be somewhat of an open response to Ingbert's comment to my post on the IT@Illinois launch, and it will segue a bit into talking a bit about some aspects of a concept I've been working on with an amazing group of IT people from around campus.

Yesterday was the kick-off of the IT@Illinois project to envision the future of IT at the Urbana-Champaign campus of University of Illinois. Going into the day, we knew a little of what Sally Jackson, CIO of the campus, had in mind, but we did not know a significant amount of detail of what the Provost was thinking. We knew that the project of transforming IT on the Urbana-Champaign campus was going to be launched, but we did not know what that meant. What did we learn on the day of presentations?

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?