Several years ago, deep in the throes of an empowerment fad, I became the “culture coach” for our IS organization. My fellow IS managers questioned my qualifications.
“You’re a techie!” one of them exclaimed. “The job needs someone who thinks about the human side of management!”
“The two aren’t mutually exclusive,” I replied, pondering how well someone who made that statement in public really understood the human side of management. My response didn’t entirely defuse the skepticism. I got the job anyway, probably because (a) the other IS managers viewed it as a career buster, and (b) I had the most important qualification – a thick skin.
Juxtapose an event a year earlier. A friend and fellow manager asked me to mediate a situation with one of her technically strongest employees, who didn’t think she really understood how much he contributed to the organization. Since I was a techie, she thought the guy might relate to me better.
As a previous column proposed, leadership is defined by who seeks approval from whom. Technically proficient employees – and IS needs a cadre of technically adept employees – often devalue the approval of technically ignorant managers.
This should be unsurprising. Soldiers prefer generals who have seen combat – they understand what soldiers go through in battle and are less likely to issue stupidly lethal orders. Journalists like editors who know how to write – they understand the process of ferreting out a story and are less likely to ruin good copy.
Programmers, DBAs, network engineers, all understand that managers who have never written and debugged code, made design compromises for the sake of production tuning, or tracked down a bad cable, won’t be able to judge performance. They’re right.
That’s why technical employees too often watch their ideas and recommendations go unheard while promotions and recognition go to their non-technical peers – like promotes like.
Technical employees understand that managers who have never held technical jobs are more likely to establish ridiculous deadlines, create unworkable project plans, embrace silly fads, and fall for extravagant vendor claims. And of course, they hold employees accountable for making it all work.
Technical employees want to walk into their manager’s office, describe a dust-up with some willfully ignorant end-user and what they did about it, and have the manager say, “Here’s something you might try. It’s worked pretty well for me in similar situations. And don’t worry – I’ll explain the facts of life to the user’s manager.”
Most important: leadership requires establishing an organization’s overall direction by articulating a description of what the future must look like. Technical employees are simply unlikely to find such a picture credible when painted by someone whose total technical depth consists of having attended one James Martin satellite conference.
Think about Bill Gates’ status as industry leader. At some primal level it’s deeply satisfying, despite Microsoft’s questionable business practices and even more questionable software design. The reason, I think, is that Bill Gates started as a personal computer hobbyist and weenie. He’s one of us.
Does this mean non-technical IS managers must immediately tender their resignations (after hand-writing them and handing them to a secretary to type, since they don’t know how to fire up the word processor)?
No. Nor is business acumen unimportant in the job – business acumen is absolutely vital to a CIO’s success. Too.
If you’re a non-technical IS manager, though, you have a big hill to climb. The most effective IS leaders act as high-level technology consultants for the rest of the company, understanding business issues, envisioning broad-brush solutions that maximize technical leverage, and providing insight into what will be required to make it all happen.
Then they have to translate it so the people who have to make it all happen understand what’s required, why it’s important and exciting, and that it’s feasible.
No big deal.