jump to navigation

Measuring Metrics January 27, 2010

Posted by Chuck Musciano in Leadership, Technology.

It’s a good bet that most people saw all or part of the Super Bowl, either at home or at a Super Bowl party. Suppose, as the game begins, the cable feed goes out and the television goes dark.  Amid the howls of protest of those watching, you grab the phone and frantically dial your cable provider.  When you finally reach a real person to complain of the interruption, they provide this explanation:

We’re sorry for the interruption, but our records show that this is our first outage in your area in more than two months.  Even though we project that the outage will last for at least four hours, that still means that we provided service 99.72% of the time. This easily exceeds our 99.5% target metric for excellent service! We appreciate your business and thank you for your patience as we work to restore your service. Thanks for calling!

Happy now? Of course not. Yet many folks in IT hide behind metrics in a similar fashion.

It is said that anything you measure will improve.  That provides a strong incentive to measure system availability, since we’d all like to hit that elusive goal of 100% uptime.  But there is a difference between using those metrics to improve our performance and using those metrics to improve our public relations.

Uptime tracking coupled with root cause analysis will help you find and fix many tiny problems that may exist in your environment.  Most mature IT shops have long ago figured out how to run their systems without catastrophic failure.  We can all hit availability of about 98 or 99 percent on a regular basis.  Getting much higher than that, however, involves ferreting out deep issues that may only surface under unusual circumstances. It takes discipline and focus to get there, and metrics can really help.

Metrics should never be used as a defense.  When users are affected by an outage, the last thing they want to hear is how well you’ve been doing prior to the problem.  It doesn’t matter, and you’re only annoying people that are already upset.

Similarly, metrics should never be used to tell the world what a great job you are doing.  When things are running fine, announcing that they are fine just makes you look boastful.  Most users just want IT to work, and they don’t want to think about it beyond that.  Building on our cable analogy, how would you like the cable company to call once a month to tell you that the service is running just fine?

From the user’s perspective, availability is measured as a binary value: yes or no.  There is no average, there is no track record, there is no target goal.  You either provide your service or you don’t.  Metrics matter internally so that we can improve our service.  But they have little bearing on user opinion and can actually do more harm than good.  Use them wisely.

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

Five January 25, 2010

Posted by Chuck Musciano in Leadership.

I had the opportunity to hear Don Yaeger speak about the elements of greatness last week.  It would take weeks of posts to share everything he said.  His talk was eloquent, moving, and inspirational.  If you ever have the opportunity to hear him speak, do not miss it.

Don spoke about his relationship with John Wooden, the legendary UCLA basketball coach. At 99, Wooden still mentors Don on a regular basis.  Don was kind enough to share some advice from Wooden, involving the lesson of five.

Yaeger noted that if you want to know your child’s GPA, don’t call the school or ask your child.  Find the GPA of their five closest friends, and your child will most likely be in the middle of that range. If you want to understand the morals and ethics of someone, understand the morals and ethics of their five closest friends.  If you want to understand the business philosophy of someone, learn about the business practices of their five closest business associates.  You get the idea.

Wooden instructed Yaeger to take a sheet of paper and make three lists.  In the first, list your five closest personal friends.  In the second, list your five closest business associates, and in the third, your five closest partners in service, such as your church or Rotary.

Now examine each list.  Do these people want what you want?  Do you aspire to be like them?  Do they share your dreams and reflect your morals and ethics?  Will they help you get to where you want to be, either personally, or professionally, or in service?  Would those people put you on their list?

If so, strengthen those relationships and make sure you give back to them as much or more than you are getting.  Recognize the value of that group and grow it to your mutual benefit.

If not, why not?  Have you chosen poorly?  Are you maintaining bad relationships?  How long will you maintain connections with people that will hinder your ability to become great?

This is a simple but powerful exercise.  These close relationships define us, and we are often too busy to give them conscious consideration.  Good or bad, we need to create and assess these lists on a regular basis.  We want to surround ourselves with people that will challenge us to be better.  And perhaps more importantly, we should live our lives in a way that others will want to have us on their lists, too.

Have you made your lists?

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

Living In Olden Days January 22, 2010

Posted by Chuck Musciano in Technology.
add a comment

Recently, a friend was kind enough to share with me an unusual book: the 1924 Ford Model T parts catalog.  This beautiful book includes detailed drawings of most major parts, along with descriptions and pricing for every component of a Model T.

For each part, the catalog includes part numbers and the appropriate model year, as you might expect.  But it also includes an odd item: a “code word.”  What on earth is a code word, and why would you need one for car parts?

It turns out that back in 1924, people would often send their orders to Ford via telegram, a very early precursor to shopping on the web. Given that you paid by the word to send a telegram and that errors could be costly, you could specify your part using its code word instead of its part number and description.

Thus, if you were in need of a crankcase lower cover (part number 3101) you would send the code word “Closure.”  This ensured that you would not wind up with a complete crankcase (part 3100), whose code word was “Closet.”  That’s a big difference, since a crankcase lower cover would run you $0.35 while the whole crankcase would set you back $11.00.

There were also code words for shipping, so that the terse message “Closure Topersteen” would order one crankcase lower cover and ship it to you via standard freight.  If you want to upgrade to express shipping, you’d use “Closure Toperig” instead.

We live in an age of glorious technology, which leads us to believe that previous eras were backwards and hopeless.  In fact, people have always been clever and creative; they simply had different tools at their disposal.  Using those tools, they crafted the best possible technical world, one that seemed glorious and amazing compared to previous times.  Imagine how they lived in the olden days, when they ordered car parts by mail and had to wait three extra days as a result! Code words and telegrams were an amazing improvement.

As we struggle to build, deploy, and exploit all the new technology that comes our way, both personally and professionally, we would do well to remember that we will be seen as living in a hopelessly backward time.  “Imagine,” they will say, “how people lived with such primitive tools.  They must have been miserable!”

Not at all.  We are always living in the best of all possible worlds, in the best of all possible times.  And with luck, determination, and perseverance, we’ll continue to make it better and better.

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

A GREAT Idea January 20, 2010

Posted by Chuck Musciano in Leadership, Random Musings.

As some of you may be aware, a company has recently announced the invention of a new punctuation mark that can be used to indicate sarcasm.  The so-called “sarcmark” is intended to clearly denote sarcastic comments, much as question marks and exclamation points confirm that a statement is actually a question or an exhortation.

Like me, your first reaction is probably one of extraordinary relief, with the burden of missed sarcasm forever removed from your written communication.  How did we ever get along without a sarcmark before?

My second reaction is to presume that the creators of the sarcmark are simply engaging in a little viral marketing.  Although the mainstream media is treating this as a real news story (surprise!), the entire concept is outlandish and impractical.  That said, they are selling software that allows your PC to create and display sarcmarks, so there is a bit of entrepreneurialism in there as well.

It goes without saying that the sarcmark is doomed to fail.  Not because it is a silly idea (it is) but because it is going up against too much legacy technology to ever succeed.  From that perspective, the sarcmark does provide a useful lesson.

Modern punctuation was pretty much settled a few hundred years ago.  There isn’t a lot of space (or demand) for innovation in this arena.  Nonetheless, if we were all still writing everything by hand, you might be able to create a new punctuation mark and get some people to start using it.

Unfortunately, we produce most of our written content by machine.  Those machines use standardized encodings for characters and standardized fonts for presentation.  The idea that you could revise a standard like ASCII or Unicode to include a new symbol, let alone update a substantial portion of the thousands of fonts used worldwide, is ludicrous.  The combined inertia of these systems overwhelms a tiny effort like the sarcmark.

As agents of change, IT leaders must carefully assess and understand the inertia that threatens every initiative we undertake.  Is the inertia overwhelming?  Will it crush our efforts?  Is there enough value to overcome the challenge?  With careful consideration, we can choose our battles wisely.

More importantly, is there a better solution that simply circumvents all that inertia?  The best innovation occurs when a completely new path is developed, one that bypasses all the problems at hand.  People are far more open to solutions that relieve them of the burden of difficult change and allow them to easily adopt new things.

In the realm of symbols, emoticons have succeeded in creating new symbols by easily combining existing glyphs into new patterns.  No one tried to create a new symbol for “smiling;” they created the sequence “:-)” instead.  By stepping around the inertia of character sets and keyboards and fonts, people developed a whole family of new “symbols” that expanded the meaning that could be inserted into a message.

As we tackle problems, we need to find more solutions that build on existing successful tools and avoid those that creation unwarranted, expensive disruption.  At the very least, we stand a better chance of hearing “Nice job!” without needing a sarcmark.

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

Pick Your Bridge January 18, 2010

Posted by Chuck Musciano in Leadership, Technology.

Regular readers know that I have some strong concerns about cloud computing, especially in the arena of security.  I’ve enjoyed a number of vigorous debates with both vendors and fellow CIOs regarding their comfort level with cloud-based services.  Personally, I’m comfortable moving small, non-material business processes to the cloud, but will continue to manage my core business applications in my own data center.  Other CIOs are at different points on this spectrum, with valid reasons for their decisions.

Invariably, many of these discussions reach a point where a proponent of cloud stuff will point out that some very large companies have made big commitments to cloud technology, moving some or all of their infrastructure and systems to the cloud.  The implication, of course, is that if these big companies are comfortable with the cloud, I should be, too.  As my mother would be quick to point out, if these companies were to jump off a bridge, should I jump off too?

There is a comfort in following the paths of others, but there is no guarantee of success.  The only thing that matters in a decision like this is what is important to your company.  Other companies are making decisions based on their own criteria; they may or may not match yours.  Simply assuming that large companies are somehow smarter than you may not be a wise decision.

In the classic Simpson’s episode Krusty Gets Busted, Bart’s idol, Krusty the Clown, is accused of robbing the local Kwik-E-Mart. The entire town of Springfield rises up in opposition to Krusty.  Bart is horrified to find that even his father Homer has turned against Krusty.  Bart complains, “Dad, you’re giving in to mob mentality!”  To which Homer replies, “No I’m not, I’m hopping on the bandwagon!  Now get with the winning team!” In the end, of course, Krusty is exonerated when it is discovered that his evil sidekick, Sideshow Bob, was the real culprit.

So many technology decisions seem to become a choice between mob mentality and joining the bandwagon. In reality, what others do should not factor into the decisions we make for ourselves and our companies.  We need to make a decision based on the unique merits of the case.

That said, critical market mass should be factored into a software or system decision, since it affects long-term maintenance and support pricing.  Nonetheless, simply assuming that something is right because others are doing it is a poor decision process.

CIOs have to pick their way through these minefields everyday.  Where will you find yourself today? As part of the mob, happily on the bandwagon, or following someone off a bridge?  What would Bart (or your Mom) think?

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