jump to navigation

Skin In The Game November 9, 2009

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

With clouds on everyone’s mind these days, more and more CIOs are beginning to consider cloud-based services.  There are still a lot of concerns with this, depending on the system or service you seek to move to the cloud.  In particular, what happens when the cloud goes down?

When negotiating with cloud service providers, the conversation inevitably turns to service level agreements.  Typically, a vendor will promise some level of availability, with some prorated refund if the service is unavailable for an extended period of time.  Thus, if a service is unavailable for more than 24 hours, you might get one-thirtieth of your monthly service fee refunded.  Less than twenty-four hours? You might get nothing at all.

Does anyone, except for the service provider, think this is a good deal?

The cost of an outage is not the actual cost of the underlying service.  The cost of an outage is the value of the business impact you suffer.  If your e-commerce platform goes down for an hour, costing you $100,000 in sales, you should get $100,000 from your service provider.  Needless to say, when you mention this to potential providers, they tend to get a bit defensive.  “You can’t expect us to fully reimburse your lost business, can you?”  Well, yes.  Yes, you can.

If your service is good enough for a client to bet their business on, they’d expect you to have some skin in the game.  If you aren’t willing to put money on the table that says you are as good as you claim to be, why should they be doing business with you? Does anyone want to be the CIO that, while explaining a multi-million dollar outage to his board, concludes with “but we got a check for $1,200!”

What is baffling is that this would be an easy guarantee for a qualified vendor to make.  Hedging risk against failure is an actuarial problem.  Why wouldn’t a vendor purchase an insurance policy against just such an occurrence, in an amount that would cover the exposed risk up to a certain point?  Roll the insurance costs into the service fee and proudly market your “Million Dollar Guarantee” far and wide.  I suspect you’d get some business.  I also suspect that you’d get really good at providing exceptional service.

A lot of CIOs are naturally reluctant to deal with service providers who refuse to share the risk equally.  Vendors who find a way to put their money where their mouth is will gain the respect, and business, of discriminating CIOs.

[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio129″ only_single=false]

Advertisements

I Feel Your Pain November 4, 2009

Posted by Chuck Musciano in Leadership, Technology.
Tags: , , ,
add a comment

Users are in a tough position.  They’ve evolved to the point where they cannot do their jobs without computers.  The systems that they use are becoming more and more sophisticated, with equally sophisticated interfaces.  Worst of all, they have little or no control over how those systems are built.

Our users rely on us to build systems that are easy to use, reliable, and consistent.  They have no idea how we do this, not do they care.  They trust us to take care of the awful details of system design and development to make things that they find useful.  Regrettably, I don’t think we on the IT side of the house do as good a job as we could on their behalf.

We often make design decisions that cause users great angst.  I’m not talking about sweeping design changes; I’m thinking more about the small, subtle things that can make a big difference in a user’s life.  The layout of a screen, the ordering of a menu, the arrangement of a list can dramatically affect the usability of a tool.  Poor usability results in unhappy users.

Many times, these kind of decisions get made on the basis of how complicated it can be to implement a better alternative.  In short, we reduce development time and expect the user to deal with a less-effective interface.  We reduce developer pain at the expense of user pain, and that’s wrong.

I’ve written about this before.  One of my biggest peeves in just about every web site on earth is that you cannot enter anything but digits into a credit card number field.  The developer will not set the field to “numeric only;” instead, they’ll put some awful text near it that explains that you should not type dashes or spaces in the field.  Here’s a big idea: how about you write some code to strip out dashes and spaces, so I can type the number in a way that make sense to me?  The developer saved twenty minutes; users spend collective years trying to type things correctly.

There are countless examples of this in every system we use.  Time and again, developers and designers make their lives easier by asking users to do a little bit more.  The problem is that the development time is incurred once; the user time incurred over and over and over again, for years.

We owe our users better. They trust us to build systems they can use.  We need to feel their pain, take it on ourselves, and remove it from their day-to-day lives.  Users are the most important part of any system; we need to show that we understand that by building things that respect their time and energy.  Show your users some love: build things that put them first.

[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio126″ only_single=false]

Knowing When To Stop October 30, 2009

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

A recent issue of Wired had a great article on the concept of good enough: when products meet enough needs that consumers are happy. The author gave several examples of good enough: MP3s instead of CDs, Flip cameras instead of high-end video cameras, and even Predator drones instead of manned fighter jets.  In each case, the product is woefully short of perfection, but is still so useful that the perfect alternative is being sidelined in the market space. (As an aside, you may not need to read the entire Wired article; for many of you, my summary will be good enough).

The idea of good enough is certainly not new, and is simply the latest incarnation of the 80/20 rule.  Unfortunately, I think many of us who understand the 80/20 rule are still struggling to implement it in practice.  It turns out it is really hard to know when to stop.

In a world of dwindling development resources, knowing when to stop is crucial to providing maximum service for the minimum investment.  The moment a developer begins working on the eighty-first percentile of a project, they have gone too far.  They need to be pulled off and turned loose on the first percent of the next project.  This is true for everyone in the development stream: the business analysts, the designers, the infrastructure people, everyone.  At some point, they are spending too much time on a project, expending effort that will not result in proportionally additional value.  They need to let go and move on.

[Note that this is not true for testers.  There is no 80/20 rule for testers.  They need to test 100% of the 80% that has been built.  More on this in another post.]

The problem is that no one knows when they have reached the eighty percent point.  Very few projects have a bounded definition that makes it easy to see when enough is enough.  Even when you do have such a bounded definition, user-induced scope creep can easily push that definition further and further out, dragging the eighty-percent point along with it.

It is often the case that a team will unknowingly extend the scope of a project as they work through the details of the spec.  Seemingly appropriate questions lead people down paths that occupy way too much of their time.  Everyone in the room knows how they got there, and why they are discussing some arcane feature, but no one was able to throw the flag and stop the process along the way. It all seems to make sense at the time.

That’s when you need a “sudden interrupter:” someone who comes to the process late, has not been a part of the incremental walk, and can easily see that things are off-track. They provide a bit of cognitive dissonance that allows the team to reset, regroup, and reassess what they are doing. Even if the group decides that they do want to continue their discussion, the pause allows them to confirm that they are on the right track.

I doubt that many people carry the title of Sudden Interrupter, but I’m beginning to think we need a few of them wandering about.  Gentle challenges during any decision-making process are generally helpful, whether you are designing software or refining a budget.  If nothing else, having to explain “why” to an outside observer is a constructive, cathartic exercise. So, go help someone.  Interrupt them!

[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio124″ only_single=false]

Infectious Diseases October 28, 2009

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

Many years ago, I worked with a group of software developers who were situated in a typical cube farm.  One day, a woman came to work clearly not feeling well.  As the morning progressed, her conditioned worsened, punctuated with repeated trips to the restroom.

Her cube neighbor was concerned that she might be carrying some infectious disease.  Sure enough, as time went by, he began to feel sick himself.  Soon he was running to the restroom as well, and by the end of the day they had both gone home.

It turns out that she was suffering from a bad bout of morning sickness.  Her coworker, it seemed, had contracted the rarest of all airborne maladies, psychosomatic male pregnancy.

While pregnancy is tough to catch at work, other diseases spread easily.  While diseases can usually be treated and disposed of, other infections can be much tougher.  These kinds of infections include attitude, ethics, and courtesy.

People tend to mirror those around them.  If the workplace is a sad, depressing, miserable place, everyone in it will be sad, miserable, and depressed.  Happy, upbeat, pleasant places create happy, upbeat, pleasant people.  The prevalent mood spreads quickly, one way or the other.

As leaders, we have tremendous control over what is in the air.  Our attitude sets the tone for the team.  We need to choose our attitude carefully, because it will be mimicked, consciously or unconsciously, by those around us.  While maintaining a continuously Pollyannish approach isn’t going to fool anyone, genuine confident enthusiasm is a good thing.

We also need to be sensitive to the “carriers” in the group, both good and bad.  Every group has a few people whose genuine positive spirit is always a welcome breath of fresh air.  Their approach lifts every project, enhances every meeting, and brightens your day.  These people are treasures and you need to specifically praise them for their good effect on the team.

Conversely, every group has a few Eeyores.  These people find the cloud around every silver lining, know exactly why every good idea will fail, and seem to find ways to bring even the happiest person down.  These people can be fatal to your organization.  Oddly, many of these people have excellent technical skills, so we overlook their attitude to take advantage of their ability.  We make excuses for their behavior, hoping that their technical contributions outweigh their social impact. You can do that in the short term, but you cannot tolerate it for long.  A person is a whole package, and attitude problems are no more or less serious than technical or ethical ones.

As leaders, we need to remove the infectious bad attitudes from our group and allow the good attitudes to more easily spread. Who are you infecting today?

[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio123″ only_single=false]

Nuts And Chocolate October 23, 2009

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

I really like chocolate.  I also really like nuts.  It is not surprising that I like nuts and chocolate together, at least in the form of a Mr. Goodbar, which blends the perfect combination of milk chocolate and peanuts into a single treat. I recently discovered, however, that I do not like dark chocolate and nuts together.  In fact, they are in such conflict that taken together, they actually ruin each other.

As all aficionados know, dark chocolate is best when savored slowly, melting on your tongue.  You do not chew dark chocolate; you let it dissolve in your mouth and release all its flavors over time.  Nuts are a different story. They don’t melt; you have to crunch them up to release their flavor.

Mixing these two in one mouthful is a disaster.  If you chew, you enjoy the nuts and turn the dark chocolate into tasteless, crumbly wax.  If you let the chocolate melt, you are left with a mouthful of soggy wooden nut bits, which is no fun.

Every day, our leadership roles present us with nuts and chocolate in the form of various challenges.  Some require fast, decisive action: we must chew them up and move on.  Others require a more methodical approach, taking time to melt before they can be fully understood and solved.

Unfortunately, we tend to confront more nuts than chocolate in our day-to-day jobs.  This conditions us to want to handle things quickly, to react and decide, to figure it out and move on.  Every problem seems urgent, every concern is pressing. As we chew up the nuts, we inadvertently chew up some chocolate, creating bigger problems.

Some problems require time. In some cases, you can use that time to reflect and consider alternatives, to really seek the right response to an important issue. In other cases, some problems solve themselves if you just let them.  This is especially true of interpersonal squabbles; letting people figure things out on their own is preferable to injecting yourself and trying to referee a no-win situation.

The trick, of course, is to separate the nuts from the chocolate.  Waiting for nuts to melt isn’t helping anyone; you need to dive in and chew them up quickly.  I’m afraid there is no simple answer to this problem.  Experience is the best teacher, and comes with the requisite scars and lessons learned.

In the meantime, as you build that experience, take a moment to think about the issues that present themselves.  Think through the implications of waiting versus diving in.  You may find that some issues are better solved later, freeing you up to deal with the urgent ones more effectively. And while you are deciding, have a piece of chocolate. Or some nuts.  But not both at the same time.

[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio121″ only_single=false]