This post is part of a blog series called Leveling Up: A Guide for Programmers. The series covers skills you can use to learn faster, more easily, and more strategically as a programmer.
This is the second part in a three-part discussion of giving feedback:
- Evaluating Whether to Give Feedback
- Identifying Safe Opportunities for Feedback (this post)
- Framing Feedback
In the last post, we talked about the benefits and risks of giving feedback. We ended with a question: how do we put ourselves in the best position to give feedback when it will be well-received—or at least received in a way that won’t hurt us?
Identifying Safe Opportunities for Feedback
We’ve established that we, the feedback givers, do not have full control over how our feedback is received. So before we talk about how to give feedback, we need to talk about when to give feedback and to whom to give feedback.
When is it safe to give feedback directly to the person or organization we want to help?
This seems like the best option, right? Help someone get better, give them the chance to fix it even if no one else has noticed, and they’re the only ones who know you ever brought it up at all. In theory, this is the least damaging way to give feedback…for the recipient. But that theory doesn’t take into account the blowback to you, as we’ve discussed. So I have pretty strict rules about when I give feedback directly like this.
Rule Number 1: I no longer give feedback directly to a person unless they are explicitly asking me for it.
I stopped doing this because it has never turned out the way I wanted it to. Usually the recipient gets upset or doesn’t act on the feedback. Sometimes it’s both. And to salt the would, I have been branded from giving this feedback as “abrasive” and “aggressive”, even on occasions when I spent days beforehand practicing the feedback in the mirror to make it sound as gentle as possible.
For example, I worked at a company with a six person product management team. We were looking to grow, and the director tasked two of the PMs with building a system for us to recruit, evaluate, and hire PM candidates. Those two PMs, Dan and Scott, were both cisgender straight thirty-something white men. The PM team they represented, by contrast, already represented a larger spectrum of diversity than that. It encompassed both men and women, LGBT folks, black and latinx PMs, and ranged in age from twenty-somethings to forty-somethings. We had both military veterans and parents on the team.
I arranged to be grabbing a coffee in the office kitchen at the same time as Dan and Scott, and I chatted them up. I spoke in the offhand, friendly way I had practiced for days in the mirror: about the importance of their roles as designers of the PM pipeline, about the importance of diversity on the PM team, about what heroes they could be by including other PMs in the process instead of orchestrating the entire thing themselves. They seemed friendly and receptive.
Next thing I knew I had a Letter of Concern on my desk that listed the incident as an example of my “abrasiveness.” I’m planning on publishing that Letter of Concern in full on this blog one day ;).
The point: the how is irrelevant when the when or the to whom are wrong. This is especially true for marginalized groups who are traditionally expected to shut up and serve.
Rule Number 2: Sometimes I don’t give feedback directly to a person even when they are asking me for it.
I don’t give feedback even when someone is asking me for it because they might not be asking me for feedback, in general. They might be asking me for a specific kind of feedback: validation. If what they want is validation, I give them validation. I see this as an opportunity to strengthen my relationship with this person, and I validate their work in the highest terms that I authentically can.
How can I tell if what they’re looking for is validation?
Sometimes they volunteer this information.
“Chelsea, how badass is this model abstraction?”
“It’s badass, Jim. Bad. Ass.” (In this example Jim’s abstraction really was badass).
What if they don’t volunteer the information? I ask them—but I do it indirectly.
How would you self-assess this effort?
If their self-assessment is “This thing is awesome, I’m pretty proud of it,” they’re probably looking for me to validate their work. And there’s nothing wrong with that! It is perfectly natural and acceptable to be proud of something and to want other people to agree that it’s great. I do this myself. When I publish a blog post that I was afraid to write like this one or this one, I want to be validated on my courage in writing it. I have communities where I can go to ask for that validation. I am happy to be part of that community for other people, too.
How a self-assessment could sound if someone is really asking for feedback: “I’m happy with the modularity of the architecture because I think that it would allow us to add features easily. That said, I wish I had a better way to test the dependency injection—I do this thing, but it has this drawback, and I wish I had a way around that. I also think we have a performance risk here that we’ll need to mitigate moving forward.”
This person is much more likely to want my feedback about this thing. They have already critically evaluated the impact of their work. I know that making it better is important to them. That means that, when I give feedback, we are sharing a common goal of making things better.*
* There is one nuance to the distinction between feedback and validation that we’re saving for a future post. In the meantime, the examples above can suffice.
What can we do when it’s not safe to give feedback directly to the person or organization we want to help?
If someone does not specifically want to do well in an area where I think it’s important that they improve, I don’t give the feedback directly to them. Instead, I give it over them.
I go to my manager with this feedback. Or, if I don’t trust my manager to relay the feedback, I go to my manager’s manager or the person’s manager with the feedback. The person’s manager, unlike me, is someone upon whom this person depends because the manager is responsible for helping them get raises and promotions (or at least stay employed). For that reason, negative feedback given down the chain of command tends to be better received than the same feedback across or up the chain of command.
Sometimes I have a valid concern that the manager will think this is not a big deal, and bringing it up will get me labeled as “hypersensitive” (another term that tends to block promotions). In these cases, when things happen that I want to bring up but I worry will be considered “not a big deal” on their own, I don’t bring them up right away. Instead I record each incident’s date and details, as well as the names of anyone else who can corroborate my account. I save this record, and I bring it to a manager when I have at least three incidents of the same type. After that, if it keeps happening, I keep bringing up the incidents one by one. The pattern has been established now. My feedback is on the continuation of a pattern, not an individual incident.
Once my feedback is with a manager, I consider my responsibility fulfilled. If their manager decides to do nothing, then maybe this organization does not align with my values. When I see a persistent pattern of this I look to leave the organization. I don’t hang around trying to change people anymore.
What if it’s not safe to give feedback to an organization, rather than a person? It’s common for leadership at a company to ask for feedback from individual contributors that they don’t really want. Brigette Hyacinth recently articulated a really helpful example of this on LinkedIn.
Why would leadership do this? They theoretically want to be seen as the kind of leaders that ask for that feedback, but they don’t want to actually have it pointed out that something needs to change. I have seen this repeatedly with feedback about inclusion. It’s not something on which the company wants to do hard, hard work: they want to be perceived as good at it without doing hard, hard work. And inclusion work is hard, hard work. So it’s easier to just push out the contributor who brought up the inclusion issue. There must be no complaints if no one’s complaining!
In this case, there might be an over-their-head place you can go. Maybe a board of directors or someone in the C-suite who shares your values. If neither of those work, my remaining options for you are:
- Organize. Reverse the chain of dependency by having lots of individual contributors collectively demand a change. The organization doesn’t depend on any one programmer, but it does depend on the entire staff as a unit. So if something really absolutely must be done, collective action gives you an opportunity to demand that.
- Leave the organization, if you have the privilege to do so.
Those options both have large repercussions. So you have a choice to make with this feedback: escalate (by going to a board member, a C-suite exec, or organizing), or disengage (by leaving the organization or keeping your feedback to yourself). Which of these options you choose depends on how important this feedback is to you. If there’s a low chance that an organization will act on my feedback, I usually keep it to myself and leave later.
Conclusion
Giving feedback can result in negative consequences for me, regardless of how I give the feedback. So before I give feedback, I evaluate my safety.
First of all, I don’t give feedback directly to someone unless they have explicitly asked me for it. Even if they have explicitly asked for it, I make sure that what they’re asking for is feedback and not validation. Sometimes I can tell which one it is. If I can’t tell, I first ask them to self-evaluate before I provide an evaluation of my own. If their self-evaluation is purely congratulatory, then I congratulate them. If their self-evaluation contains meaningful critique, then I trust that they’re looking to improve and I support that goal with feedback.
If at any point these checks fail, then I am not safe giving this feedback directly. At that point, I evaluate whether I really need to give it. It might be better for me to just keep my mouth shut. If it is very important to me that this feedback be addressed (for example, if it is harassment or a pattern of exclusionary behavior), I go over the person’s head to my manager or to their manager.
This doesn’t work as well for organizations because it’s hard to go over an entire organization‘s head. It might be done by going to a board member or C-suite exec, or it might be done with collective action. There are cases where this works, and they are wonderful. My personal experience doesn’t happen to include them. Usually when I’m faced with this situation, I keep my mouth shut and make plans to leave the organization.
Now we have talked about when and to whom to give feedback. In the next post, we’ll return to the question of how to give feedback.
If you enjoyed this piece on when to give feedback, you might also like:
The rest of the leveling up series