jump to navigation

Toddler Audit December 4, 2009

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

As any parent can tell you, there comes a time in a child’s life when they seek to learn everything.  Around the age of three or so, children suddenly want to understand the reason for everything.  No matter what the issue, they ask one simple question, over and over again: “why?”

Parents are driven to distraction by this, as their children soon discover.  It’s tough to argue with a thirst for knowledge, though, so parents will tolerate a lot of questions before hiding behind the old stand-by of “because I said so.”

As leaders, we would do well to emulate toddlers on occasion, at least on the thirst-for-knowledge front. But don’t misunderstand: I’m not suggesting that we go around asking other people “why?” They have enough  to do without our constant intrusion.  Instead, we need to spend time asking the question of ourselves.

The pace of leadership is ever-increasing, which forces us to make decisions rapidly.  We rely on instinct and history, letting our experience guide us.  There’s nothing wrong with this, of course; it’s why experience is so important in making successful decisions.

Even so, we need to stop periodically and make sure we understand why we are doing certain things certain ways.  And like that persistent toddler, we need to question each successive answer to drill into the foundations of our decisions.  If those foundations prove to be solid, then our decisions will be solid.  If you find yourself winding up with answers like “we’ve always done it that way” or “because so-and-so says so,” you may want to reconsider what you are doing.

This “Toddler Audit” is an obvious exercise when dissecting a technical decision.  Technical decisions have technical foundations, and it is relatively easy to get to the bottom of why you are selecting a tool or deploying a system.  A Toddler Audit can also be useful during a budgeting exercise as you seek to justify each item and confirm that you have a good number assigned to each expense or income item.

Toddler Audits get a bit trickier on the soft side of our business.  If you are figuring out how to challenge people, or divide up work, or expand an organization, the answers to “why” become much more subjective and soft.  That’s not to say that the process breaks down; you just need to be more thoughtful with your answers to make sure you are being honest with yourself.

Finally, Toddler Audits really help analyze what we are doing at any given point.  Here’s an interesting exercise: at random times during the day, stop and ask why you are doing whatever it is you are doing at that exact moment.  Is it the right thing to be doing?  Is it the most important?  Is it taking up too much time, or stealing your attention from something else?  All good questions, and you should have good answers.

If you survive a Toddler Audit, I suspect you’ll know a lot more about the foundations of your decision process, which should improve your decision making.  It may even prepare you for the dreaded Teenager Audit: “Why not?”

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

What’s Your Iron Boat? November 23, 2009

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

In planning for his great trek across the United States, Meriwether Lewis had a brilliant idea: a portable boat, made from a collapsible iron frame and covered in animal skins.  After leaving the Mississippi, his group would carry this boat until they reached the river rumored to extend to the Pacific, whereupon they would assemble the boat and sail away.  It was cutting edge technology for 1803 and Lewis absolutely loved the whole idea.

You can imagine what his men thought of it.  The boat frame was cast iron and weighed 176 pounds.  Fully assembled, it would be 42 feet long and could carry 8,000 pounds of men and equipment.  If you were one of the men assigned to lug the boat halfway across the United States, I’m guessing that you were not so enthused over the boss’ pet project.  You can almost hear the muttering and cursing as 176 pounds of iron were loaded up each morning and carried all day, day after day, across the continent.

Finally, the time came to assemble the boat.  Lewis had envisioned covering the boat in animal skins, sealing any holes with pine tar.  There were just two problems: they didn’t have enough animal skins, and there were no trees in the spot where they were building the boat.

For almost three weeks, from June 21 to July 9, 1805, Lewis directed his men to hunt elk and skin them.  It took a lot of elk to cover a 42-foot boat.  Every day, instead of heading west in the perfect weather of early summer, the men stayed in one place, shooting and skinning elk.  Lewis supervised, trying to figure out how to seal the boat without any tar.  Again, imagine the griping, growing each day, as the skins piled up and the boat slowly took form.

Finally it was time to put the boat in the water.  Within minutes, it sank.  Years of planning, months of dragging it across the country, weeks wasted for the skins, and the whole thing was over in an hour.  Lewis was embarrassed, certainly, and his men were vindicated.  Can’t you see them all at the river’s edge, biting their tongues and rolling their eyes, afraid to look at each other for fear of laughing at the boss?  I’ll bet no one could even say “boat” for the next week, without a lot of snickering from the back of crowd.

What is your iron boat?  What idea has captivated you, in spite of what your people are trying to tell you?  What bit of technology are you totally enamored of, regardless of its utter uselessness in the real world?  What piece of your plan made complete sense two years ago, but is now on the verge of sinking because you just won’t let it go?

Every leader has an iron boat, strapped to the backs of his or her team.  None of us can see the boat, but our people certainly can.  Are you listening for their feedback?  Do you trust them when they complain about your boat?  Are you humble enough to see your boat and let it go?

(I’m on hiatus this Thanksgiving week. This is a repost of one of my favorite articles from 2008. For more on the spectacular trip of Lewis and Clark, look for Undaunted Courage on my Books page)

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

Fighting Fires November 18, 2009

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

Few phrases will sharpen the mind of an IT professional more than “we have an outage.”  Outages are to be avoided at all costs, the bane of our existence.  We all work diligently to build systems that will never fail.  We build in redundancy so that users will never know that a particular piece of equipment went off-line, or that someone kicked a cable out of the wall.  We are definitely a belt-and-suspenders crowd.

In a sense, that’s a shame.  Don’t misunderstand; I’m certainly not advocating more frequent outages as a way to spice up our day-to-day lives. But if you never have an outage, you’re missing a big opportunity: the chance to see your staff really shine.

Good IT people rise to the challenge of an outage.  Mindful of the impact, not wanting to disappoint customers, challenged by the technical problems, a good operations team will do amazing things to get their systems back up and running. It is a privilege just to watch them in action.

As much as your people make things look easy when all is going well, you are quickly reminded of how complicated their world really is when things run off the rails.  The many levels of abstraction coupled with the intricate details make it almost impossible for any one person to fully understand how all the pieces fit together.  A good team will play off one another, sharing information and supplying clues that collectively solve the problem.

How does this happen?  It certainly isn’t by chance.  Good operations teams develop a deep sense of ownership for the systems they tend.  It isn’t “a system;” it is “their system.”  Typically, they built it from the ground up, know every bit of software installed on it, and configured most of the settings themselves.  Like a mechanic and an automobile, a systems administrator forms bonds with their systems that will pay off when the chips are down.

To outsiders, this sounds a bit odd and even creepy.  But anyone who has been in operations understands this completely.  Each system is special and requires specific attention in unique ways.  You cannot typically step up and just take control, you have to know how and why each component was added and maintained.  Great operations people have this knowledge and use it to their advantage when needed.

Make sure you give IT people the chance to own their systems.  They need to be included in the design and development early on, integral to the decisions that drive the system design.  As the systems mature and develop, your people will acquire the knowledge that will really make them shine when things go wrong.  And may you never have a chance to see your people at their very best, when they are digging out from a disaster.

[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio133″ 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]