A Simple Matter of Software

Changing Behavior - Focus on what you want not what you don't want

Slate has a good article on changing people's behavior.  This article is about children's behavior but most of the ideas apply just as well to a 40 year old as a 4 year old.

You begin by deciding what you want the [person] to do, the positive opposite of whatever behavior you want to stop. The best way to get rid of unwanted behavior is to train a desirable one to replace it. ...

Then you tell the [person] exactly what you would like him to do. ...

Whenever you see ... what you would like, or even something that's a step in the right direction, you not only pay attention to that behavior, but you praise it in specific terms ...

If you don't see enough of the desirable behavior, then you can work on it using simulation ... Your objective is to arrange for as much reinforced practice as possible, ...  A brief but intensive period featuring lots of reinforced practice, often somewhere between a couple of weeks and a month, can make long-lasting or even permanent changes in ... behavior.

Going ballistic never helps, but explanation aimed at improving ... understanding can actually play a useful part in this approach. When combined with reinforced practice, explanation has been proven to speed up the acquisition of behavior.

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.

 

Setbacks and Success

“Success is not final, failure is not fatal,
it is the courage to continue that counts.”
                                      - Winston Churchill

There are some typical software venture dysfunctions that come from assuming that success is final and failure is fatal. 

The success delusion tempts you into sticking with what worked last year instead of focusing on what needs to change to succeed this year.  In the famous words of Andy Grove "only the paranoid survive" and success unfortunately drives out paranoia.

Failure tempts you into abandoning a direction that could succeed with an appropriate and active course correction.

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. 

 

You can't improve without change

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

Surveillance and diligence

As I mentioned in a previous post I recently heard Atul Gawande talk about his book "BETTER: A Surgeon’s Notes on Performance".  He made observations about why some teams have much better results (in terms of patient medical outcomes) than others.

He highlighted two traits that seemed to be central to that success: "surveillance" and "diligence".  These traits are incredibly important in the software world as well, for much the same reasons as touched on by Atul.

I am not sure that "surveillance" is the best possible phrase to use, I prefer to think in terms of "active observation."  Whatever the label the concept is critical.  Here are some points to keep in mind when practicing active observation:

• Don't depend solely on your own observations, enlist the broader team to take part in the process and listen carefully when they share what they are seeing.
   
• Don't accept everything you hear at face value, question and probe, search for validating or contradictory data points.
   
• Make sure you have a good consistent data set that lets you make comparisons over time and comparisons between different people and different projects.  When there is variation in that data set probe into it, even if the variation seems small.
   
• Take advantage of your insights into well known patterns of misleading reports.  Some folks are modest and pessimistic and consistently make things sound worse than they are.  Others may tend towards self-justification.  In any case you need to look for these patterns and take them into account as you get new reports from the same source.
   
• As you form conclusions based on these observations, test that conclusion, make predictions based on that conclusion and go look at the relevant data.  If your new data points don't support your prediction, than your conclusions are probably wrong.

Atul makes some key points regarding "diligence":

• Diligence can be defined as "the constant and earnest effort to accomplish what is undertaken."
   
• "People underestimate the importance of diligence as a virtue" perhaps because on the surface it sounds mundane and simplistic.
     
• However, diligence is a "prerequisite of great accomplishment" and "one of the most difficult challenges facing any group of people who take on tasks of risk and consequence"

I agree wholeheartedly with these points and would add just a couple more regarding the practice of diligence. 

• It is unreasonable to expect diligence from someone who does not understand why their tasks matter in the bigger scheme of things.
     
• Having relevant and easy to understand metrics that are shared with the entire team, encourages diligence and continuous improvement.
     
• Developing team practices that enable folks to get into a good rhythm and spend most of their time "in the zone" is critical to encouraging diligence.  There are lots of things (too many meetings, unproductive meetings, inconsistent goals/feedback, constantly switching assignments, etc.) that will pull folks out of the productive zone and discourage them from trying.
   
• An out-of-context or irrelevant response to anxiety or social tension is called a displacement behavior.   I believe this term was originally from animal behavior studies, but it certainly applies to humans as well.  For example you may feel anxious about a deadline, doing the relevant work just reminds you of how hard it will be to make the deadline, which makes you even more anxious, so you find yourself reading Slashdot or reorganizing the source tree instead of actually working on the relevant implementation.  Team leaders need to give folks an open door and when they express anxiety or point out tension, leaders need to help them work-around those issues so they can pursue the tasks that matter instead of getting sucked into an eddy.   

Here is Atul's description of a Doctor who has mastered the arts of surveillance and diligence.  This describes an examination of a Cystic Fibrosis patient (Janelle) by her Doctor (Warwick).  Even though the specifics of this situation are far from the specifics of a software project, the mindset and basic skills shown here are extremely relevant.

Warwick pulled out her latest lung-function measurements. There’d been a slight dip, ... Three months earlier, Janelle had been at a hundred and nine per cent (she was actually doing better than normal); now she was at around ninety per cent. Ninety per cent was still pretty good, and some ups and downs in the numbers are to be expected. But this was not the way Warwick saw the results.

He knitted his eyebrows. “Why did they go down?” he asked.

Janelle shrugged.

Any cough lately? No. Colds? No. Fevers? No. Was she sure she’d been taking her treatments regularly? Yes, of course. Every day? Yes. Did she ever miss treatments? Sure. Everyone does once in a while. How often is once in a while?

Then, slowly, Warwick got a different story out of her: in the past few months, it turned out, she’d barely been taking her treatments at all.

He pressed on. “Why aren’t you taking your treatments?” He appeared neither surprised nor angry. He seemed genuinely curious, as if he’d never run across this interesting situation before.

“I don’t know.”

He kept pushing. “What keeps you from doing your treatments?”

“I don’t know.”

“Up here”—he pointed at his own head—“what’s going on?”

“I don’t know,” she said.

He paused for a moment. And then he began speaking to me, taking a new tack. “The thing about patients with CF is that they’re good scientists,” he said. “They always experiment. We have to help them interpret what they experience as they experiment. So they stop doing their treatments. And what happens? They don’t get sick. Therefore, they conclude, Dr. Warwick is nuts.”

“Let’s look at the numbers,” he said to me, ignoring Janelle. He went to a little blackboard he had on the wall. It appeared to be well used. “A person’s daily risk of getting a bad lung illness with CF is 0.5 per cent.” He wrote the number down. Janelle rolled her eyes. She began tapping her foot. “The daily risk of getting a bad lung illness with CF plus treatment is 0.05 per cent,” he went on, and he wrote that number down. “So when you experiment you’re looking at the difference between a 99.95-per-cent chance of staying well and a 99.5-per-cent chance of staying well. Seems hardly any difference, right? On any given day, you have basically a one-hundred-per-cent chance of being well. But”—he paused and took a step toward me—“it is a big difference.” He chalked out the calculations. “Sum it up over a year, and it is the difference between an eighty-three-per-cent chance of making it through 2004 without getting sick and only a sixteen-per-cent chance.”

He turned to Janelle. “How do you stay well all your life? How do you become a geriatric patient?” he asked her. Her foot finally stopped tapping. “I can’t promise you anything. I can only tell you the odds.”

In this short speech was the core of Warwick’s world view. He believed that excellence came from seeing, on a daily basis, the difference between being 99.5-per-cent successful and being 99.95-per-cent successful. Many activities are like that, of course: catching fly balls, manufacturing microchips, delivering overnight packages. Medicine’s only distinction is that lives are lost in those slim margins.

And so he went to work on finding that margin for Janelle. Eventually, he figured out that she had a new boyfriend. She had a new job, too, and was working nights. The boyfriend had his own apartment, and she was either there or at a friend’s house most of the time, so she rarely made it home to take her treatments. At school, new rules required her to go to the school nurse for each dose of medicine during the day. So she skipped going. “It’s such a pain,” she said. He learned that there were some medicines she took and some she didn’t. One she took because it was the only thing that she felt actually made a difference. She took her vitamins, too. (“Why your vitamins?” “Because they’re cool.”) The rest she ignored.

Warwick proposed a deal. Janelle would go home for a breathing treatment every day after school, and get her best friend to hold her to it. She’d also keep key medications in her bag or her pocket at school and take them on her own. (“The nurse won’t let me.” “Don’t tell her,” he said, and deftly turned taking care of herself into an act of rebellion.) So far, Janelle was O.K. with this. But there was one other thing, he said: she’d have to come to the hospital for a few days of therapy to recover the lost ground. She stared at him.

“Today?”

“Yes, today.”

“How about tomorrow?”

“We’ve failed, Janelle,” he said. “It’s important to acknowledge when we’ve failed.”

With that, she began to cry.

Warwick’s combination of focus, aggressiveness, and inventiveness is what makes him extraordinary. He thinks hard about his patients, he pushes them, and he does not hesitate to improvise.

I particularly appreciate the comment "... combination of focus, aggressiveness, and inventiveness is what makes him extraordinary"  That certainly applies to the software world as well.

                                                                               copyright 2007 Kerry Champion

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

Understanding the 'Why' of Decisions

Good article in Wall Street Journal (subscription required) today on "How Understanding the 'Why' of Decisions Matters"

[tell] workers not only what was decided, but why and how ... sounds like common sense but is easy to neglect in practice ... Executives may feel too busy to explain their thinking.  They may be so wrapped up in their decision making that they think their own conclusions are obvious  ... If management doesn't offer explanations, 'people will work together to develop their own reasons' ..."

The article used examples from cheese factories, however the lesson is even more applicible to the knowledge workers who build software and internet services.

This earlier post talks about the execution of this practice in software ventures and touches on the parallels with Ellen Langer's famous experiment.

                                                                                 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

Explain why it matters

Telling someone to perform a task may get results.  However, taking the time to "explain why it matters" almost always gets you better results, no matter who you are talking to or what you are asking for. 

For most people the following approach works great:

• Explain why the work they are doing is important.
• Explain why the timeliness of their work is important
• Don't just assert that it is important, but make the effort to show step-by-step what the connections are between their work and the ultimate impacts.
• Certainly talk about the impacts on the company's bottom-line; but then go beyond that and talk about what the impacts are on the customers' experience, what the impacts are on co-workers who are depending on this person's efforts, etc. etc.
• Don't deliver these messages just once, deliver them multiple times through multiple mechanisms: via team meetings, via one-on-one meetings, via hallway conversations, via guest speakers, etc. etc.

This results in :

• a higher level of energy and effort
• more pride and satisfaction in their work
• quicker delivery of higher quality results
• a better vibe around the team

It may seem easier to just tell people specifically what to do day-to-day without wasting time on why, in reality that kind of micromanagement can be very time-consuming and ultimately demoralizing.  It is much better to help people connect the dots between what they do and the impacts on everyone else in the ecosystem.  This leads to greater self-direction, more initiative, and better total throughput.

By the way, "explaining why it matters" is not just the right approach for full time staff members, it is also the right approach when dealing with vendors, independent contractors, temporary staff, etc.  Even if they do not have a direct tangible stake in the company, people will make a greater effort if they understand the rationale behind why their work is important.

All the above is based on real-world observation.   There is some scientific work in this area as well.   Ellen Langer did an experiment that triggered a lot of debate.   Malcolm Gladwell has a good summary:

Langer examined the apparently common-sense idea that if you are trying to persuade someone to do something for you, you are always better off if you provide a reason. She went up to a group of people waiting in line to use a library copying machine and said, "Excuse me, I have five pages. May I use the Xerox machine?" Sixty per cent said yes. Then she repeated the experiment on another group, except that she changed her request to "Excuse me, I have five pages. May I use the Xerox machine, because I'm in a rush?" Ninety-four per cent said yes. This much sounds like common sense: if you say, "because I'm in a rush"--if you explain your need--people are willing to step aside. But here's where the study gets interesting. Langer then did the experiment a third time, in this case replacing the specific reason with a statement of the obvious: "Excuse me, I have five pages. May I use the Xerox machine, because I have to make some copies?" The percentage who let her do so this time was almost exactly the same as the one in the previous round--ninety-three per cent.

There is wide disagreement on how to interpret these results.  We don't have a definitive explanation yet of what is going on inside peoples brains.

My take is that people have an inherent hard-wired desire for meaning and explanation; and will respond better when given meaning and explanation. 

For small requests (such as, "Can I use the copier first?") any explanation will do, even one that seems content free.

However, for big requests (such as, "Commit your heart and soul to spending the next year building this ground-breaking new service.") you need a meaningful explanation and you need to deliver that explanation repeatedly through multiple channels.

                                                                                 copyright 2007 Kerry Champion