Chapter 32. Actions speak louder than words

by Dan North

The way you act says more about your values than any pithy motivational slogan. A team is more likely to follow your lead in terms of your behavior than they are to follow your instructions, particularly if these aren’t aligned.

If you talk about valuing feedback and then get defensive when someone offers some, the team will unconsciously pick up on the defensive behavior. Conversely, if you always take the time to check in with your team, they’ll get into the habit of telling you things and may even become more comfortable talking with one another. Sometimes, this modelling can have a surprising upside, when you notice the team picking up a behavior intrinsic enough to your values that you never thought to make it explicit.

One of the toughest starts I had as a software team leader involved joining a team of nine strongly opinionated developers as their lead. They’d formed cliques within the team, and each thought the others were idiots and didn’t understand software. I was brought in primarily as facilitator: an external person who wasn’t vested in any of the cliques and who might be able to help them find a way forward.

My first priority was to take each member of the team out for coffee, one at a time, away from the office, and listen. I asked each person the same questions: what they liked and what frustrated them about the team, the software, and the project, and what they wanted to change. The thing that surprised me most was that they all saw the same issues and wanted to make almost the same changes. Before I got there, the team decided to introduce a design change to make part of the code more understandable, and they were busy arguing about how to implement it. There were some differences in the details, and it was here that cliques were forming. It seemed to me this was more about jostling for position than about an objectively better or worse technical solution.

I used the Shackleton technique of asking everyone for their input and then making a decision, while actively engaging with and listening to dissenters. We went ahead with one of the options; after a couple of weeks, we realized it wasn’t helping, and, in fact, the whole approach was making things worse! I took the responsibility for a bad decision, and we backed out the change, cleaning up as we went. Then a strange thing happened: people started to become less defensive and began experimenting a little. I inadvertently demonstrated that it was okay to try something and fail, which unlocked a whole new style of working.

If the boss could admit a mistake and move on, perhaps admitting uncertainty wasn’t such a sign of weakness after all. In fact, for a time the pendulum swung the other way, with people proudly announcing how little they knew about something, but that they were still willing to give it a go! Over time, it settled into a healthy rhythm of trying out several ideas, evaluating them, and then deciding which ones to progress. Rather than taking an absolute position and defending it, the team members became more open to the idea of discourse and collaboration, valuing team learning over their own individual status.

Roy’s analysis

In influence forces terms, this note deals with social motivation and environmental motivation.

People tend to imitate people they respect. If I see someone in the team whom I highly respect do something, like make mistakes and admit them publicly, and then see that nothing bad happens, I might be less afraid to confess my own mistakes and know that there will be no environmental punishment for it.

If I do that, and then my team leader comes to me and says, “Great job experimenting!” that’s an environmental reward: it’s reasonable to assume that my job is safer because my manager likes what I do, so I’m more likely to repeat the behavior.

Actions speak louder than words because they imply social motivation (“I’m not the only one”). Environmental motivation is implied if the organization rewards and appreciates those who make mistakes while trying to experiment.

DAN NORTH is an independent technology consultant who writes software and coaches teams and organizations in Agile and Lean methods. He believes in putting people first and writing simple, pragmatic software.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.148.103.210