“Ever Present” by JD Hancock is licensed under CC BY 2.0

I’ve heard that a lot this year and it’s changed me in two pretty fundamental ways.

First, I’ve started seeking it out.

A year ago, I might have been more likely to deliver some software to my customer (other software developers) with a note like:

“Here’s the super-blammo tool that will solve problem X for you. Hope this saves you some time in the future!” After that, radio silence. I rarely got to know how much and if it could be improved until something in the tool frustrated them enough to log an enhancement case.

Six months later: “The super-blammo tool is great under condition A, but it completely dies under condition B.” That’s cool. Condition B didn’t even exist when the tool was built. Another iteration through the pipeline and hopefully the customer will be happy…. I made a lot of assumptions about how people felt about my work. Sometimes I assumed that everything was great, sometimes that everything was a mess. Sometimes I was right; I usually wasn’t.

Earlier this year I started participating in a leadership slack and heard time and time again how frustration and upsets were prevented through better communication and how a large part of that communication came in the way of feedback.

Fast-forward to now.

“Here’s the super-blammo tool. It should solve problem X that we were discussing based on the requirements A, B, and C that you’d noted. Give it a whirl and please let me know if there’s anything that can be improved.”

That minor change in phrasing has led to a significantly higher response rate. The same customers let me know (much sooner) if there was something that was unpleasant. On a more personally fulfilling level, they also let me know (much sooner) if they enjoyed my work!

Enjoy the gift, not the wrapping paper.

It’s important to note that receiving feedback is as mindful a process as giving it. You have to be fully present to parse out the different pieces:

• What are they telling me? They’re happy? They’re unhappy?
• How (un)happy are they? Is this major or minor?
• Are they suggesting a solution or merely stating a problem?

You might not like a person’s delivery, but the content is the important part. Let’s go with unhappiness. Someone is frustrated with [thing you did]. Why? If they’re not specific, ask them for specifics. If it’s not clear to you what problem [thing] is, ask for clarification. You cannot and should not expect all feedback to be explicit when it first arrives, but the conversation that you have about it will drive your relationship with that person.

“Mr Popular” by Jason Rogers is licensed under CC BY 2.0

Bob might come to you and say “I really hate how I get hourly alert e-mails about P1 bugs.”

OK, Bob, why?

“There are too many and I’ve found myself ignoring them. They’re useless.”

OK, Bob, that’s a good point. We still need an alerting system, but do you have a suggestion for improvement?

“Send an e-mail when the bug is created, but then only send e-mails if the bug hasn’t been updated in 3 or 4 hours, and only to the people who have to act on it.”

That sounds like a great improvement to improve our signal to noise ratio. Thanks for that feedback, Bob, I appreciate it!

Second, I started giving a lot more feedback, too.

Having those conversations isn’t easy.

In the old days, if I was irked by someone’s behavior or action (“Ugh, Bob checked in another broken build,” or “How many times can someone whistle the William Tell Overture in a row?”) I would turn that frustration inward. I’d put on my headphones, crank up some music, and try to distract myself from that frustration. I’d also find myself distancing myself socially from those irksome folks.

That doesn’t feel healthy for me.

These days, if someone committed yet another broken build, I’d talk to them about it. Maybe the tooling for building and testing the code before a commit is heinous. Maybe they weren’t onboarded properly and don’t know what impact they’re having on other people. Maybe they just want to watch the bits burn. There’s no way to know what someone’s motivation is before you ask them, though it helps to assume (I know, it’s a bad word) that they’re trying to do what’s right.

Having those conversations isn’t easy. It’s not fun to share with someone that you’re being negatively impacted by their behavior. You have to be vulnerable to them and you have to actively listen to what they say in response, but despite those hurdles, giving feedback is so worth it.

Since I started having those kinds of conversations with folks, I find myself more social with them than before. These are people I seek out for knowledge that, before those conversations,  I didn’t know they had. I also find myself being sought out more frequently by those folks. The feedback loop seems to breed community.

To be sure, there are bad ways to give negative feedback:

“Hey, stop whistling.”

“Don’t they teach you how to check in working code at [your school]?”

Likewise, you don’t want to sugarcoat it to the point that the actual feedback is lost:

“Does your throat ever get dry when you whistle?”

“Building code is the worst, right?”

My approach.

First, figure out how I would want to receive the feedback:

“Hey Matt, I noticed that your last few builds were broken. What are your thoughts about that?”

and

“Hey Matt, can you stop whistling in this shared space?”

Next, acknowledge that my audience is not me and figure out how they specifically want to receive feedback.

Lastly, know that I might be wrong about how they want to receive feedback and that it may take some work building a relationship with that person before they can completely hear my message. That’s OK. Like software, you can develop your people skills iteratively too! (See Kate Heddleston’s excellent presentation on this.)

Next, acknowledge that my audience is not me and figure out how they specifically want to receive feedback.

Don’t forget to remind people of success

“Thank You” by NY is licensed under CC BY-SA 3.0

I also started giving much more positive feedback. I mentioned to someone in IT how it would be cool if we had a better strategy for throttling network bandwidth to test high-latency conditions. That person found a tool, installed it, and presented it to me unbidden. That person was (and is) awesome, and I made sure to let them know how much I appreciated it.

Some of my code relied on another team’s code. I wanted to do X which required change Y in their code. I chatted with the owner of that code, offered to make the changes myself, and heard back: “Oh, we got this. It’ll be done later today.” Again, high appreciation.

This doesn’t have to be a mutual admiration society where what’s considered par for the course requires a shout-out, but I’ve been surprised at how happy I feel when I thank people for everything and when I let their managers know how happy I am with their reports’ work.

I see this as a bit of a feedback loop, too. If you receive continual recognition for good work, you have a good indicator of what you should be doing next. This sort of feedback serves three purposes for me:

1. It lets me show someone that I recognize their contribution; it’s so easy to keep my head down, plow through a ton of work, have some customers acknowledge that I exist but let others have no idea what I do. (This helps explain why I’ve seen “I don’t know, they’re cool?” in peer feedback responses for my reports.)
2. It lets me show someone that I value them; they’re not just a work delivery mechanism but a person who provides a valuable role on the team.
3. Selfishly, I like to receive good feedback. The more good feedback I give, I hope the more likely someone is to emulate me and give some back!

The best feedback is specific and timely.

I can’t emphasize this enough.

Sue derailed your strategy meeting with Star Wars spoilers.

DO:

In the meeting: redirect attention to the agenda, and away from Star Wars. Also emphatically note that spoilers aren’t cool.

Privately, that same day or week: let Sue know that it’s tough to get through the agenda in the time allotted as it is, that you would appreciate her helping you accomplish that goal.

Sue now has an opportunity to improve at the next meeting, and everyone on the team is assisted by the meeting being kept on schedule.

DO NOT:

In the meeting: let the clock run out and schedule a second meeting to accomplish the goal of the first, hoping that conditions will improve.

Privately: 8 months later during your annual performance review, and after 3 other similar occurrences, inform Sue that she is a distraction in meetings.

Sue doesn’t remember any specific meetings where she was distracting and although she understands the words coming out of her boss’s mouth, has a difficult time emotionally connecting to them. In which meetings is she distracting? All meetings? The last meeting? This performance review meeting?

The team is likewise annoyed with Sue who they see as that person who derails meetings, though no one will tell her.

My hopes for your feedback

• Be timely and direct. Big problems usually start out small before they snowball into a relationship or employment avalanche.
• Be specific, especially about negative issues. It’s harder to correct general problems, and trends tend to be based on individual data points. Use the data points.
• Give lots of it, both positive and negative. Let people know what you think: otherwise, they’re likely to make assumptions.
• Replace your anonymous peer review systems with conversations with your peers. Let their managers know about the good and the bad about their reports after you’ve told your peers. Your relationship with your peer cannot be improved by only giving feedback to their manager.

Speaking of feedback, what do you think about this post? Please let me know! Your feedback is a gift.