Ruining Habit #2: Withholding Feedback until “The Time is Right”

The next habit is one that drives your developers crazy, stunts their growth, and erodes trust between you and them. It will drive them away faster than you can imagine.

The habit? Withholding feedback from them until “the time is right”.

What does this look like? Consider this example:

Paula manages a group of developers. On Monday, Joe submits work that is unusually rushed and sloppy. Paula is disappointed and spends a frustrating hour commenting on all the shortcomings of his pull request. The longer she works on it, the more critical she becomes. She presses “Reject” and sends the pull request back to Joe. Feeling vindicated, she moves on to the next task. She makes a note to point out his failures at the next monthly sprint retrospective.

Notice that Paula had decided to give feedback, but decided to wait until the retrospective, which is a *feedback ceremony*. This makes her more comfortable because that’s what the ceremony is for, and it seems less like “conflict” (which she hates).

Unfortunately, most of us have worked at companies that save up feedback until a prescribed *feedback ceremonies* occurs.

Examples of feedback ceremonies could be:
1. One-on-one meetings
2. Annual (or semi-annual) reviews
3. Sprint retrospectives
4. Employee discipline
5. Termination

As managers, you should not limit your feedback to these feedback ceremonies.

Instead, you should begin giving *continuous feedback* to your developers. This is like *continuous integration* for your management practice.

That is the only way your developers will grow and improve. That is the only way you will get the team you need.

Remember, your job is to build a team of software developers who produce what the company needs. This is *your only job*. You are the only one who can do it within your team.

So Paula decides to wait until the retrospective, which makes her feel better. Unfortunately, this approach doesn’t help Joe at all.

In fact, feedback is a bit like milk left out on a hot summer day. It goes bad faster than you think.

How can feedback go bad?

Let me illustrate with Paula and Joe. Let’s imagine the day Paula rejects Joe’s work there are still eighteen more days until the sprint retrospective.

When Joe receives Paula’s comments he thinks, “Oh sheesh, she must be mad at me about something. I have no idea what, she’s impossible to read. She probably wants to fire me, which is why she found ten times as many things as normal. I’d better start looking for another job.”

For eighteen days Joe walks on eggshells, and has no real idea if Paula’s comments were *caused* by something other than the code he sent over. Joe’s past managers sometimes became more critical toward his work in the weeks leading up to his termination, and that’s what he fears is happening here. Joe suspects Paula’s feedback is more about *him* than about the *code*, but he’s certainly not going to ask her about it. He starts brushing up his resume, and looking at job boards, just in case.

Eighteen days pass, and Paula notes Joe’s sloppy work in the retrospective. She points out how it didn’t meet the teams “definition of done”, and it caused another team delays. She uses it as an example of a pattern she’s seeing across the team, and reminds to the team the importance of being “done” before submitting a PR. No big lecture, just a short reminder. Then she moves to the next topic.

Joe leaves the retrospective angry and frustrated because he’s spent the last eighteen days worrying about losing his job. If Paula had come and talked to him he would have known what he should do differently, and woulds never have scheduled three interviews for next week.

Joe thinks, “Oh well, I’d rather work someplace where my manager cares about me. I’ll do the interviews and see what happens.”

Notice how in the absence of facts Joe makes up reasons why Paula would grade his work so harshly? Even when faced with the specific comments in the PR, he placed the feedback within the context of a larger story that could be called, “My boss is mad at me is building a case to fire me.”

You might blame Joe for jumping to conclusions, or Paula for not being sensitive. I don’t think either is useful.

A conversation would have fixed this.

Either could have initiated that conversation, but both had their reasons not to. And we shouldn’t imagine that we wouldn’t have reasons not to as well, because we don’t see situations in our life perfectly either.

Joe might have felt that initiating the conversation would be risky for him, as he was in a lower-power position that Paula. He might have worried that he would look stupid, or asking for clarification would upset her. It felt safer to assume something than to ask for clarification.

Paula might have felt that a conversation would be risky for her, as she doesn’t want to be seen as a micromanaging, pointy-haired boss. She doesn’t need *more* conflict in her life. It felt safer for her to assume that Joe would understand what she meant than to have a potential confrontation.

If Paula practiced *continuous feedback*, she and Joe would both feel more comfortable with giving and receiving feedback. Instead of waiting for *feedback ceremonies* that make ones heart pound, giving and receiving feedback would be a normal part of their relationship.

Joe would learn he could trust Paula to speak her mind, which makes him feel safe. He wouldn’t worry that there was something else going on, and could focus on improving his work.

Paula would learn to trust Joe to take her feedback at face value and not become upset when she corrected him. Her continuous feedback would teach him that feedback was not scary, and was not conflict.

Here’s what that might look like…

Paula manages a group of developers. On Monday, Joe submits work that is unusually rushed and sloppy. Paula is disappointed, and spends a frustrating hour pointing out all the shortcomings of Joe’s work. At the end she pauses, and takes a deep breath. Paula decided last month to start giving continuous feedback to help her team improve faster, and reduce assumptions and miscommunications.

Paula asks Joe to come in for a few minutes. When Joe arrives, Paula shuts the door and say, “Joe, this code doesn’t seem up to your normal standards. I’d like to walk through it with you, but first, is there something else happening that I’m not aware of?”

Can you see the difference? Paula recognizes that this situation deserves a conversion, not simply some pointed, specific comments on his work. She recognizes it by how she feels (frustrated and disappointed), and that her comments aren’t in-line with the type and quantity of feedback she normally give gives.

She wants Joe to understand what her comments mean, and what they don’t mean. She knows that a conversation will be the best way for him to receive and digest this feedback, and will strengthen the trust relationship between them.

One of my workshop attendees, Bradford, recently told me “My company isn’t very good at giving feedback. We avoid it because it feels like conflict. I can see we need to get better at that.”

A few parting questions…

  • What feedback ceremonies does your company use?
  • Do you save up feedback for these ceremonies?
  • Do you find yourself holding off giving feedback out of fear it could cause conflict?
  • How much faster would your team improve if you gave them feedback as soon as you saw a problem?
  • How much trust would be built between you and your team members if they knew they could trust you’d always give them feedback if there was a problem
  • Would you like more (or more honest) feedback from your own boss?

Until next time!


One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.