All Posts in Organizational Effectiveness

|In: Leadership|Last Updated:

Since sports metaphors are popular among management consultants (yielding grossly inflated speaking fees for washed up sports figures in the bargain) I always love hearing interviews with the coaches of losing sports teams. I’ve synthesized a typical example:

“Ed Jones just didn’t play very hard this game,” complained the coach. “And John Smith demoralized the team with that interview he gave you reporters yesterday. If he’d spend more time trying to hit the ball and less time spouting off, it would give the whole team a lift. And then there’s Jim Johnson. Sure, his stats look good, but he’s grandstanding. He needs to be more of a team player.”

And on, and on. If I had a manager who publicly berated his staff like that I wouldn’t bother firing him.

I’d hire a recruiting firm to sneak him into my fiercest competitor instead.

And then there were the professional football players in the late ’80s, who arm-twisted the concessionaires into supporting their strike. The next year, when the concessionaires went out on strike, do you think the football players supported them? Not a chance.

This may be one of the more useful crossover lessons from professional sports to business leadership — say what you have to in order to get your way, then conveniently forget it when it becomes bothersome.

The first time I was exposed to “employee involvement” our visiting consultant, diluting his sports metaphors a bit, explained how it would transform the role of the leader: from decision-maker and expert to “coach and mentor”.

Now there’s an energizing concept.

You still hear this nonsense every so often, so let me clear it up once and for all: coaching and mentoring are wonderful ancillary qualities for a leader. The job, though, consists of setting direction, establishing priorities, and clearing away every obstacle to success.

Somebody famous once contrasted management and leadership as “doing things right” vs doing the right things. I’m not sure I agree. I think leadership makes sure decisions get made; management makes sure jobs get done.

Making sure decisions get made isn’t the same as making all the decisions, and the most important difference between good and bad leadership is decision style. There are four ways to make decisions: Command (you just make it), Consultative (you ask a lot of people, then make it), Delegated (you give it to someone else to make), and Consensus (you ask everyone involved to make it together).

The worst leaders make a lot of command decisions. Command decisions make sense in a crisis (there’s no time to ask anyone else) and when the leader knows so much more than anyone else that other opinions add no value. Leaders who make lots of command decisions either have lots of crises (bad leadership) or weak, untrained staff (bad leadership).

Good leaders make a lot of consultative decisions. Gather a lot of facts, ask for a lot of competing opinions, and you’ll be a lot smarter about the choice you have to make.

Good leaders delegate a lot of decisions. Figure out the best person to make the decision and give him or her ownership of it. You’ll deal with less detail and the delegatee will grow with new responsibility. (Now, you get to help that person figure out which of the four decision styles to use. In most cases, I’d recommend the consultative style.)

Reserve consensus decision-making for very special situations. Consensus decisions are expensive and time-consuming. Use consensus processes when (a) you need everyone involved to own the decision; or (b) you’re leading your peers to a decision nobody has the authority to make.

If you find yourself trying to do everything by consensus, you’re not leading. Quite the opposite, you’re avoiding leadership, playing it safe.

You’re making sure you can blame the team.

Comments

|In: Leadership|Last Updated:

Back when I was studying electric fish, I learned a bit (no pun intended) about information theory. The math isn’t too difficult and has wide and surprising applicability.

Information resolves uncertainty. If someone flips a coin, you’re uncertain as to how it landed. With a fair coin (one that lands on each 50% of the time) the information needed to resolve your uncertainty regarding the outcome is called a “bit” (short for “binary digit”).

Toss two coins. 50% of the time they deliver a heads/tails combination (one bit again); two heads and two tails each happen 25% of the time – two bits each, because those events are twice as unlikely. Which, I suppose, is why we call a quarter “two bits”.

The weighted average of all outcomes – the probability of each outcome times the bits in each outcome – is the average information content in the event. In our double coin-toss, it’s .25*2 bits + .5*1 bit + .25*2 bits = 1.5 bits, or more generally, -SUM(p(i)*log2p(i)), if you care.

Try this: take some function and rate every application used by the employees that accomplish it. 5 means it’s critical, 3 means it’s important, and 1 means it’s used somehow. Add the ratings together and make each application’s rating a proportion of the total (“p” in the formula). Compute the formula – call it “application complexity” (more complex environments need more information to describe them). Fewer, better-integrated applications will reduce the complexity – and improve the end-user environment.

In English, the information formula means the more obvious the statement, the less information it contains. That’s why “dog bites man” isn’t news (low information content) – while “man bites dog” is.

I’m afraid this column will have no information content for many readers, as it may seem pretty obvious. It wraps up our series on interacting with end-users, though, and the series would be incomplete without it, so I’m going to press on.

Most Information Systems organizations have some form of executive steering committee to make sure its priorities and initiatives stay in line with the company’s strategic objectives and critical success factors. If yours doesn’t, you should form one right away.

A surprising number of IS departments have no corresponding feedback channel to help with the nitty-gritty day-to-day crud. If you haven’t organized a PC users group or something along those lines, your life is much harder than it needs to be.

If you support PCs and networks in an organization of any size, your chance of understanding the concerns and priorities of the end-user community are pretty dismal. It’s a diverse group of individuals, with widely varying priorities, levels of expertise, work habits, and deadlines. This constituency has no organizational clout, no easy consensus, and a large ability to create demand for your services.

A solution that’s worked well for me is to create an internal advisory group. Call it a PC Users Group, Network Advisory Council, or make it a Mentor Group function. The specifics are less important than how you position it. Your goal is to make this staff-level group a surrogate for the whole end-user community. Its consensus defines a lot of your requirements, and you, of course, set its agenda and facilitate its meetings.

Keep this group in the loop regarding server upgrades, software changes, training schedules, standard workstation configurations, PC delivery schedules, and every other aspect of your operation. Make sure its members understand your constraints and what you’re doing about them. Publicize it, give it a strong, clear advisory role, and also make sure its members understand their role in getting the word out to their coworkers. It’s a great way to transform fragmented demands into coherent requirements.

Comments