HomeLeadership

Manage, then lead

Like Tweet Pin it Share Share Email

Management and leadership are, as has been mentioned once or twice, different. Precisely how they differ is a matter of some controversy, and quite a lot of ink has been spilled arguing what exactly distinguishes the two.

There has been somewhat less discussion of which is the more important, possibly because the answer is so obvious.

It is obvious, isn’t it? Just listen to the two words. Leadership sounds downright inspirational, forward-looking, and important. Management, in contrast, conveys overtones of control, drudgery, and hard, tedious work.

Hmmm. Maybe it isn’t so obvious after all. If we use the Edison Ratio as our metric (1% inspiration : 99% perspiration), perhaps management is the more important of the two. After all, inspiring the troops to battle on for glory and mother country doesn’t do much good if you haven’t first taken the elementary precautions of arming, training, and briefing them.

From a personal perspective the distinction matters only in how you decide to allocate your time. To be effective, you have to be proficient at both — to inspire people to follow your lead, and to make sure they do the job well and deliver results. It’s a reality as true for a chief executive officer as for a first-time supervisor.

Organizationally, the sequence is more clear: Manage first, then lead.

Which is to say, before anyone will take IT seriously as an equal partner, fully engaged in the development of business strategies and tactics, it first has to deliver stable, high-performance systems and networks; it has to complete projects on-time, within the planned budget, and with the original list of deliverables intact; and those deliverables have to help the business change and improve as intended.

Oh, and the Help Desk has to be helpful. Don’t ever underestimate the importance of the Help Desk. It’s impact on IT’s image would be hard to overstate. The Help Desk is the WD-40 of IT, lubricating its relationship with the rest of the business. It’s where the battle for business users’ hearts and minds is won, one resolved problem at a time.

Those stable networks don’t win anyone’s hearts and minds. They do, however, lose them. They’re critical to IT’s success, but only in the way showing up for work is critical to an employee’s career. It isn’t something you get credit for. It’s expected.

Which leaves projects as the battleground for IT’s credibility in the enterprise. IT project completion rates were poor during our industry’s Jurassic period, when file-oriented batch mainframe dinosaurs roamed the enterprise; they continued to be poor after the introduction of database management systems and on-line programming techniques moved us into our Cretaceous period; and they still hadn’t improved as additional waves of technology propelled us through geologic time to the Pleistocene era of object-oriented programming.

IT organizations have finally started to figure it out: Better project completion rates come from better project managers, not better technology. Project completion rates are trending up at last, and that’s a good thing. The only problem is, they’re trending up just in time to be not enough.

Project completion rates are about delivering software to the business that adheres to specifications. Which was enough when IT figured its proper role was to be a supplier and the enterprise was its customer.

The world has changed again, though, and as an industry we’ve caught up just enough to be a step behind the times. Because while we’re finally completing IT projects, the business is figuring out that there is no such thing as an IT project.

We need to take the next step and take it quickly: We and our partners in the business need to stop completing projects and start excelling at change.

Because in the end, taking control of business change is the only goal that matters.