insights you can use

Promises, Promises.

2007-12-03T09:40:00.000-06:00

Last week I wrote about a middle manager who didn't consider renegotiating a low value project because he'd given his word to his boss.

The response to the post was consistent:

Ken Flowers said,

I have to assume that if the project doesn't make sense to the middle manager, it also wouldn't make sense to the VP. If I were the VP and found out that my manager was doing a project that he knew was ineffective, I would be really angry. I would expect him to talk to me about it first. I pay him for his judgment.

Dwayne Phillips posted:

Beware of promising things that are out of your personal control.

"I promise to look at this and get back to you"

"I promise to do what I CAN"

"I promise to investigate what this project means to you, me, my group, and our company."

On Ken's site, James Todhunter left this comment:

Concealing material information demonstrates a fundamental lack of integrity. I wouldn't want such a person on my team. I could never trust their input or judgement.

It's clear that a middle manager who continues down the wrong path because he "gave his word" is undermining how other people view his integrity.

What happens if we replace "middle manager" with "senior manager" and "boss" with "client" ?

I talked to an executive recently who promised a big client that his company would deliver a special project for them.

Unfortunately, he made a promise on the basis of incomplete information. Once he talked to his development group and ran the numbers, it turned out the work he promised will have a negative return on investment. And it's a double whammy: doing the low value work will delay doing higher value work, and cause the group to miss other targets.

But the executive refuses to consider going back to his client to explain the situation and renegotiate. He gave his word, and he feels his integrity is at stake.

How does the change in position and authority effect your response about the integrity question?

They don't get it (...well, maybe)

2007-11-26T10:13:00.000-06:00

I got a call from an acquaintance, Gloria, who is trying to convince her organization to adopt agile methods.

"I've given them every logical argument I can think of," she said. "They just don't get it. All I get is blank looks. How stupid can they be?"

"They" probably aren't stupid at all.

But they may have a different frame of reference, or a different mental model.

They may value something that isn't considered in Gloria's logical arguments.

They may agree completely with Gloria's argument, but don't see how to get to where she wants them to go.

They may be afraid that if they do what Gloria suggests, their managers will be angry.

What Gloria doesn't get is this: while logic is appealing, it isn't always the most effective tool for persuasion.

Rather than try to win through logical argumentation, Gloria might try understanding:

what other people value
what other people fear
what obstacles other people face
what problems they want to solve.

Going, Going...

2007-11-26T10:06:00.000-06:00

Diana and I have one space left in the December 11-13 Secrets of Agile Teamwork in Portland, Oregon.

SAT is three days of experiential learning and practical tools to help you and your team reach the next level of collaboration and productivity.

Be the first to fax your registration and the spot is yours.

After that, its the waiting list.

Interview with Jerry Weinberg

2007-11-22T12:04:00.000-06:00

An interesting interview with Jerry Weinberg here, at the Citerus site.

Some excerpts:

Q: You must have seen a whole bunch of ideas, about how to best do software development, grow and die over all those years. Do you see the agile movement as a pendulum swing or is it a move in a new direction?

A: How about a pendulum swing in a new direction? It's a pendulum swing because approximately every decade, there's a fresh movement to "solve the programming problem." High-level languages, structured programming, object-oriented programming, ...

But it's a new direction because it's the first movement to focus largely on social processes rather than purely intellectual ones. For that reason, I believe, it has more hope for success than the earlier movements, each of which made a little progress, then largely ran out of steam before achieving its grand promises.

Of course, agile won't achieve all its grandest promises either, given the conservative nature of human beings, but that's all right. After another dozen decades or so of incremental improvement, we'll begin to see some really fine software development. Well, I shouldn't say "we," because none of us will see them, but at least our great-great-grandchildren will be able to look back at us and laugh at our crude methods.

Q: If you're the J.K Rowling of software development, who's Harry P then?A: Well, first of all, I'm not a billionaire, so it's probably not correct to say I'm the J.K. Rowling of software development. But if I were, I suspect my Harry Potter would be a test manager, expected to do magic but discounted by software developers because "he's only a tester." As for Voldemort, I think he's any project manager who can't say "no" or hear with Harry is telling him.

Promises Involve Self, Other, and Context

2007-11-22T11:48:00.000-06:00

I talked to an middle manager recently who promised his VP that his group would deliver a special project for the VP.

Unfortunately, he made a promise on the basis of incomplete information. Once he talked to his group and ran the numbers, it turned out the work he promised will have a negative return on investment. And it's a double whammy: doing the low value work will delay doing higher value work, and cause the group to miss other targets.

But the middle manager refuses to even consider going back to his boss to explain the situation and renegotiate. He gave his word, and he feels his integrity is at stake.

I think he's leaving something out. In standing on "integrity," he's considering self, but not the context or the other people involved. What about the financial integrity of the company? What about the people who have to do the work, and will work overtime to meet other commitments, or experience consequences when they miss other dates?

There's another part of integrity that involves cleaning up your own messes.

Focus on the individual or the system?

2007-05-02T14:12:00.000-05:00

I've been watching a discussion on the Agile Project Management yahoo group, which poses the question, "Does everyone in agile need to be above average?"

The question behind the question is, "Does agile need extremely competent people in order for it to work?"

When I read stuff like this, I wonder "What method of building software works without competent people?" It's a puzzle.

Which brings me to this snipped from Bob Sutton (via Jason Yip):

Great systems are more important than great people. The notion that you are doomed to mediocrity if you can�t hire the very best people has little empirical support. Yes, there are big differences between the most talented people and the next level down in most occupations. But systems are more important. Toyota beats the competition as a result of a superior system; Men�s Wearhouse and McDonald�s don�t hire people that are much different from their competitors, but their systems explain their long-term dominance more than their people. As Jeff Pfeffer says, many organizations seem to have �brain vacuums� to turn people who seem to be smart into bumbling fools. Even the most brilliant person is doomed to fail in a bad system, and seemingly mediocre people can become stars in a great system.

Agile methods are a system that can help people perform better.

One agile coach I know tells a story about the first agile pilot in her organization. Someone in senior management didn't want the pilot to succeed. So he sent her all the "poor performers" for the pilot team. But they ended up outshining expectations and did a fine job of delivering valuable working software.

Further, focus on individual talent (and focus on individual performance management) takes focus off improving the system.

(I'll say this now, because someone always asks at this point "So you're saying we should hire incompetent dodos?" No, I'm not saying, "hire dodos." Hire competent individuals who are a good fit for the organization's culture. Focus on improving the system to improve results. Focus on individual performance for career development. Give feedback to help individuals become more effective.)

What every manager should know about feedback

2007-04-28T07:47:00.000-05:00

Wanna know? Read it here: My article What Every Manager Needs to Know About Feedback is posted at CIO.com.

Two more ways to gather data in retrospectives

2007-04-28T07:27:00.000-05:00

If you've been holding iteration retrospectives for a while, you know that timelines get old after a while. But when team skip the data part, each person works from his own data (which other people may not know) and his own interpretations (which other people may not share). That means that the team is less likely to come up with actions that have broad support.

So here are two more fairly quick ways to gather data for an iteration retrospective.

Diana describes FRIM, an activity that looks at the frequency and impact of events, impediments and boons that affected the team during the iteration. Use this as input into analysis and to decide on experiments and changes for the next iteration.

Jean Tabaka used a sailing metaphor to gather data at the Retrospective Facilitators Gathering retrospective. She asked us to identify events, interactions, etc that put wind in our sails. Then she asked us when we were in the doldrums, becalmed or held back by tides and current. We put up the "wind in the sails" stuff behind the boat, filling the sail and the doldrums stuff in front of the boat. The metaphor helped keep us out of habitual thinking and automatic categorization. And it was kind of fun.

Agile Retrospectives review

2007-04-20T17:04:00.000-05:00

I just came across this nice review (written by Brad Appleton) of Agile Retrospectives: Making Good Teams Great on AgileJournal.com. For me, "useful" is the highest praise for a book.

Secrets of Agile Teamwork June 5-7, 2007

2007-04-08T20:55:00.000-05:00

Diana and I are offering Secrets of Agile Teamwork this June 5-7, 2007 in Portland, Oregon. This is a public workshop, open to 12 people.

We'll be focusing on the interpersonal skills that enable people to be effective team members. We'll be looking at communication, conflict, shared leadership, and forming and nurturing teams.

If you want to be the best team member, ScrumMaster, or coach you can be, join us for three days of learning and fun. Download a registration form here.

Overcoming "resistance"

2007-04-07T19:14:00.000-05:00

Back in February, I wrote a post on helping people change and pointed to George Dinwiddie's post on Overcoming Resistance. His post has grown up to be an article, and it's posted on the AYE Conference website.

When is it time to move someone off a team?

2007-04-04T20:00:00.000-05:00

When I talk to teams about self-organizing, people worry about what to do when some one on the team isn�t working out.

If we�re a team, they posit, we have to work things out so we can work together. Not necessarily so.

Teams need to manage team membership so that they can achieve their goals. There are times when teams can work things out to work together. And there are times when someone needs to go.

I see four common reasons to move to move someone off a team.

When a team member doesn�t have the skills needed to do the work and can�t (or won�t) learn them in the timeframe needed by the team and the business. This can happen because of a hiring mistake, when the company moves to a new technology, or when the focus shifts from one type of work to another (e.g., from manual functional through the GUI testing to automated testing through APIs).

This is really hard when it�s someone who has contributed and now can�t make the learning curve. If there�s no other way for the person to contribute, it�s time to move him off the team. In the long run, though, allowing the situation to continue doesn�t do anyone favors. The team may start to resent the non-contributing team member. The non-contributing team member doesn�t have the satisfaction of pride in work and making a contribution. Everyone suffers.

When someone can�t or won�t work collaboratively. For example, when a person focuses on completing his tasks at the expense of completing the team�s iteration goal, or the rest of the team agrees to share code-ownership and he refuses to relinquish control over �his� code. Or when an individual doesn�t communicate with other people on the team.

On a team with interdependent goals, having a member who refuses to collaborate (for what ever reason) makes it harder for everyone to do their work. It also creates a dynamic where team members focus time and energy on the behavior of one team member rather than on building working software. It�s futile to try to convince someone to work collaboratively when he doesn�t value collaboration.

When the person challenges efforts to move forward that aren�t perfectly aligned with his ideas. Sometimes an individual sees risks in an option and has a hard time talking about it in a helpful way. Usually this comes as �that will never work here,� or �we tried that and it didn�t work�. This is irritating; AND there�s often useful information behind the objection�when you tease it out. (And you can coach the person to modify their style.)

On the other hand, some people challenge efforts to move on a philosophical basis�they call into question whatever the team proposes on the basis of an abstract notion of how-things-should-be. It�s really easy to get hooked on the content and get sucked into discussions about why some action is or isn�t pure and correct.

There is a place for �devils advocating� and vetting actions against fundamental values. That�s an important function on any team and I�m not talking about eliminating it. However, when one member has a pattern of challenging efforts to move forward, not letting go, and killing new ideas with criticism, its a problem. Especially when the challenge shifts to meet each new proposed avenue of progress that doesn't meet the purity test.

When someone has a fundamentally different vision of where the team should go. A few years ago, I was traveling from Amsterdam to Copenhagen by rail. My route required that I change trains twice. As I settled in to my seat after the first train change, a nice German woman asked me where I was going. �Copenhagen,� I replied. �Oh, no, my dear,� she said, �you are going to Berlin.� I guess I could have argued, but instead I got off at the next station, back tracked, and got myself onto the train that was going to where I wanted to go.

It�s like that sometimes with teams. Most of the team wants to go in one direction, and one individual wants to go in a dramatically different direction. And he argues for that direction, well after the majority of the team has expressed their commitment to go another way. The team spends lots of time trying to convince the one person, and that person spends a lot of time trying to convince the team. At a certain point, it�s time to say, �This is where we are going. We want you to come with us. If it doesn�t fit for you, we understand. And you�ll need to go your own way.� Early in the life of a self-organizing team, the coach may have this conversation. Some teams reach the point where they have the conversation amongst themselves.

There�s a risk that the individual has the right of it, and the team is headed in the wrong direction. But if the team makes some movement, they are likely to discover that, and then they can make corrections. As long as the argument continues, no one is moving at all.

Excluding some one from a team is difficult. Most of us want to feel included and part of the group. That�s a potent trigger for most of us. Some people feel overwhelming anxiety over excluding someone from the team. For others the need to belong is equally overwhelming. Helping someone move off a team is seldom easy. And when it�s done�and handled with respect and caring for the person who is leaving the team�it�s doesn�t have to be a traumatic event for anyone.

A ScrumMaster is like...

2007-03-25T14:24:00.000-05:00

Every so often someone asks what the title ScrumMaster means. Some assume it implies mastery of a subject, such as a Zen Master, or a master carpenter.

My friend Bryan Stallings gave the best answer I've heard so far:

When I work with those new to Scrum I explain this subject as follows...

I ask them to tell me what a Master-of-Ceremonies does. They tell me about events such as the Oscars and explain that an individual with this role is responsible to ensure that the event progresses as planned, that they facilitate the transition from one phase of the event to another, and that they step in should anything unplanned occur.

I then ask that they describe to me the responsibilities of a Quartermaster in the military. They explain that a Quartermaster provides the troops with all that is required for their success and comfort, and sets-up suitable circumstances.

I of course agree with them and then I proceed to explain that like a Master-of-Ceremonies, a ScrumMaster is responsible to ensure that the Scrum process progresses effectively from event to event, that a ScrumMaster also steps in should an obstacle to success be encountered. Additionally, I explain that like a Quartermaster, a ScrumMaster shoulders the responsibility to provide the team with all that is necessary to ensure their success, comfort, and suitable circumstances.

Obviously, mastery of coaching a team to self-organize and helping teams and learn how to deliver working software every iteration is a study that can consume an entire career. In the meanwhile, Bryan's definition gives a good place to start the journey.

Estimating hard-to-measure benefits

2007-03-21T08:32:00.000-05:00

Last week, I wrote a post about decisions that look only at easy-to-count costs and ignore hard-to-count benefits.

Here�s one method for estimating hard-to-count benefits, subjective impact analysis:

1. Identify the proposed course of action.
2. Determine what�s important to the person who makes the decision.
3. Ask that person who they consider credible sources related to the issue.
4. Create a short interview protocol.
5. Interview the people the decision maker identified as credible.
6. Summarize and present the results.

Here�s part of a subjective impact analysis I did for a client a billion years ago (suitably scrubbed).

The client was a VP in an IT operation. The business was livid about the production problems and outages that followed when the IT group installed new functionality.

When I looked at the data about outages, it was pretty clear that the worst problems came from the hand-off between the development folks and operations folks. I poked around, and found that the two groups weren�t working together.

So I suggested a little experiment: a �readiness review� prior to installing a change where the development people and the operations people would sit down together and walk through the installation. And I created a half-page checklist for the development people to actually write down critical information for the ops folks.

Then we tried the experiment. We held a "readiness review" for a smallish update to the production systems. The meeting took about 45 minutes.

After the �readiness review,� the IT managers told the VP they were concerned about adding another meeting that took away from development time. The developers complained about the burdensome documentation (half a page).

The costs were obvious.

The benefits were not so obvious.

So I did a subjective impact analysis to show the benefits (if there were any).

Here�s what the VP valued:
� Avoiding production problems
� Improving the application
� Taking a proactive stance

I asked a cross-section of the people who participated in the review these questions:

1. What gaps and issues came up in the review that could have caused problems had they been discovered in production?

� What was the biggest problem discovered in the review?
� On a scale of 1 � 10 (1 = negligible impact, 10 = disaster), how big would that problem have been?

2. What was the team able to do to improve the application because of the review?

3. What problems did the team fix before they hit in production?

Then I summarize the data and presented it to the sponsor. Here�s the data from the first question.

Problems Discovered in the Readiness Review
(1 = negligible impact, 10 = disaster)

10 ****
9 *
8 ***
7 **
6 *
5 *
4 **
3
2 **
1

(This represents each person's assessment of only the biggest problem, so it�s a subset of the problems. For the most part, the development folks identified lower impact problems, the ops folks higher impact problems. Very interesting...)

This little data table helped people see the benefits of the readiness review, as well as the costs.

(Obviously, there were lots of other issues with this organization. This was a starting point to bring the level of conflict down enough for people to look at underlying problems.)

I did this subjective impact analysis after the fact, but you could easily adapt it to estimate benefits before making a decision.

quick peer code review

2007-03-16T05:12:00.000-05:00

Via Testing Reflections:

Jared Richardson (co-author of Ship it! A Practical Guide to Successful Software Projects) explains how to do a quick peer code review.

Another low tech way to improve the quality of the software we deliver.

Face to Face Still Matters

2007-03-16T02:45:00.000-05:00

There's been a discussion going on the the Retrospectives list on how to do distributed retrospectives and planning meetings. The assumption is that it's cost prohibitive to bring the group together.

People always site cost as a barrier. It does cost money to bring people together face to face. There's lodging, airfare, time not spent on billable activities... and all these are easy to count.

But what this thinking doesn't take into account are the costs of not having the team face to face for planning and retrospectives:

Less collaboration, greater misunderstandings, continuation of us/them dynamics (be they ever so subtle there's always differences in access to power, information, and resources), miscommunication, etc.

And there's lost opportunity to build relationships and trust which short-cuts many of those problems.

But all those are hard to measure and quantify, and are almost always left out of the cost equation. People look at the costs without any of the benefits.

Even when you have access to great technology for planning, retrospectives or other forms of collaboration, face to face is still superior for communication and collaboration in the moment and in building a foundation for future communication. Face to face is superior in building shared commitment and infusing a project with energy.

Pay for Performance (and why it doesn't really work)

2007-03-10T07:50:00.000-06:00

Every so often, I share my views on pay-for-performance and annual performance appraisals on this blog. My experience is that pay-for-performance and annual performance appraisals--contrary to popular belief--actually hurt performance and results, rather than driving higher performance.

So I was interested to learn, via Bob Sutton's blog, that Jeffrey Pfeffer (co-author of Hard Facts, Dangerous Half-Truths And Total Nonsense: Profiting From Evidence-Based Management and author of several other books on management)was called to testify before Congress on the matter of pay-for-performance.

Pfeffer's testimony walks through the assumptions underlying pay-for-performance,

Money is an important motivator.

Motivation is the issue for enhancing performance.

Individual performance can be reliably and unambiguously assessed.

Individual, rather than collective, rewards are important because of the need to overcome free-riding problems.

Differentiation in individual rewards, a necessary and frequently explicit consequence of individual pay-for-performance systems, leads to higher unit performance.

....and lays out the evidence related to those assumptions. (They don't hold true when you actually look at the evidence.)

He also points out that when the explicit and implicit message is that people (and their contributions) aren't valued, tweaking the compensation system won't overcome the depressive effects on performance.

If the senior managers at a company really want to improve performance, tinkering with the pay system isn't the way to go about it. Addressing the underlying culture and quality of management is.

Although the list of high commitment or high performance work practices differs slightly among authors and studies, most such lists include: a) sustained investment in training and development, including job rotation, both formal and on-the-job training, and a tendency to promote from within as a consequence of the successful internal development of skill and people; b) an egalitarian culture in which formal status distinctions are downplayed, salary differences across levels are less than in the general economy, and in which people feel as if their contributions are important and valued; c) delegation of decision making responsibility so that skilled and developed people can actually use their gifts and skills to make real decisions; d) high pay to reduce turnover and attract the best people, coupled with rewards that share organizational success with its members; and e) employment security and a policy of mutual commitment, so that the workforce does not fear for the outcomes of events over which it has no control and instead, feels reciprocally committed to the employer.

He ends his testimony with this statement:

We should implement what we know, rather than what we hope, or wish, might be true.

Read the full testimony here.

Pesky co-workers

2007-03-08T06:41:00.000-06:00

I wrote a little article on dealing with co-workers who annoy you. (Not surprisingly, the solution starts not with the co-worker, but with you.)

Practicing Leadership

2007-03-06T06:29:00.000-06:00

From an interview on Workforce.com.

Ram Charan defies traditional notions about leadership. It�s no longer enough for leaders to be charismatic and courageous to be successful, he says. Instead, they need to hone their skills to address the needs of their organizations...

Workforce Management: What is new about your perspective on leadership?

Ram Charan: In the past, most people have talked about personality when they talk about leadership. They think that leaders are born. My view is that once you are 22 or 23 years old, you have a basis of who you are, but you don�t have the skills yet to be a leader. Many leaders today are great communicators and are charismatic, but that�s not enough. If they can�t perform, they are out. To learn how to perform as a leader, they need to practice through real-life experiences.

WM: How does one "practice" leadership skills?

Charan: You practice the ability to handle diverse experiences. You move from one business to the other and develop your skills as you move along. You learn how to work in a team and how to create change.

Leadership isn't about personality or charisma. It's about understanding and skills. That means leadership can be learned, and that leadership looks different in different circumstances.

Flow

2007-03-06T06:15:00.000-06:00

Via Frank Patrick, Mihaly Csiksczentmihalyi on the componenets of enjoyment and flow:

Eight Components of Enjoyment

1. Confronting tasks that we have a chance of completing.

2. Concentration.

3. Concentration is possible because the task has clear goals.

4. Task provides immediate feedback.

5. A deep, effortless involvement removes from awareness the worries and frustrations of everyday life.

6. Enjoyable experiences allow one to exercise a sense of control over one�s actions.

7. Concern for self disappears, yet paradoxically the sense of self emerges stronger after the flow experience is over.

8. Sense of time is altered - hours pass by in minutes.

The Prime Directive, continued

2007-03-04T19:46:00.000-06:00

George continues the exploration of the Prime Directive.

Great Managers are Made, Not Born

2007-03-02T08:13:00.000-06:00

I came across a spate of articles lately proposing different reasons why some managers fail. The reasons ranged from rising to their level of incompetence, becoming corrupted by power, promotion by favoritism, and not being a "born leader."

I suspect the reasons are less nefarious.

I suspect managers fail because they haven't developed the skills to be a good manager.

I don't buy that successful managers are "born leaders." I believe that successful managers have skills and abilities related to both management and leadership behaviors. And, my experience is that except for those rare birds who just don't like working with other people--people can learn the skills and develop the abilities to be successful managers. (Assuming reasonable emotional adjustment, self-awareness, and the ability to inspect and adapt their own behavior.)

Of course, it's harder to learn those skills and develop those abilities when there aren't good role models, and when a new manager doesn't have coaching and support to improve.

So if you or someone you know would like to work on their management skills and abilities, consider coming to the Managing One-on-One workshop Johanna and I are offering April 23-25, right here in lovely Minnesota (the show should be gone by then).

Office Romance

2007-03-02T06:14:00.000-06:00

Via Johanna: The Rules of Office Romance, on Information Technology Dark Side.

Most advice regarding office romance will tell you to be discreet, steer clear of your managers and subordinates and review the HR policies. That advice assumes you are going to stay with a company and can successfully navigate the political hailstorm you will fall into. The better advice � advice that is both easy and foolproof � is just don�t do it.

And if you fail to follow this clear cut advice...

In the mean time, you will have to deal with increased HR scrutiny, jealous coworkers, office rumors, productivity losses, suspicion of favoritism, potential career damage, loss of power and the threat of sexual harassment lawsuits.

That's while you are dating. When you break up, it gets really ugly.

The original post also includes a handy chart to help you determine when to pursue an office romance.

Appreciative Retrospectives

2007-03-01T06:06:00.000-06:00

Diana Larsen has an article on Appreciatative Retrospectives posted on the AYE Conference site. Appreciative retrospectives build on strengths and look to create the circumstances that enabled people to be at thier best.

(Diana will be one of the guest presenters for the 2007 AYE Conference.)

A change story

2007-02-28T08:56:00.000-06:00

I�ve been noticing a problem in my office lately. My dog, Pudge, spends a lot of time in the office with me. She has a blanket in the corner where she hangs out and naps or chews her nyla bone. The only problem is that the blanket tends to spread out and cover a large expanse of the hardwood floor right across the entrance into my office. Then I come in and step on it and go flying. Plus when it�s spread out, it�s not very cushy for Pudge.

So I had the bright idea to improve things and make things better for both of us.

I sent away for a fine, cushion-y, and washable dog bed. I measured Pudge, and I measured her other favorite spot (a chair in the living room) to get the right size.

I was sure she�d love it. Why wouldn�t she? The new bed would be much better than the ratty old yarn blanket, much cushier and more comfortable. And her nyla bone wouldn�t get snagged in the yarn and all tangled when she pawed the blanket around.

When the new dog bed arrived, Pudge was curious about the box. She was even curious about what was in it.

But when I took her ratty yarn blanket away, her curiousity vanished. I put the cushy new dog bed down and urged her to try it. She sniffed at it, then took her nyla bone into the kitchen for a good chew. Over the course of the day she moved all her chews and toys to a new location, far away from the new bed.

The next day, instead of hanging out in the office on her fine new dog bed, she sat in the kitchen on the hard floor. After a while, I enticed her onto the new bed with a biscuit. She stepped gingerly onto the bed, picked up the biscuit and left. Later, I picked her up and put her on the bed. She stayed as long as I was scratching her belly, then headed back to the kitchen.

Eventually, she accepted that her ratty yarn blanket wasn�t coming back and started lying on the cushy new dog bed. We�re in a new status quo. She�s content in the corner of the office, all her nyla bones have migrated back, and I�m not tripping on the blanket.

So what can a story about my dog tell us about change?

Our wonderful ideas of how to make things better for other people may not be greeted with enthusiasm.

Other people may value things about the old way that we don�t see or don�t appreciate.

Things that we don�t like about the old way may be valued by other people.

It takes time for most sentient beings to adjust to a new way.

People accept the new way to retain something they value.

Even when the new way is accepted, people may look back fondly on the old way.

So don�t take someone else�s lack of enthusiasm as an indictment of you or your ideas--but look at how you introduce your ideas.