jump to navigation

Deep And Wide May 6, 2009

Posted by Chuck Musciano in Leadership.
Tags: , ,
2 comments

Information, of quality both high and low, is seemingly infinite in supply. Time, however, is woefully finite. I’ve written previously about using the Three Ps as a structure for status reports, in the hopes of sharing more quality information in a shorter amount of time. Coaching your people to focus on the Three Ps certainly can help, but it doesn’t stop there. It’s also important to recognize the value of Deep versus Wide.

Many people, especially technical people, take a simple approach when communicating up their management chain: convey a lot of detail about the issue at hand. There are merits to this technique: you can show that you know your stuff; you make sure that your boss is truly well-informed; and you can’t be accused of hiding information. There is little downside for the messenger to use this “deep” communication strategy.

Unfortunately, your boss may simply not have the time to listen to all this data, no matter how much they’d like to hear it. In many cases, they need certain salient details to make a decision; once that decision is made, little further information is needed. Instead, they need to move on to the next decision, which may require a similar quick assessment. Leaders often need “wide” communication, rapidly covering many topics at a low level of detail.

These competing goals often set up disastrous status meetings. Staff members go on at length with tremendous detail and background about each project while the decision-makers patiently wait them out, having made their decision long ago. Not wanting to offend or discourage their team, leaders will suffer through lots of extraneous data, sacrificing precious time that could be spent on other decisions. When they do cut things short, teams come away annoyed that their hard work was ignored or dismissed out of hand.

This conflict serves no one and can demoralize a team. Meetings run long and items at the end of the agenda never get addressed. Without clear direction, people have no idea how to communicate effectively with their bosses.

You need to address your desired level of detail with your staff. I tell my team to approach these meetings in a “wide” fashion first, initially addressing each item at a fairly cursory level. If things are as I expected, either good or bad, there is often little need to go “deep” and request more information. If, however, the initial review seems awry, I want to dive into the details and learn more. I expect my staff to have the details in their head so we can discuss them.

That’s a key item: discuss them. I expect my staff to understand the details and to be ready to engage in a good discussion. I do not want them to whip a stack of PowerPoint slides out of their hip pocket on demand. That’s a huge waste of time on their part, time better spent doing real work. Just be ready to have an informed conversation and we’ll all be better off.

Don’t think that this advice only flows downhill. Many CIOs suffer from the same problem, arriving at a senior management meeting ready to go “deep.” This is a double disaster, since deep dives with CIOs eventually drift into inscrutable technobabble. It’s as if we CIOs need a “stall alarm” in our heads that squawks “Pull Up! Pull Up!” as soon as we mention anything with moving electrons.

Your boss and peers are just as pressed for time as you are. Go “wide” until the questions start, and then dive deep as their questions lead you. You’ll save time, win some points, and shift further into your true role as a business leader, not the technology director.

No? No. No! April 22, 2009

Posted by Chuck Musciano in Leadership.
Tags: , , , , ,
5 comments

There is a fatal trap into which all IT Leaders fall, sooner or later.  It isn’t a sudden trap, sprung upon you all at once, but a slow, gentle descent into a disaster that can break your career if you aren’t careful.

It starts by saying “no.”

Every IT organization in the world is understaffed with respect to the total demand for all IT projects contemplated by the business.  While we may have enough people to keep the lights on and systems running, we’ll never have enough people to execute every project envisioned by our peers in the business.  That’s the way it should be: not every project needs to be completed, no matter how badly it is wanted by its champion.

As the owner of scarce resources, IT can become the arbiter of what gets done and what gets ignored.  And therein lies the trap: for every project you accept, you are telling one or more people “no.”  Each person that gets turned away views IT as an impediment to their grand plan, a speed bump on their road to success.  Over time, you’ll wind  up telling everyone no at some point.  You’ll have accrued so much resentment among your customers that they will begin to bypass you to get things done.  When that happens, your effectiveness as a CIO has diminished, and your ability to serve your company has ended.  Soon after that, you’ll be looking for a new job.

There is a better way, and savvy CIOs know how to avoid this trap.  The key is to engage your peers to decide, among themselves, which projects should or shouldn’t get green-lighted.  IT has no business determining the ultimate cost and benefit of a project.  That’s up to the project champion and his or her peers, debating the project in the broader perspective of the business as a whole.  When they finish their debate, your job is to step in and make their collectively-chosen projects successful.  The animosity of those whose projects were declined can be directed at their peers who made that decision, not you as the CIO.

Every CIO needs to develop this governance process in their company.  Whole books have been written on how to gather projects into portfolios, build governance teams at various management levels, and facilitate the debate among business leaders.  The IT organization provides guidance along the way, with scope estimates, impact statements, and technology assessments.  This is done objectively to support the conversation, not to champion a particular cause.

But, some CIOs complain, change only occurs when I initiate it!  How do I get things to happen while being objective?

You have two choices.  The right way is to present your big idea to another business leader, convince them of the merits, and allow them to champion the project.  With them as champion, you step back into your role of objective facilitator and implementation expert.  The more difficult path is to advance the idea yourself, acting as a business leader and not as the CIO.  This requires a deft hand and can be fraught with peril.  Honestly, if you can’t convince someone in the business to champion your idea, why would you advance it on your own anyway?

Good IT governance is a crucial part of every successful company and every successful CIO.  It takes time to develop the culture and process for successful governance, but your patient efforts will be well-rewarded.  Good governance gets you out of the position of being the “guy who always says no.”  That’s important, because the “guy who says no” is soon known as the “guy looking for a new job.”

Three Envelopes April 20, 2009

Posted by Chuck Musciano in Leadership.
Tags: , , , ,
10 comments

According to the apocryphal story, a person is hired to replace someone who was fired for poor performance.  Excited about his new job, he arrives in the recently vacated office to find the desk empty except for three envelopes left there by the now-departed predecessor.  Numbered 1, 2, and 3, a short note explains that they are to be opened only when the owner has really messed things up at work.  Our new hire sticks them in a drawer and forgets about them.

That is, until six months later, when he really messes things up.  Facing a tough situation, he remembers the envelopes.  He tears open envelope #1 to find a slip of paper that reads, “Blame your predecessor.”  Perfect!  He concocts a story that pins the problems on the previous employee and deftly sidesteps blame for the issue.

Another six months go by, and again our friend is in trouble.  This time, the envelopes are fresh in his mind, so he opens #2.  “Blame your coworkers,” it advises.  He does, and once again avoids taking the fall for a problem he caused.

It should come as no surprise that six months later, he’s in trouble again.  Fortunately, there is still another envelope.  He opens number 3, to find one last bit of advice: “Prepare three envelopes.”

A person’s character can be neatly judged when we see how they handle mistakes.  We are all human; we all fail.  When confronted with that failure, our next move paints a picture of how we handle responsibility and blame.  Do you step up and own the problem, or do you reach for an envelope?

Good people step up.  They acknowledge the problem, accept the blame, and work doubly hard to correct the problem.  It is a sad commentary on our world today that most people are pleasantly surprised when you do this.  While you may not be able to completely rectify the problem, you will earn some measure of respect by taking ownership of the issue.  The problem may not be fixed, but your character is intact.

Bad people step away.  They look to blame anyone except themselves, and will sacrifice anyone to protect themselves.  Blaming predecessors and coworkers will work for a while, but you will eventually run out of envelopes.  The problems remain, but you will not.  And your character will be irreparably tarnished.

We all have three envelopes available to us, every day.  We’ll all make mistakes at some point.  When that happens, don’t reach for an envelope.  Own it, fix it, and move on.

Your Next 10,000 April 17, 2009

Posted by Chuck Musciano in Leadership.
Tags: , ,
2 comments

In his book Outliers, Malcom Gladwell explores why people are really successful.  I’ve included the book on my reading list, but can save you the full read by cutting to the chase: Luck and timing.

OK, to be honest, there are a few other factors that make the book worth reading.  One of them is the magic of 10,000 hours.  Gladwell found that, regardless of the field, it takes about 10,000 hours to get good at something.  Violin, hockey, computer programming: whatever the skill, the very best put in 10,000 solid hours of practice before achieving real success in their field.

This holds true for leadership as well.  For years, I’ve noticed that job postings for management positions often require a minimum of five years management experience.  Hmmm.  Five years is equal to 10,000 hours of management experience.  While not explicitly stating it, people have intuitively recognized the 10,000-hour rule for a long time.

Getting your 10,000 hours takes commitment, no matter what your field of expertise.  My concern is not with the 10,000 hours you’ve managed to amass at this point, but with the 10,000 you’ll need to get to the next stage of your career.

Are you content with your current position?  Do you aspire to take on more responsibility and to accomplish more things?  Most people, no matter how happy they may be, desire to do more and contribute more.  Among those with such aspirations, some actually have a plan to get there.  But I fear that even among those with a plan, few have realized that they need to amass 10,000 hours to be really good when they get there.

If you are a technical contributor who aspires to be a manager, how are you accumulating 10,000 hours of management experience?  If you are a team leader who hopes to lead larger groups, how are you getting your 10,000 hours of managing other managers?  If you are a CIO who hopes to take on other operational responsibilities, how are you getting 10,000 hours of finance or operations experience?

10,000 hours is a lot of time, especially when your current job occupies 2,000 hours of time each year.  How do you make this happen?  Even if you put in an extra 4 hours a day, it could take 10 years to get those hours!

First the good news: you probably don’t need the full 10,000 hours to make a career transition.  But you do need some experience, probably on the order of 2-4,000 hours, to make a successful change that will let you get the remaining 6-8,000 at a faster pace.  Even so, 2-4,000 hours is a big investment of time.  How do you do it?

First, simply recognizing that you need it is a good first step.  Armed with that daunting realization, you can develop a formal plan to put in your time.  While some people have jobs that allow them to take on additional responsibilities independent of their main commitment, most of us do not.  In that case, you need to seek out opportunities to combine your current job with your desired job.  The technical contributor should look for project management opportunities, while the team lead could seek out ways to lead their peers.  C-level executives can look for cross-organization openings, and CIOs in particular can often find ways to get deep exposure to other parts of the company. And anyone can volunteer in a local charitable organization; that’s a whole different kind of leadership experience that would serve anyone well.

It won’t be easy, but success never is.  That’s the other side effect of the 10,000-hour rule: only those who really want it badly enough will get the hours.  Everyone else will fall by the wayside.  And that is one of the other big lessons of Outliers: success comes to those who work really hard for a long time.  Are you up to it?  Are you an outlier?

[tweetmeme source=”EffectiveCIO” alias=”http://j.mp/cio033″ only_single=false]

Get It In Writing April 13, 2009

Posted by Chuck Musciano in Random Musings.
Tags: , , ,
1 comment so far

When I worked in R&D, we shared our building with another group whose job was to improve engineering productivity.  They took their job quite seriously and had a mandate to investigate any aspect of the engineering groups that appeared to be in need of improved productivity.  They weren’t engineers, but they did claim to understand process and project management, and they often used a new acronym, TQM, as a sign that they were on the cutting edge of this kind of stuff.

As you can imagine, the engineers were not overly enamored of this group.  Fortunately, the productivity team must have decided that our R&D group was beyond help, productivity-wise, since my group was rarely the target of their attention.  On the whole, our groups got along pretty well and often shared information.

At some point, a few folks from the productivity group got involved in a fairly elaborate project, working with another division in my company.  They were very excited about this project, which involved some fancy new computer system to collect and analyze a lot of data.  The more this woman talked, the more excited she got about the project, and the more doubtful I became of her chances of success.

After a bit, I asked her about system performance.  The data volume was large and the analysis was complex.  Even with the best current technology, a functional solution would be a challenge to build. Would the system be able to perform well?  Would the users be happy with response time?

She didn’t miss a beat.  “Of course, it will perform well!  We wrote that into the requirements!”

And off she went.  With the stroke of a pen, she had solved any and all performance issues this new system might have.  As you might imagine, the project never finished, for a variety of reasons.

It is easy to listen to this story and laugh at the naivete of non-IT people.  How could anyone design such a complicated system and them make it perform well with a simple written requirement?

The deeper lesson (you knew there would be a deeper lesson, right?) is that someone failed to educate this person as to the real complexity of her project.  Non-IT people cannot understand what we do.  Unfortunately, when we do it well, we make it look very easy.  When it looks easy, people assume that it is easy and base their world on that assumption.  This results in projects that fail to meet user expectations.

Users do not want to know the details of our technology.  But they need to know when things are really hard or really expensive.  If they probe, you can explain why. We owe them enough information, matched to their curiosity, so that they can appropriately plan and manage their world.  If we fail to do that, we have failed them, no matter how well our technology works.