jump to navigation

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]

Advertisements

What Are You Measuring? October 21, 2009

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

When you boil it all down, computing is about numbers.  Two of them, actually, 0 and 1.  Over the years, we’ve worked up from that, of course, so that you have to dig to find the 0s and 1s, but our obsession with numbers is deeply ingrained.  This has bad implications for those of who try to lead IT organizations.

Given our predilection for numbers, most people in IT like to collect them.  Storage usage, bandwidth, code size, database tables, and the like are obvious targets for the numerically fascinated.  But we also collect more abstracted numbers, like project success rates, hours spent doing things, call volumes, and satisfaction indices.  Sometimes, we place a lot of importance on these numbers and work hard to optimize them in some fashion.

Some numbers are necessary.  On the operations side of the house, disk utilization and processor loading are important metrics that drive good capacity planning models.  These numbers are easy to collect and understand because they relate back to physical resources that can be measured accurately.

Other numbers are a bit softer.  Many organizations try to quantify qualitative data, like customer satisfaction.  Gauging satisfaction is tough; there is no number that equates to “great” or “awful.”  That doesn’t stop us, however: our inherent love of numbers leads us to assign numbers to feelings and opinions. That’s not inherently bad when we make simple comparisons.  When one customer rates us a 9 and another decides we are a 1, there is a clear difference of opinion.

The problem with numbers is that they are so prone to manipulation.  Once you make the leap from adjective to value, it is way too easy to start doing arithmetic.  Suddenly, we are averaging those ratings, or worse, computing standard deviations and higher order statistical metrics.  These computed values are worthless, no matter how attractive they may seem.

Consider: if you are in a room with two people, one of which says “I love you” and another that says “I hate you,” the average in the room is not “We like you.” Depending on which way you turn, you are going to either get kicked or kissed.  Math and emotion simply do not mix.

In spite of this, many organizations use these numerical metrics to make business decisions and control compensation.  I’ve seen teams rejoice when customer satisfaction climbs from 3.3 to 3.5, as if the 0.2 difference has any significance.  They are beholden to the numbers and have lost track of the feelings and emotion behind them.

Part of being an expert with a tool is knowing when you shouldn’t use it.  We fancy ourselves to be experts with numbers; we should do a better job of applying them appropriately. In many parts of our businesses, we need to stop focusing on numbers and start listening to people. That’s where you’ll find the real answers and understand your real problems.

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

Field Of Rakes October 9, 2009

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

In the surreal sitcom My Name Is Earl, Earl (our hero) is at one point confronted with a series of challenges that he must complete to rescue Catalina, his brother’s true love. One of the more painful trials is that he must run through the Field of Rakes, blindfolded.  The rakes are positioned tines up, so that each mis-step results in Earl getting smacked in the face with a rake.  Earl’s painful sprint will seem eerily familiar to anyone who has spent any time in IT.

It is easy, in IT, to build your own Field of Rakes.  Each time we disappoint a user we add a rake to the field.  Even the simplest of problems can turn into a rake that will pop up to smack us in the face when we least expect it.

We work hard to do the big things right: system upgrades, new technology deployments, and major projects get lots of attention so that they don’t go awry.  That makes sense; big projects involve a lot of rakes, and the last thing you want to do is add several hundred rakes to the field in one fell swoop.

Unfortunately, we often get the big projects right but fail on the little things.  Individually, the little things don’t present much risk. After all, it would be pretty easy to run across a field with a single rake.  But all those little things, taken over time, can fill a field with lots of rakes.

What can add a rake to your field? Anything and everything.  Denying a request for special software.  Failing to follow up on a support call.  Getting stuck between two competing users, so that you’re guaranteed to get a rake from one of them.  Missing requirements from a user.  Mismanaged expectations on a contract negotiation.  Ignoring what people really need and acting like you know best. I could go on and on, and every seasoned IT pro could add to this list.

How do you avoid adding rakes?  Easy: listen, care, and communicate.  Continuously. Every rake is the result of our inability to communicate and relate to someone.  As service providers, it is inevitable that we will disappoint people.  How we handle that moment and compensate for the problem determines whether we get a rake.  People know we cannot be perfect, but will only be gracious about it if we sincerely and diligently work to meet their needs.

Even with our best efforts we’ll still get a few rakes, and our run across the field may be a bit painful at times.  But diligent attention to people is the real key to IT success.  My Name Is Earl was a series about karma, good and bad.  All those rakes represent your karma, collected over your career. Focus each day to look for the rakes and remove them from your field.  May we all run through empty fields!

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

Legs And Memory August 21, 2009

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

My grandfather had a saying: “A weak memory makes strong legs.”  This seems to be coming to mind more often these days, as my short-term memory seems to expire faster than I can get the items I set out to retrieve.  Multiple trips ensue, helping my legs and overall cardiovascular health, but wasting time and energy.

Forgotten items create more work, both at home and on the job.  While personal memory problems may be inevitable as we become more, ahem, mature, organizational memory loss should be completely avoidable.  Unfortunately, almost everyone is terrible at capturing and using our organizational memory.

Everyone you work with has huge amounts of useful information stored in their heads.  From the moment you begin employment, you are gathering information about what you do, why you do it, for whom you do it, and how you do it.  When you start out, everything is new and you spend lots of time gathering data that everyone else long ago internalized.  Simple questions confront you all the time: who is in charge of that?  Which form do I need?  Why does this work that way?  Your coworkers patiently explain all this, bringing you up to speed in your new role.  After a while, you internalize this information as well, to the point that you stop thinking about it.

When the next new person arrives, they begin the same process.  It is highly unlikely that you documented everything you learned when you started (who has the time for that when you are just getting started?) so this poor soul goes through the same process.  Time is wasted as the weak organizational memory forces them to do a lot of walking.

I have been on teams that set out to solve this problem.  We created formal guides and detailed documentation for our organization in the hope that new hires would get up to speed faster and waste less time.  We tried to create an organizational memory but in the end, failed.  Why? Continuous change.

Capturing most of this information results in a snapshot of a continually evolving process.  That snapshot works for a short time, but eventually fades.  Even after a few weeks or months, there are enough blurry spots in that snapshot that people will once again have to manually fill in the blanks.  As soon as people lose faith in the documentation, they abandon it and go back to the manual process.

Like real memories, captured organizational memories fade rapidly over time.  To reinforce real memories, you must replay them in your mind.  To reinforce organizational memories, you must constantly revisit and update them.  This is time-consuming and expensive, and ultimately not cost effective.  Except for the most important processes that require rigid definition and oversight, most of our business rules exist in the (very) fluid minds of the participants.

The idea of easy, effective knowledge capture has been an ongoing goal for the past thirty years or more.  It has yet to become a reality.  Our collection tools are simply not capable of collecting all that we do and learn in real time.  Currently, people are looking to social media as the next magic bullet that will make this a reality.  As tempting as this sounds, I don’t think it will pan out from a data collection perspective.

The real answer, I think, is to accept that organizational memory is best retained in the heads of the people in the organization.  It may be that these social networking tools will allow us to find the person who knows what we need better than any previous tool.  It may be that capture has never been the problem, but that the connection network has been deficient.  Social networking may let us connect the perfect capture tools (our brains) in better ways than ever before.  As I’ve pointed out before, knowing who knows is the key to success in any field.  We may be on the verge of solving the problem of finding who knows better than ever before.  Memories may continue to fade, but the walking will be greatly reduced.  We can only hope.

Until then, I’ve got other problems.  Where did I put my keys?  Time to start walking…

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

Til Death Do Us Part August 17, 2009

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

It is said that many marriages run aground on the rocks of unrealistic expectations.  The old saw claims that every bride looks at her groom and thinks, “I can change him!”  Each groom gazes at his bride and thinks, “I hope she never changes!”  If a woman is seeking a project and a man is seeking a prize, both will be sorely disappointed.

Hiring someone is like getting married.  After a brief courtship, employee and employer embark on a (hopefully) long-term relationship, seeking mutual benefit and collective success.  Sometimes it works out, but all too often it does not.  A lot of that has to do with how we hire, and if we are acting like the apocryphal brides and grooms.

There are aspects of a new hire that should never change.  In that sense, a hiring manager must think like a groom.  Ethics, attitude, enthusiasm, and personality are ingrained in a person long before they reach your door.  You need to make sure that these parts of a candidate align with your company culture.  It is absolutely unrealistic to think that you are going to change core aspects of a person’s personality once they join your team.  If there isn’t a strong alignment with your needs in these areas, call off the wedding before it’s too late.

Conversely, there are parts of a person that you can change once they are on board.  In particular, some technical skills can be taught or expanded.  Certainly, understanding of your specific business processes can only happen once the job begins.  We often reject candidates because they do not have the exact list of technical skills we seek, when in fact we could teach some of those skills to an otherwise qualified candidate after they start.  The trick, of course, is to know which skills are required at the beginning and which can be learned later.  You need to think like a bride, but be a discerning one.

Often, in the excitement of courtship, we make bad decisions.  A technically qualified candidate is a lousy fit, culture-wise, but we think we can change him.  A delightful person with all the right social skills turns out to be untrainable.  Someone who seems great during the interviews winds up being dramatically different a few months later; if only we had paid closer attention while we were dating!

Like a bad marriage, these bad hiring decisions hurt the candidate, the company, and everyone surrounding them.  Parting ways can be expensive, litigious, and hurtful.

An approach that borrows from both the bride and groom will serve us all best in the long run.  Know what to change, accept what you cannot, and you’ll have a much better chance of a productive relationship.  Be patient and wait for the right candidate, because your Mom’s advice holds true as well: there are plenty of fish in the sea.  Catch the right one!