% fortune -ae paul murphy

Leadership vs. Management

This is the eleventh excerpt from the first book in the Defen series: The Board Member's IT Brief.

From Chapter 3.2: For Unix: hire a leader; for others: hire a manager

The most difficult issue to get your head around in aligning your CIO with the technology you have or want to move to, involves the difference between leadership and management.

Think of leadership as the process of getting more brains focused on achieving a goal, and management as the process of getting more hands working together.

Manually lifting a steel beam into place is a classic management exercise: you know exactly what the job requires, get your people in place, loudly yell "Heave" and the job gets done. Management is highly visible. As a manager your people are your hands, and you have to be there to direct activities.

Management is appropriate where you have many repetitive, predictable, tasks involving lots of essentially inter-changeable people whose efforts need to be focused only on the specific roles assigned them as part of the manager's plan for getting the job done.

Since that's what you have in the (now merging) Windows and Mainframe communities, a CIO for those environments has to be a manager first, and a technologist second.

In contrast, getting a football team in scoring position, or a military unit in place despite ambushes and other surprises, requires leadership: things happen, you won't know what's needed to respond until it's needed, and if your people don't know what to do when the expected unexpected events happen, you won't achieve your goals.

Leadership is invisible: like stage magic, if you're seen doing it, you're not doing it right.

Leadership is required when there are very few people relative to the number of unknowns in the environment, tasks tend not to be repetitive, and you usually have little time to react to change. Since that describes a well run Unix data center, the Unix CIO has to be a leader, not a manager - but be aware that those who cannot do, cannot lead; and so he has to be a real technologist too.

Rule One: For Unix: hire a leader; for others: hire a manager

As organizations get larger, management tends to grow from the top down: the guy yelling "Heave" can't be heard at the end of the line, and has to get some lieutenants in place as repeaters. It's not unusual, therefore, for mainframe and Windows technology data centers to have several layers of IT management - but remember that the more people there are between your CIO and the actual job, the more disconnected he'll be from the reality of your organization's systems operation.

Leadership, in contrast, grows from the bottom up. As the IT organization develops some people take more and more responsibility and build teams of their own. As a result what you'll see in a leadership situation is a CIO who looks like he does almost nothing but somehow stays connected to the technology, the job, and his people.

Be aware, when looking at a candidate, that there are quite a lot of people who talk the talk, but don't walk the walk.

In particular the reality is that almost every major IT shop has some Unix machines, and so most CIO candidates can claim Unix experience even though they not only have no idea how to run it, but the certainties they do have will raise your IT costs while reducing the quality of IT service your organization gets.

So how do you tell the 1-5% of good guys from the 95 -99% of bad guys? You have to get that from talking to their former colleagues, from looking carefully at what they've achieved, and from your own gut instinct after talking to them.

In my experience, however, there are two "tells" that should trigger concern on your part - these are not absolutes, of course, merely more often right than wrong:

  1. IT executives who see the hardware and software, and not their own technical staff, as the key IT resource tend to be winners in their own careers and losers for you; and,

  2. People who refer to Unix use in terms of boxes and without reference to software and purpose are denigrating both the technologies and the people who use them. Thus someone who claims to have had responsibility for multiple Sun boxes is more likely to be a fraud than someone who claims past responsibility for Oracle on Solaris.


Some notes:

  1. These excerpts don't include footnotes and most illustrations have been dropped as simply too hard to insert correctly. (The wordpress html "editor" as used here enables a limited html subset and is implemented to force frustrations like the CPM line delimiters from MS-DOS).

  2. The feedback I'm looking for is what you guys do best: call me on mistakes, add thoughts/corrections on stuff I've missed or gotten wrong, and generally help make the thing better.

  3. When I make changes suggested in the comments, I make those changes only in the original, not in the excerpts reproduced here.

Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.