Geoff Mazeroff

I was catching up on my podcast listening while doing some chores this weekend. One of these was .NET Rocks! 1406: Punishment Driven Development with guest Louise Elliott. There were too many times when I told myself “oooh, that’s good — remember that for later” that I knew I needed to re-listen to the episode and take notes.

Here are the notes that I took:

• Avoid creating a culture of blame.
• Many of us engage in self-punishment when we do something we wish we hadn’t done (e.g., making a change directly on a production server). You could even argue that technical debt can lead to self-punishment: You’re pressured by the organization to get it done, then you torment yourself about it.
• Louise mentioned a time where one person on the team didn’t quite fit in. She was asked to fix the issue (because obviously, it’s that person’s fault and they need to be “fixed”). The individual asked basic questions, wouldn’t stick to any decisions, and seemed slow on the uptake. She tried implementing two strategies: (1) let him finish asking questions; (2) have the team e-mail out the decisions made. Just because somebody thinks differently doesn’t mean they’re bad, and verbal decisions may not feel as real.
• People are not interchangeable. If I try to manage someone how I want to be managed or the way I naturally would manage, then that’s about me rather than being about them. Manage for them, and not for you.
• Working with people is like a puzzle: The assembled puzzle is way more valuable than the pieces. And the puzzle doesn’t work if all the pieces are the same.
• Don’t have everyone agree all the time. If everyone agrees, then we haven’t explored it thoroughly enough.
• If you’re writing software, you can’t avoid getting to know the requirements. So why would you avoid getting to know your people/team?
• You can make the wrong assumption that what motivates people is the same as what motivates you. You assume that the world and the people in it are like you.
• What if somebody isn’t pulling their weight? (See also: Theory X and Theory Y.) People want to make a difference. If you have someone trying to do the least they can do while at work, what has happened to them? It’s usually because they’ve been shut down, told it’s not their job, they’re disenchanted, they don’t think they can make a difference even if they wanted to. They ask themselves why they should keep trying. You want people to be happy.
• Sometimes the answer is for the person to leave. They may need some distance. It’s toxic for a team to see that there’s a failure in management and that it’s not being addressed. It’s uncomfortable to have those conversations, so managers avoid them.
• When someone isn’t delivering, it’s always approached from the “what’s wrong with you?” angle.
• Asking people why they did something invites defensiveness. You can ask what’s going on (how are they feeling, what’s life outside of work like for them), and try to obtain more context.
• If someone is being arrogant, ask why they feel the need to be like that. That person deserves the right to have that addressed.
• Instead of having people feel bad for a mistake happening, why not do a 5 Whys and ask why that was possible in the first place?
• Self-blame stops people looking at the lessons. “Be more careful next time,” is not good root-cause analysis. When someone makes a mistake, they’ve helped find an issue so that it can be addressed.
• Bonus schemes
  • Some companies have tried ones that are inversely proportional to the number of bugs found in user-acceptance testing. The best way to have no bugs is to not write code. What about measuring bugs per unit of measure (man-hour, lines of code)? This puts tension between the developers and QC.
  • One suggestion was to have bonuses about the end product so you work as a single team.
  • Zero sum games don’t work. “I don’t have to be the fastest, I just have to trip you.”
  • Bonus schemes based on objectives that have changed/shifted means you end up focusing on the wrong thing. You make decisions that are good for you rather than good for your customers.
  • Up to a certain point, money doesn’t motivate: look to autonomy, mastery, and purpose. Software is already high-paying. Why do you think open-source exists? Because developers don’t create those things where they work.
• If you find yourself having a strong emotional response, your natural (impulsive) reaction usually brings about the worst outcome. Use that response as a signal to step back and ask what you want out of the situation.
• Not reacting isn’t a good solution either. Don’t suppress; acknowledge and ask what you want. Realizing you have these triggers is valuable; it takes courage.
• We’re not responsible for other people’s feelings, and they’re not responsible for ours either.
• It’s amazing how much distress people have is not actually about them.
• Trying to make someone justify their behavior can be stressful. What is it you really want? Can everyone keep their dignity?
• We always talk about the tech side of development. Ultimately it comes down to if you can’t get along within your organization and learn how to navigate the morass of feelings/egos/all of that, you’re just going to bounce from job to job and never be happy, no matter how good you are.
• When projects fail, it’s typically about how you work together rather than the technology.
• See narcissism of small differences; these people are very similar to us, but we have to find the things that makes us unique so that we can hate them, and make “us” feel more alike. Once there’s an “us” and a “them,” it doesn’t matter how well-intentioned everyone is. We get tribal — for us to be in, we have to be able to define who’s out. This can be toxic. To address this, redefine the tribe (which is hard to do). Reform what the team is. Remember that Agile is fundamentally about communication and teams. Redefine the group as a cross-functional team that works together.
• We can sometimes get into black/white thinking — e.g., that’s their job, so I won’t do it. This allows you to blame.
• Be aware of what tools you have and when to use them. Pick and choose — this team, at this point, to do this job.