ManagementSpeak: This newly-created technology leadership position doesn’t require technical knowledge. It requires good people skills.
Translation: I’m going to give this job to a friend of mine.
This week’s entry was provided by “an IT administrator who left Academe,” where he presumably served as a professional translator.
Month: January 2002
Designing relationships (first appeared in InfoWorld)
Which is more important — skills or manners?
The right answer: Both. Because while mediocre employees will never create excellent results, everyone else will torpedo the work of a brilliant but obnoxious co-worker.
Likewise your IT organization. Excellence is important, but not until after the rest of the business invites you to participate. Relationships matter.
Nor is having a “good” relationship sufficient. You have to have the right kind of relationship — one you’ve designed. But how do you do that?
Last week I introduced a technique for starting the process of designing your relationship with the rest of the business, called either “scenario-based design” or “tales by the campfire,” depending on which stage of the consulting sales cycle I’m in. It replaces abstract generalities with illustrative anecdotes as a way for IT leaders to explain to each other what they’d like IT’s relationship with the business to look like.
Once your team has shared these anecdotes … and probed at them, because you need internal consensus on this … what happens next?
Extract a set of between five and seven relationship design principles. These are abstractions tested against each campfire tale to make sure they’re valid. For example, if one campfire story talks about mandatory adherence to IT standards, “they’re our customers” won’t survive as a design principle. Coercion isn’t something you do to a customer, after all. (Unless you’re an IT vendor, but let’s not go down that path.) Examples of relationship design principles: “There’s no such thing as an IT project, only business change projects, most of which have an IT dimension.” And: “To the rest of the company, IT appears to be a unified whole, in which every IT employee acts as an ‘ambassador’ for the department.”
What good are these design principles? They’re what you need for the next step — to figure out how IT has to change. That’s the payoff.
What really matters in all of this is that you have a structured process to help you figure out what new skills and knowledge your employees will need, how some key processes will have to change, and perhaps what new tools you’ll have to put into place so you can have the right relationship with the rest of the company.
See? Telling tales by the campfire can be pretty useful. You bring the marshmallows.