A Simple Matter of Software

Need for nimbleness

The interesting thing about the Microsoft-Yahoo merger to me is not that two companies that lost out to Google now are combining, but rather why they lost to Google in the first place.

 

Here is one common thread in the commentary:

"Yahoo management has not been nimble, Microsoft has not been nimble, Google has a management team that is nimble and dynamic."  - SF Chronicle

Over the past few years, "Yahoo became less nimble ... " -  Diab

"I'd add that since Google is a faster growing, more nimble company than Microsoft or Yahoo ... " - Techsmart

"Word has it that Yahoo's once nimble and entrepreneurial culture has turned sluggish and bureaucratic. The company's organizational structure and compensation system appears to be rewarding silo behavior that inhibits change."  - Steve Tobak

"... what some see as an inability to respond to more nimble (though considerably larger) Google" - CNET

Falling back into a "comfort zone" and building mechanisms (bureaucratic or otherwise) that "ensure stability", is a typical human response to success.  In its time Yahoo had plenty of success and slowed their rate of change as a result. 

For a Internet service business where the "network effect" applies and there are "very low switching costs" for the end user.  It is critical that you respond to success by staying nimble and accelerating your rate of progress.  Otherwise someone else will see what you have achieved so far and take the initiative to eat your lunch.

 

Don't leave the trail and fling off your clothes

Software ventures are by definition high-risk operations that will often experience set-backs and failures.  How you react will determine whether you enter a death spiral or power past failure to find real success.

I was reminded of this while reading Bill Bryson's "A Walk in the Woods", in particular his description of hikers struggling with hypothermia had a real resonance.  In his examples the death spiral involved actual not figurative deaths.

Popular impressions to the contrary, relatively few victims of hypothermia die in extreme conditions, stumbling through blizzards or fighting the bite of arctic winds ... [most] die in a much more dopey kind of way, in temperate seasons and with the air temperature nowhere near freezing.  Typically they are caught be an unforeseen change of conditions [for which they are unprepared] ... Nearly always, they compound the problem by doing something foolhardy - leaving a well-marked path in search of a shortcut ... fording streams that get them only wetter and colder.

Hypothermia is a gradual and insidious sort of trauma.  It overtakes you literally by degrees as  ... your natural responses grow sluggish and disordered ... [It leads to] desperate and irrational decisions ...

A person suffering hypothermia experiences several progressive stages ... profound weariness, heaviness of movement, a distorted sense of time and distance, and increasingly helpless confusion resulting in a tendency to make imprudent or illogical decisions and a failure to observe the obvious.  Gradually the sufferer grows thoroughly disoriented and subject to ... decidedly cruel misconceptions .. Many victims tear off clothing, fling away their gloves, or crawl out of their sleeping bags. 

Software ventures that experience some serious difficulty can fall into a similar pattern:

• Conditions prove to be different than you had assumed.  The scope of the problem is bigger, or the number of competitors is greater, or the receptiveness of the market is slower than you had hoped.
• You could use this information to make a one-time fundamental revision to your methods and goals.  However, you are so latched on to your current assumptions and commitments, that you can't bring yourself to make an fresh objective evaluation.
• You refuse to recognize that there is any fundamental barrier to achieving your existing plan.  You steadily warp how you define and report your metrics to support this position.  You develop  "a distorted sense of time and distance" and "a failure to observe the obvious".
• You assume that if everyone just works harder than anything is possible.  Ignoring how the resulting "profound weariness" effects everyone's judgment and perspective.
• Often that hard work is spent pushing down the wrong path.  You don't recognize that superhuman effort is no replacement for good judgment and correct direction.
• As "your natural responses grow sluggish and disordered" you make increasingly "desperate and irrational decisions".
• Finally your "misconceptions" lead to making "foolhardy" decisions and attempting muddleheaded "shortcuts" that actually take you further from your fundamental goal.  In effect you leave the trail and fling off your clothes.

The best way to handle changing conditions is an approach of:

1. proactively prepare for potential potholes
2. clear-headed measurement of current progress
3. decisive corrective action when needed

However, you don't want environmental changes to be used as an excuse to cover poor performance or a lack of commitment to deliver results.  Part of your role as a leader is to make sure that changes to a committed plan honestly are optimizations in the face of new information and not cover ups for sloppy work.

                                                                                 copyright 2007 Kerry Champion

Groupthink and Software Design

"Groupthink may cause groups to make hasty, irrational decisions, where individual doubts are set aside, for fear of upsetting the group'€™s balance. The term is usually used as a derogatory term after the results of a bad decision."   - Wikipedia

Irving Janis created the original definition of groupthink.

More than once I've seen a team working extremely hard on a year long effort to implement a software design, where the software design was fundamentally flawed, with no one on the team actively questioning the assumptions in the design.  I believe that groupthink is often a root cause of this type of failure.

Here are common behaviors I have observed that lead into the groupthink trap:

1. Individuals high in the hierarchy (formal or informal) express an opinion when the task is first assigned to a group.  This creates a prepackaged answer before you even start. 
2. Rationalization is tolerated in the culture.  Team members assume that it's invariant human nature, and don't bother correcting it when they see it.
3. Don't consult with trusted experts from outside of the group.  Avoid technical and customer advisory boards.
4. Never request that knowledgeable insiders act as "devil's advocate"
5. The common attitude is "we don't have time to think about it lets just do it."
6. There is no distinction made between critical defining decisions and trivial decisions, both are given the same level of scrutiny.  This leads to minimal scrutiny for all decisions.
7. Fall in love with your own ideas.  Don't bother building into the culture a distrust of NIH.
8. Don't bother keeping a lookout for "early latching."  When searching for an answer humans tend to latch on to the first reasonable answer (using a low barrier of acceptance) and then use a much higher standard when considering other possible answers in comparison to this initial answer.  Don't bother looking for this pattern.
9. Focus your energy driving local optimization based on unquestioned assumptions.

Sloppy professional habits and a normal desire for group harmony are common drivers of these behaviors.  However another common driver in software ventures is the natural desire to deliver quicker and deliver more. 

Delivering the wrong thing fast isn't what creates a success.  Having a team that lives in perfect harmony in their comfort zone isn't what creates a success.  Success comes from building a culture that rejects both groupthink and analysis paralysis.  


                                                                                copyright 2007 Kerry Champion

 

Cover-up and crime

In Washington there's a bit of conventional wisdom that says "it's the cover-up and not the crime that causes the most damage."  If our Attorney General is forced to resign he will be the most recent example of this maxim.  It was not firing a couple US Attorneys that caused the most controversy it was the subsequent misleading of Congress that really got him into hot water.  Watergate and the Clinton impeachment were other examples of this pattern in action.

The same rule applies when managing a software venture.  Everyone makes mistakes and  encounters setbacks.  The trick is to acknowledge those errors, take responsibility for them and learn from them.  Having done that you can move on. 

What really causes long-term damage is when you try to convince yourself and others that there was no error.  In this case there is no basis to justify needed corrective action.  There is no lesson learned to avoid similar mistakes in the future.  And as the eventual results of the original error become visible your credibility is steadily undermined.

                                                                                 copyright 2007 Kerry Champion

Ask For More

Most folks respond well to the "explain why it matters" approach or have some other fundamtental motivation that you can discover and call out to. 

However that is not true for everyone.  For a minority of folks you need to look them in the eye and  tell them to work harder and deliver more  You  will need to do that in the most direct  and unambiguous way possible.  Depending on the person you may need to get in a rhythm of delivering that message on a regular basis.

This approach should be reserved for that minority that doesn't respond to normal calls to action.  Sending out a broadcast message to everyone "that we all have to work harder" and "I want to see more cars in the parking lot at 9:00 PM every night" is often counter-productive.  The people who are already working at 150% are insulted or dispirited that you are telling them to do more.  People who work in the office 8 hours a day and work from home another 4 hours are annoyed that you don't value what they do, because their "car is not in the parking lot".  And almost everyone wonders why the first order focus is on activity not results.

So simply asking for more activity does not work as a general message to the whole team.  However, there is always at least one individual on a team, that needs the message "work harder, do more" delivered to them personally, and you should not hesitate to do so.

By the way, if you don't deliver this message and you allow this person to bump along unchecked at a low level of productivity, it will cost you more than that one salary, it can be a source of dissatisfaction for the team as a whole.  No one likes to be working hard while others are not making an effort.  His co-workers will be happy that you ask him to carry his share of the load.

You might think that repeatedly having to tell someone to do their job is a sign they need to be fired.  In some cases that is true, but not always.  If you are happy with their level of productivity after this prompting and the time required to deliver the messages is not out of line (say a 15 minute conversation every few days) than this just might be one of those quirks that you learn to live with.  Of course if  either of those conditions (ultimate productivity and time required to manage them) does not reach a reasonable level then you should get rid of the person.

It is natural for people to tend to settle back into their comfort zone, part of your job as a leader is to draw them out of that comfort zone.

                                                                                 copyright 2007 Kerry Champion

Rationalizing Creatures

Good post by Justine Davies titled Talk To Me In Numbers on data driven management.  One comment that struck me was "A person can provide any number of reasons, incredibly well argued, as to why their sales performance is off."  It is true people are rationalizing creatures by their nature. 

Here is an interesting paper that touches on the neuroscience behind why we take so naturally to rationalization.

"many times we give 'rational' explanations to our "irrational behaviors', even knowing that we are betraying ourselves"

"In a well-known experiment, a group of women have to chose some nylon tights.  Once they were asked about their elections, they gave detailed, careful, and sensible explanations related to the differences in color, texture, or the quality of the material, without taking into account that the tights were identical.  The reasons for choosing them in fact were rationalized explanations built to explain an emotional behavior, that has no rational explanation"

The paper discuss that this tendency to rationalize may be driven by the division of labor between the two hemispheres of the brain.  The logical half of the brain gets in the habit of unconsciously building verbal explanations to explain the impulsive, reactive, emotional behavior of the other half.  That sounds plausible to me.  But as a practical matter how to effectively deal with this behavior is more important than the biological basis for it.

My experience is that from day-one you need to build a culture and set of practices that is data-driven and that is prepared to deal with harsh truths when the become apparent. 

Justin's post seemed aimed more at sales results, but of course this tendency to rationalize away what you are seeing comes up in other customer interactions as well, and gets in the way of really hearing the customer.

                                                                                 copyright 2007 Kerry Champion

What you want to see and what you need to see.

Scott Maxwell does an excellent job explaining the 10 best ways to lie with metrics.

Seth Godin recently posted on the disconnect between common metrics and what really matters.

Our previous post on how market definitions can be used to reaffirm existing biases is getting to a similar point.

Behind these cautionary tales the real issue is selectively using data to reinforce what you want to see.  Instead of using data to discover what you need to see.

Sometimes what you want to see is a specific conclusion, such as "yes it makes sense to inject another $10m into our current product focus, no changes needed there".

Sometimes what you want to see is a high degree of action and precision regardless of the conclusion:  "Look at all the metrics, look at the precise numbers, this is one organization that is really on top of things ... well no, we are not sure yet what action plan makes sense given these numbers ...".

In both cases you are missing the real goal: having a open minded data-driven process that sometimes leads you to surprising conclusions, but always leads you to decisive action.

                                                                                 copyright 2007 Kerry Champion

Not Seeing The Gorilla - User Requirements (part 1)

You might think that entrepreneurial software ventures are pretty much guaranteed to do a good job of listening to the customer.

You would be wrong.

Whether they are in a start-up or doing an innovative new project within a big company, folks working on software ventures are just as prone as anyone else to:

• Fall in love with their own ideas
  Something that welled up from the mists of their frontal lobe, is always more appealing than an idea that was tediously sifted from lots of conservations with strangers
   
  
• Fall in love with the early ideas
  When searching for an answer humans tend to latch on to the first reasonable answer (using a low barrier of acceptance) and then use a much higher standard when considering other possible answers in comparison to this initial answer.  Fondly known as "early latching syndrome", this may be a good thing in breast feeding, but not such a good thing in problem solving.
     
• See themselves as experts and users as uninformed.
  Folks in a software venture are way smarter than average and spend 100% of their time thinking about the issues around their target offering.  Users are average smarts and typically spend a tiny fraction of their attention around the issues associated with this offering. It is easy to assume the developer is right and the user is wrong.
     
• Assume that bad solutions mean an irrelevant problem
  What really matters is the users' (not the developers) definition of what is the real problem and what trade-offs are worth making.  However, users often (not always but often) are bad at proposing specific solutions (functionality, UI, architecture, etc.) to address those problems and implement those trade-offs.   Unfortunately once a developer hears a bad solution suggestion they often stop listening and don't bother to dig for the underlying problem the user is trying to address.  Finding the problem the developer might suggest an alternative solution that the user would love.
     
• Act as rationalizing machines
  What distinguishes humans from animals is not speech or tools, but our extraordinary ability to rationalize.  We are amazingly good at providing a rationale sounding analysis of a given set of observations, an analysis that just happens to support our pre-existing biases and assumptions.
     
• Suffer from situational blindness
  When stressed and really focused on a particular goal we can be blind to obvious facts present in front of us.  There is an fascinating experiment with two basketball teams and a gorilla, that illustrates this.  More relevantly I am sure we have all seen a more subtle form of this in software projects as well.
  

All of this gets in the way of really hearing the key messages from the prospective users.

I suspect we have all seen software ventures that have:

• Made it more complex than the customer wants and undervalued the power of simplicity
• Failed to tie technical innovations to customer valued differentiations
• Targeted the wrong customer for their offering
• Made bad assumptions on the rate of adoption
• Spent time and money on development efforts that were irrelevant to the user
• Suffered from NIH syndrome, when user preferences would have driven them to leverage existing technologies

All of these issues (and more) can be alleviated through a real commitment to understanding the user and finding the key messages.

Most of the time I believe the needed data is readily available through some basic legwork.  The real issue is overcoming our biases and wishful thinking. 

As in the situational blindness experiment, that gorilla is right there in front of us.  We just have to break out of our stress induced tunnel vision and apply the needed judgment and perspective.  Then we will see it.

Later posts will further explore how to capture user requirements.

Previous posts talked about when not to listen to the customer (here and here), how to deal with an unpleasant truth when you discover it, and the dangers of doing the right things (such as careful user analysis) to solve the wrong problem.

 

                                                                                 copyright 2007 Kerry Champion

Embracing Harsh Truths, Rejecting Rattlesnake Rattles

Google "harsh truth" you get 148,000 hits.

Read a few of these references and a couple things become clear about the "harsh truth": first it is virtuous and good for you; second it is painful and it is the most natural thing in the world to want to avoid it.  Sounds like a trip to the dentist.

Lets consider some examples of things that might be harsh truths.  There are many times when you are managing a software project that you will hesitate to say something that is on the tip of your tongue:

• You about to tell the VP of Marketing that the product will not be ready for the planned launch, but you hesitate.
• You are about to tell an engineer that he is not pulling his weight, but you hesitate
• You are about to tell the CEO that his vision and our reality are currently living in different time zones and we need to do some work to get them back together, but you hesitate
• You are about to tell the candidate that he has no chance to succeed at the job he is applying for, but you hesitate
• Etc. etc.

There are a lot of reasons you may hesitate to share these thoughts:

1. You are not sure yet that it is true, you need more evidence to support your tentative conclusion
2. You are sure it is true but you don't want to get sucked into that conversation until you are prepared with the "whole story".  For example, you may want to have some proposed alternative actions ready to go before raising a big red flag over the current plan.
3. You are sure it is true, but you want to break the news to the right people in the right order, and the person standing in front of you that instant is not the right one to hear the news first.
4. You are pretty sure it is true, but it is just too upsetting.  Too many plans and expectations already depend on it not being true.  Or some individual will be insulted or wounded by what you have to say.
5. The possibility of this being true is just unacceptable, so it is not even worth considering.  (This is often a sub-case of 4, but at the time it is hard to see it that way.)
   

In cases 1-3 biting your tongue and taking the immediate appropriate actions is the right thing to do.

In cases 4 and 5 you need to seriously consider that there is a harsh truth right in front of you and that instead of avoiding it you need to face it and talk about it with the broader team.

By embracing that harsh truth you can make a real-world plan instead of wish-based plan; while giving people a realistic basis for evaluating their past work and what work they need to do.  You will cause some short-term pain.  However, in the long run you will improve everyone's morale and productivity by forming a mature organization that manages based on honest measurement and a real commitment to results.

A caution here though.  Sometimes, even well meaning individuals will use the "truth" as a weapon and as a stress transference device. 

Rattlesnakes are great at stress transference.  When they feel stressed out they shake their rattle, make a big nose and transfer that stress to everyone around them.   Anyone who often hikes California hillsides can attest to this being a real attention getter that drives everything else out of your mind.  You need to recognize rattlesnake rattles in your meeting room as well as on hillsides.

It is common for even very well run mission critical software projects to cause stress.  When that happens a natural thing to do is to drop a bombshell, which may not be true but sounds plausible.  The urge to do this is usually sub-conscious and instinctive and not part of some nefarious plan. 

For example, if you are stressed out because you are not going to deliver your sub-component on time, and you are in a status meeting where you have to make your report, you might be tempted to blurt out "hey we have a fundamental architecture problem XXX that means we will never succeed because of YYY".  This feels good in the short run, you have moved your stress around to others and in addition you have taken the spotlight off your personal issue.  It may be that your bombshell isn't really true (though it may have a kernel of truth) but it will take weeks of running around to fully confirm that.

Just because something sounds like a "harsh truth" does not mean you should immediately embrace it.  You need to look hard and see if it is just a rattle that is distracting the team from pushing forward to the goal.  In that case, you need to quickly push back and set the record straight.  Part of your job is to triage which issues deserve the teams time and attention, you can't spend equal time on all of them.  If you think something is a distraction that does not warrant a real analysis, stand up and say so.  Analysis-paralysis is one of the ways to kill a project.

A second caution concerns responding to a harsh truth.  You need to pull the team together to attack the problem and not be stymied by finger-pointing.  At the same time you need to make sure that the right lessons are learned by everyone (not just you in your private thoughts) and that those lessons feed back into your continuous improvement process.  Also you need to make sure that responsibility for this issue does not just diffuse into the ether.  You may want to pick a private forum to do it, but if someone screwed up you need to talk to them about it and make sure they recognize their personal responsibility.  Obviously that needs to be done in a way that is positive and forward looking but it needs to done.

Being able to:

• separate stress rattles from real truths
• get the whole team to understand that truth and take positive action in response
• make sure the lessons from those truths get learned, and the responsibility for any errors is acknowledged

can make your team happier and more productive.  It will help them feel like grown-ups who control their own destinies, instead of kids who consistently fail to recognize the real issues till it is too late.

                                                                                       copyright 2007 Kerry Champion