The “They, They, They” Syndrome of Change

[article]
Summary:
Naomi Karten tells the story of a developer named Bruce who became upset when his team members acted indifferent to his plans to implement multiple changes. By viewing yourself as a participant in the change effort, the odds will be higher for having your ideas accepted and acted on, as opposed to Bruce's situation.

Bruce, a sharp and curious guy, started a new job on a large project already in progress at BiggieCorp. As an experienced developer, he was overflowing with ideas about how the project team could do more, faster, better, and cheaper. (Bruce was a master of adverbs!)

Undeterred by his lack of familiarity with the team, the project, and the company—as well as his eagerness to demonstrate his worth to his team-mates—he downloaded his ideas by the barrel, which is to say, he foisted his ideas on them. His teammates (no spoiler alert needed here) rejected the ideas, one by one by one.

Bruce’s frustration was palpable as he told me what he thought of the team. They’re averse to change, he vented. They want to keep doing things the same old way. They’re afraid of trying anything new. They don’t realize all the opportunities they’re missing. They…they…they...

The problem, as Bruce saw it, was entirely theirs. Even after the project was implemented— successfully, by the way—Bruce continued to grouse about what might have been, if only they

It’s impossible to know if the team would have been more receptive to Bruce’s ideas if he had presented them differently, but it was clear from his venting that the way he tried to “get them to change” was destined to fail. And such failures are common: people attempt to introduce change to their team, their customers, their management, or others; find their ideas rejected; and see those who (in their eyes) refuse to accept these ideas as the problem. They…they…they…

What might Bruce have done differently—and what can others do—to increase the odds of potentially valuable ideas being seriously considered by those they serve, support, and work with?

Learn about the context and build trust.
As a new member of the team, it would have been to Bruce’s advantage to hold back, listen, observe, and become familiar with how the team functioned. His eagerness to help, genuine though it was, led him to spout idea after idea before he had gained the trust of the other team members. Besides, in not knowing what had worked and what hadn’t in previous projects—or thus far in this project—he was spouting ideas out of context.

It’s rarely a waste of time to learn about the history of a team’s efforts, both in previous projects and in the current project to date. By learning more about the team’s experiences, Bruce would have been in a better position to promote his ideas.

Arrange one-on-ones with key team members.
Bruce introduced his ideas in meetings where the entire team was present. In such a setting, his ideas were shot down with almost no time devoted to discussion or analysis. He couldn’t counter the views of the various team members because the setting didn’t give him a chance to learn what those views were. This is a key issue in introducing change: it’s difficult to persuade a group, especially if some of its members have mindsets already predisposed to dislike the ideas.

By holding one-on-ones, he could have gotten to know the team members better and gained insight into their fears and concerns about the project, as well as their hopes and wishes. With this knowledge, he could have tailored his case to each such individual and been better prepared to counter their objections.

Communicate with care.
There was more than a hint of arrogance in the way Bruce described his ideas for improving the project and how the team rejected those ideas. I didn’t witness his efforts at persuading the team, but if they sensed the same arrogance I did, it wouldn’t be surprising that they overruled his ideas. People will be inclined to reject the best ideas if they don’t like the tone or attitude of the person presenting them.

Furthermore, as the new kid on the team, Bruce might have found a better reception for his ideas if he asked what the team thought of them, rather than preaching about what he thought was good for the team. Asking “Do you suppose it would be a good idea to…?” might have won more support than forcefully stating “We really should…” or “It’s ridiculous not to…”

Recognize that introducing change is a sales job.
Bruce actually didn’t seem to realize that he was attempting to introduce change, and that doing so would entail selling his ideas to his teammates. Whether you’re selling products or services or you’re trying to persuade others to “buy” your ideas, proposals, or recommendations, you’ll be more likely to succeed if you consider the perspective of your intended buyer.

For example, some people are leery about buying because they’ve been burned by solutions that proved to be more complicated, befuddling, expensive, time-consuming, or troublesome than they were worth. Some people simply need time; the bigger the decision, in terms of bucks, impact or risk, the longer the sale will take. For some people, every decision is a big one. The key is patient persistence—and persistent patience.

Start small.
Bruce was so gung ho about his ideas that he wanted to implement them all at once. No wonder team members were leery. Instead, he might have proposed one small change for this project, taken responsibility for overseeing it, and in so doing demonstrated its effectiveness (if, indeed, it proved effective). By having something to point to as evidence of the worth of his ideas, he would have had more clout when he proposed more and bigger changes for the next project.

Wait and see.
For all that might have seemed similar between this job and Bruce’s previous job, he was now in a different company and on a different team. And for all its similarities, this project was different from those he had worked on previously. He was a phenomenal idea person, and therefore potentially a major asset to the team. But without a basis for assessing the relevance or applicability of his ideas to this particular project, he was the one missing opportunities.

And therefore…
The bottom line for Bruce is that he would have stood a much better chance of being successful in introducing change if, instead of characterizing others as unwilling to change, he started by looking within and asking, What do I need to do to succeed? How can I introduce this change in a way that others will be most receptive to it? How can I present my ideas so that these ideas will get a fair hearing?

And the same is true for you (and for me). There are no guarantees, but by viewing yourself as a participant in the change effort, the odds will be higher for having your ideas accepted and acted on.

User Comments

2 comments
Susan Bedford's picture
Susan Bedford

This is a great article; there are a lot of Bruces out there and the suggestions for an improved response are spot on.

So many times a newbie comes onboard and wants the existing group to change their processes to his/her way of doing things. This is labor intensive enough if there is just 1 newbie and the change actually improves things (vs making things worse or changing happy to glad). Unfortunately, 3 months later there is another newbie and he/she wants the existing group to change their processes to his/her way of doing things. The newbies do not agree.

Waiting a cycle or 2 to realize better what changes would work best with a group is an excellent idea. Offering to shoulder the effort implementing the change will require is also an excellent idea.

well said Naomi

February 27, 2013 - 8:40pm
Chris Riesbeck's picture
Chris Riesbeck

The variation of this advice I give is to listen and watch until you see what appears to be a problem -- some inefficiency, tedious action, common error -- that you think you have a solution for. Then mention this to the team. If and only if they agree that there is a problem, then bring up the idea and see if it resonates.

March 5, 2013 - 11:56am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.