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.

 

Clinton, Machiavelli and the challenge of change

"It must be considered that there is nothing more difficult to carry out ... than to initiate a new order of things.  For the reformer has enemies in all those who profit by the old order, and only lukewarm defenders in all those who could profit by the new order, this lukewarmness arriving partly from fear of their adversaries ... and partly from the incredulity of mankind, who do not truly believe in anything new until they have had an actual experience of it."
                                                                     - Machiavelli writing in "The Prince"

A favorite quote of former President Clinton. 

 

The good kind of failure

“I have not failed. I have just found ten thousand ways that won’t work.”
                                                                                    - Thomas Edison

Resiliency and learning from your "mistakes" are critical to building a successful venture. 

Organizing your efforts to avoid "mistakes" and to have no risk of "failure" is a bad strategy.  Organizing your efforts to "fail faster" so that you can learn from your mistakes and course correct as you go is a good strategy.

It is important to distinguish between making new mistakes which are the good kind that you learn from; and simply repeating the same mistakes that have been made before and should now be avoidable.

                                                                               copyright 2007 Kerry Champion

You can't improve without change

Different Isn't Always Better, But Better's Always Different
                                                      -  Jonathan Schwartz

Out of the comfort zone

Wikipedia defines "comfort zone" as a set of "artificially created mental boundaries, within which an individual derives a sense of security."

It is natural for humans to build a comfort zone for themselves and in many situations this is an excellent life strategy.  When our Paleolithic ancestors were wrestling hyenas for the right to scavenge the best bits off the gazelle carcase, finding a secure niche and staying in it made a lot of sense.  So long as you are getting your basic needs met in the valley you are in, why move to the next valley over?

Unfortunately finding a comfort zone that meets our basic needs and staying there is not the best strategy for guiding a software team to deliver world-class performance.

Our paleolithic ancestors defined their comfort zones in terms of what geographic area they would search for food; and what animals they would fight vs. which they would fly from.

Software teams tend to define their comfort zone in terms of how they respond to change. 

• Will they limit themselves to incremental changes to existing product or will they create category defining new products? 
• Will they obsessively cling to keeping the current team as is, or will they reorganize the team and add new members as needed to address new challenges? 
• Will they be primarily motivated by risk-aversion or will they be primarily motivated by reward-seeking? 
• Will they train others and share responsibility for their code, or will they have a very proprietary attitude towards the code they wrote?
• etc. etc.

Often  these limitations are not driven by any rational analysis of risks and rewards, but rather is driven by specific previous bad experiences, a desire for control, and a general free-floating anxiety.

Given the natural human tendency to define a fairly constricted comfort zone, it is part of a leader's responsibility to know when and how to break down those boundaries.

Of course creating change for changes' sake or pushing people just to see them squirm is not productive.  Being a "loose canon" who has a new "priority of the week" is not how to guide a team to real success.

Instead your should carefully and consciously call your shots.  You should push people out of their comfort zone when doing so is directly tied to addressing organizational imperatives that are critical to your overall success.  And you should take the time to explain why there is a direct connection between these changes and those imperatives.

Even as you change what needs to be changed, you need to highlight to the team what is remaining stable.  Often people will fixate on the changes and risks, and lose sight of elements which are remaining stable and resources which will provide extra resiliency if things don't go exactly as planned.  Take the time to remind folks of these stable elements and resilient resources.

Let's talk through an example of when taking people out of their comfort zone was the right thing to do.  I was SVP of Development at a software company that had recently acquired another firm of about the same size.  We were just a few miles down the road from each other so we could combine offices.  Each of the predecessor companies had a stable software engineering team run by a VP of Engineering.  In both cases the teams liked and trusted their VPs and the VPs had intimate knowledge of the teams.

After the merger I had several goals including:

1. Maintain rapid progress in the development of both the original and the acquired product lines
2. Find opportunities to integrate the product lines
3. Form an objective assessment of the relative strengths of the two VPs, of the two teams, and of specific individuals on each team

Because of the first goal I did not want to just immediately tear apart both teams and form a new fully integrated team.  Also, until I had fully succeeded at the third goal I as not in a good position to ensure that such a drastic reorganization would be successful.

Therefore, what I did in the short-term was to maintain the teams as-is but to ask the two VPs to switch jobs.  This certainly pushed people out of their comfort zones, everyone involved was hesitant to see this change made and everyone needed to be talked into it.  Each team would have a brand-new top boss and each VP would have a wholly new team.

While people were uncomfortable with this change they accepted it because we could show how it made sense given the goals:

1. By just changing the two VPs, but not reorganizing the teams overall, we could maintain enough continuity to allow rapid progress on both the original and the acquired product lines
2. The switch of the two VPs forced them to rapidly learn the "new" team's product line and technologies which put us in a good position to assess what integration points made sense.
   
3. Also the switch of the two VPs put me in a much better position to get objective assessments of each sub-team and individual; as we now had two senior folks (the VPs) who could provide relevant analysis about everyone.  It also gave me a chance to assess the VPs themselves as I could see if switching them had much impact on the relative productivity of their teams.

The above is an example of a change that was highly useful to make and was directly driven by our imperative goals.  However, it was also a change that was non-obvious and was perceived as a "surprise".  This change was outside those "artificially created mental boundaries" that defined our current comfort zone, that is why it was a "surprise" and why we almost did not implement it.

                                                                                 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

Success Delusion

Marshall Goldsmith has an interesting article titled "The Success Delusion" in The Conference Board Review.  For those of you who (like me) are not subscribers, the New York Times has a summary here.

As historians like to point out Generals almost always start the current war be trying to re-fight the last one.  The tendency applies to the business world as well.  It is a bad idea to simply apply to your current situation what has worked for you before, without thinking through why it worked and what has changed.

Goldsmith was not focused on high-tech but lessons from Silicon Valley suggest that his central message applies to the software world as well.

Anytime you do a multi-year mission critical software project (in-house or startup) you will find that it breaks into distinct phases.  Phase definitions will vary, here is one example:

1. Conception and exploration
2. Proving viability of implementation and value proposition
3. Building pilot system and initial production use
4. Scaling up
5. Line extensions into neighboring spaces

What approach works in one phase that gets you to certain level of tangible success, may be exactly the wrong approach for the next phase. 

This is a hard lesson to internalize.  You will work hard for a year and finally break through by achieving a major goal, and then you need to immediately question everything about how you should move forward.  The talent mix, the practices, the attitudes that got you your current success may very well be the wrong ones to get you to the next dramatically higher level of success.

As Goldsmith puts it:

“Any human will tend to repeat behavior that is followed by positive reinforcement ... The more successful we become, the more positive reinforcement we get — and the more likely we are to experience the success delusion: I behave this way. I am successful. Therefore, I must be successful because I behave this way.”

... therefore I should continue to behave this way. 

There are two obvious fallacies here.  One that Goldsmith emphasizes is the fact that not all of your behaviors were directly relevant to your success and therefore you are attributing causation to a behavior-result when the behavior was really just noise.   

Another fallacy in this mindset is that it fails to recognize changes in the environment and circumstances.  This fallacy is the more critical one in the high-tech world.  High-profile software projects inherently have changing circumstances as they move from phase to phase,  they also almost always have very rapidly changing external environments.  The high-tech landscape is defined by constant motion.

In the high-tech world an archetypal example of phase to phase environmental changes is the difference between defining a break-through innovation vs. standardizing and scaling up that innovation.   Each of those steps requires a dramatically different approach to staffing, organizing, motivating, and measuring progress. 

Obviously there should be some critical continuities between the phases.  Key people, key goals, key philosophies that are constant throughout.  So while you should question everything you should not blindly throw out everything.  What is needed is to recognize that the normal tendency is to question too little rather than too much.  Then having recognized that and taken your blinders off, you must use the right judgment to make sure you strike the right balance.

It is human nature to believe that what worked last year will work next year.  People naturally want to build a stable environment: a comfort zone.  But when working on multi-year mission critical software projects that is almost always wrong.  With each significant success you need to question everything;  recognize those defining questions and critical success factors that matter the most in getting to the next phase; and where it is needed you must tear up what you have built and reconstruct it to meet the new challenge.

                                                                                       copyright 2007 Kerry Champion

The Replacement

Mission-critical software projects typically have:

• high expectations
• high stress
• multiple phases (spread over years) where each phase requires a significantly different mix of skills/behavior from the team and the manager
• a need to be very agile and to adapt quickly in the face of new information

If the team needs to evolve in response to the above characteristics, that typically can be done through various additions/subtractions while keeping a core group that provides continuity. 

If the manager needs to change, you sometimes can keep the previous manager in a new role, but often you end up replacing one manager with another.   What should you keep in mind if you are the replacement coming into this situation?

Business Week had a surprisingly relevant sidebar this week.  The nominal topic was how to replace a CEO, but it applies just as well for a VP of engineering coming into the latest Web 2.0 company, or a just assigned project manager trying to release a new service from eBay.

The four key points are quoted below.

"Be Your Own Person 
Don’t try to be someone you’re not. ... Also, introduce (or reintroduce) yourself to the company and let them know who you are and what you want to accomplish."

You should have a point of view, you should have a philosophy and you should have a history.  You don't want to lecture the team about any of those things, and you certainly don't want to talk more than you listen.  But anyone who spends time with you should get a clear sense of where you are coming from.

However, even more important than who you are is what you expect from the team and individuals.  You should have a clear set of expectations and you should communicate those every chance you get.  Initially your expectations may be rather general ("we will build a team that says what it will do, and then delivers it").  But as you learn more about the situation, and given everyone a chance to provide their input, those expectations should get much more specific ("our AJAX implementation will have large file upload performance that is 5x what it is now") and even more specific ("Tom, by the end of the month we need your component implemented to match the spec that you proposed to the team this morning").

"It’s Not About You
It’s about the company and the people who work there, the customers you serve, and the investors who are looking for an attractive return. Give credit to others for successes and use “we,” not “I”—except when shouldering blame."

While you should certainly have opinions and a point of view, you should not redefine the world based on your experiences and biases.  Those team practices that are working well should be left alone, even if they are different from how you worked in the past.  You should be adaptable and learn from the team.

In some professions (sales for example) a certain amount of "marking your territory" behavior is expected.  In engineering it is not respected at all.  Everyone has better things to do then deal with unnecessary changes that are only being made so the new boss can establish his authority or create a comfort zone for himself by making his new environment just like his old one.

"Establish Three Powerful Themes
Make them straightforward and use them consistently and relentlessly. The three themes (two seem incomplete, and people won’t remember four) need to be sufficiently specific to be meaningful, yet general enough to serve as organizing principles."

Beyond avoiding unnecessary (negative value) changes, I recommend you avoid immediately implementing a bunch of positive but low-payback changes.  You can always make those additional optimizations later on.  It works so much better to focus all your energy on a small number of high-payback changes instead of a large number of low-payback changes. 

Like a newly elected politician a new manager has a certain amount of goodwill and capital to spend.  I strongly recommend you use that honeymoon period when everyone is listening closely to what you have to say, to define and implemented a very focused agenda.  Pick those three key themes that may involve big changes (but have big-payoffs) and push on those.  After showing some success (and building some team confidence) with those, you can push on to other issues and themes.

"Never Speak Ill of Your Predecessor"

Even if the team hated the guy, it will earn you no credit to belittle him.  Most people won't respect that approach.  And the folks who do want to sit around and bitch about the previous guy are folks that you certainly don't want to encourage and may want to subtract from the team.

Of course you may need to raise concerns and even completely reverse certain practices and decisions.  In each of these cases you will be fine if you focus on the issue (advantages/disadvantages, fit with current direction) and avoid attacking the person who made the original decision.

Failing to implement the four ideas above is usually a sign of being too reactive and emotional.  When you don't have a plan but simply parachute in and react, it is natural to:

• get pulled into a million little firefights
  instead of having some big themes
• to bitch about your predecessor
  instead of staying focused on the way forward
• to try and build a comfort zone for yourself by recreating your previous environment
  remember it is not all about you, marking your territory by making things work your way does not help.  It is implementing changes that have a direct connection to your themes that helps
• to not make it clear what your expectations are
  because it is not clear in your own mind

It is tough being the replacement.  However, there is no question that you can make it easier on yourself and your team.  The four rules of thumb in the Business Week article are good rules to live by, but you could probably invent another set of guidelines that are equally good.  What is important is that you:

• listen
• build a plan
• communicate the plan
• don't fall into the reactive trap

If you do that you will do fine.

P.S.
Business Week used James Citrin of Spencer Stuart as the source for their article.  More detail on his thoughts can be found here and here.

P.P.S
If you have never listened to The Replacements version of Red Red Wine, you might want to give it a try, it is unique ;-)

                                                                                       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

Addition Through Subtraction

Every gardener knows that thinning and pruning is just as important as planting and growing.

The same is true in software. Sometimes the best way to add to your results is to subtract some negative elements.

When faced with some problem the natural thing to do is to increment on a new element: a new hire, or a new process, or a new project.  It is typically  easier to stay in everyone's comfort zone by adding rather than subtracting.  But putting some short term stress into the system is often the right path to get a better long term result.

Consider this scenario:

• Dozen person team working on company critical software project:  Software Architect, VP Engineering, and ten engineers
• Have first generation product that clearly does not provide functionality/performance required for company to succeed.  Now need to architect and code second generation product.
• Architect is really really smart guy who has very quickly implemented very difficult coding assignments both at this company and previous company.
• Engineers other than Architect have the normal mix of skills including both "competent but will never be a star" and "really skilled, could be a star with right support and opportunity".
• Architect is adamant that fundamental design changes are required to deliver second-generation.
• Architect has non-traditional design approach that worked at a previous company and he wants to try again here.  Architect is serenely confident that this approach will achieve all goals and be implemented very quickly.
• Management feels intense pressure to get competitive product to market and is pushing hard to get team going on "coding"
• PROBLEM 1: Even after several weeks of work on the detailed module design and initial coding, it is clear that the Engineers do not fully understand the design being advocated by the Architect. 
• PROBLEM 2: Beyond the specific issues of rolling out this particular design, it is clear that Architect is weak communicator in general and has trouble working with people who "are not as smart he is".

Those are some serious problems and the project and company are on a clear path to failure.  Lets consider some potential solutions.

Problematic solutions via addition:

• Add Person
  
  • Hire another layer of management by hiring an Engineering Manager.  Have this guy modulate and manage the communication between the architect and the rest of the team.
  • Makes you feel good that you are doing something
  • Since it will take a long while to hire the person and for that person to learn the score, it puts off the real day of reckoning
  • Inefficient in terms of resources, adds expense and bureaucracy that is not needed yet.
  • Will mask the issue for awhile but will almost certainly fail to address the fundamental issues.
  • There will be some unintended consequences (better known as blowback) as the new manager will certainly start doing more stuff (beyond managing architect to team communication) to justify his existence.
• Add Process
  • Create a new set of processes that force the required communications and design reviews
  • Similar issues to above.  Masks problem for awhile but does not really solve it.  Also unneeded processes create general slow-down and lethargy.
• Add Project
  • Create an isolated greenfield project that will build the second generation product.  Put the architect and 1 or 2 simpatico engineers on that.  Leave the rest on maintenance of the first generation product.
  • If 2 or 3 people is the right number to have on this project for its whole life cycle then this solution may be a good one.
  • However, if 2 or 3 is just enough to get started and you really will need a dozen to finish the project, then you have put off dealing with the problem, created an us-them dynamic on the team, and have 75% of your team underutilized while the problem festers.

None of the above sound very appealing the way I stated them.  However, I have seen similar solutions implemented in the real world, they were just wrapped up with a nicer sounding rational.  In the scenario we gave the fundamental issues are really painful and uncomfortable to deal with.  In which case it is very natural for folks to talking themselves into a "solution" that does not address the real issue.

Promising solutions via subtraction:

• Subtract person
  • Move architect to a supporting position. 
  • Accept the fact that he is very likely to leave us a result.  But get what value you can out of him before he goes. 
  • Preferably develop 1 or 2 of the existing engineers to take architecture responsibilities.  If that is not possible, fundamentally re-set the schedule and look outside for help.
• Subtract process
  • In this scenario there is not a good opportunity to solve the problem via removing process.  However, surprisingly often this is an option.  Processes tend to accrete over time like plaque in your arteries.  You should always look for opportunities to simplify.
• Subtract project
  • Test your premises about the fundamental nature of the project.  If possible avoid adding a new project and evolve the existing effort instead.
  • Do you really need a brand new project and fundamentally new design to achieve your goals?
  • Can you achieve your goals by killing that "rebuild it all" project and defining an incremental approach (that relies less on your architect's  communication skills and non-traditional design)?

Obviously the best solution will depend on the specific circumstances of the project and sometimes the right solution is via addition.  However, there is a consistent inherent bias to not consider solutions via subtraction.  We need to push ourselves and our teams out of our comfort zones and seriously consider those solutions.

                                                                                       copyright 2007 Kerry Champion