Recoilless Feedback
Put simply, recoilless feedback is feedback that does not make the recipient recoil whether that be in disgust or fear or similar emotions.
Imagine a very real situation, which you may have already or still do experience:
You're a software developer, excited to contribute to an application. You request a code review for something you're submitting, walk away, get a drink to refresh yourself, and come back to find a notification indicating you've received a completed review or comments.
Excitedly, you pull up the comments and… horror ensues. The person reviewing your code has left comments saying things that make your hair stand on end. You're left feeling underappreciated or, worse, targeted and belittled.
This is a situation we should avoid at all costs, particularly in professional settings. With few exceptions, feedback should be provided to those seeking it, or those who require it, in a way they can consume, manage, and learn from without undue effort.
In mechanical engineering, there is a concept of building something that is recoilless. Machines are designed to provide the same function, except without any recoil or destructive impact to the machine or the user of the machine. This prevents damage to the machine or user during regular and maintained use. The cool thing is that we can apply some concepts we already understand in software development to help make this happen for feedback.
To provide recoilless feedback we need to:
- Identify a clear problem
- Queue up the feedback in advance
- Analyze the problem together
We can treat these steps as if they were methods called in an IF statement.
function feedbackProvided () {
if ( problemIdentified && feedbackIsQueuedUp && analyzeProblemTogether ) {
return true
} else {
return false
}
}
Recoilless feedback if it was written as code
Like any other IF statement, a failure in any of these methods will short circuit the statement and cause us to stop the process. This is exactly what we should do in the real world. If we can't identify a clear problem, then we shouldn't queue up feedback. If we can't queue up feedback, then we shouldn't analyze the problem together.
Now that we have a general structure to our logic, let's dig into each of the steps to see how we implement them.
Identify a clear problem
AKA Figure out what needs to be fixed through your feedback
Ask yourself: what problem are you trying to solve through providing feedback? What is it that you want to see changed? It's difficult, even for those experienced with providing feedback, to do so without some kind of agenda or problem in mind. Determining whether an issue is fixed is also difficult when you can not clearly describe what the problem was in the first place.
So that's why defining a problem helps you to provide feedback, but how does this make your feedback more recoilless? Consider the following two pieces of feedback you might receive.
I just don't think you did a good job on that presentation.
Generic and unspecific feedback
You spoke very softly at times even though it was a large room and you only had data to back up about half of your claims.
Specific feedback pointing to two problems
The first piece of feedback is generic and points to no specific problem. The second piece of feedback defines clear, solvable issues with the work: the speaker wasn't loud enough and there were not enough pieces of data to back claims. If it feels like the solutions for the second piece of feedback are clear, then that is because it is a well defined problem!
Click here: Why you might stop at this step
Code reviews are a perfect place where we can apply this concept. Examples of specific problems in a code review include:
- bugs that you can identify
- lack of consistent code styles
- failing tests
- use of specific anti-patterns
These are all easy to check whether they've been fixed or not after a review. Does the bug still occur? Does the test succeed?
Less specific problems, however, can not be easily checked. Maybe someone detects a “code smell” or similar, poorly defined issue. It is easy to jump at those feelings and provide feedback in comments like, “this kind of smells,” but don't do it!
Instead, ask yourself more about what it is you might be smelling. Ask the contributor for more context. Ask your peers for their perspective. There may, in fact, be no problem to solve.
Queue up the feedback in advance
AKA Ask ahead of time if you can provide some feedback
Consent, in general, is an important concept to grok and respect. It is especially important to respect consent in situations where potential harm can be done to an individual whether it's intended or not. Providing feedback is one of those situations, so it is important we ask first if someone is prepared to receive feedback.
That's it. That's the tweet, so to speak.
It might seem like a foreign idea to some or it may seem perfectly normal, depending on your experience with permission and consent and hard conversations. Simply put, you're bringing some version of unexpected news or new information to someone and it is your responsibility to ensure they are ready and willing to receive that information first.
This might actually be the most important step here because it is also where the feeling of power can be given or taken away. Again, imagine an example where you just gave a presentation and afterwards someone either comes to your desk or sends you a Direct Message with one of the following:
Hey, I wanted to let you know that you didn't speak loudly enough or provide enough data points to back up your claims in that presentation.
Sudden, unprompted criticism
Hey, do you have a couple minutes for me to provide some feedback on your presentation?
A request to provide feedback
The first one follows our first point of using a clearly defined problem, but it still sucks to just have that show up in our DMs. Now imagine how freeing it is to respond to the latter with, “can you give me 5-10 minutes so I can grab a drink?” Like, thank you, but I will defer critical feedback for the moment so I can get some fucking coffee after that tiring presentation. This is the feeling we want to enable with recoilless feedback.
Click here: Why you might stop at this step
Have you ever been in a mood where you just weren't interested in hearing someone else's opinions? We have to allow for that or similar situations and feelings. Sometimes folks are just not ready or willing or interested in getting feedback. Sometimes folks have other things going on in their life that eats up the energy they'd otherwise use here.
If the recipient expresses or even implies they're not ready to hear feedback, then let them know that's ok and come back some other time. A simple, “Oh, that's ok!” goes a long way to show both of you that not every problem needs to be solved immediately and a lack of feedback in any one instance is not the end of the world.
After all, if a recipient doesn't receive feedback in a way they can learn or grow from then they are not nearly as likely to solve the problem you're describing. This is the step where you can demonstrate the most compassion towards someone so think hard about whether your feedback will actually help or hinder the recipient.
Analyze the problem together
AKA Talk about the work, the perception, and not the person
If we reach this step, then we have clearly defined a problem and received permission to share critical feedback with someone. We can still fuck up at this point though if we phrase that feedback poorly. It doesn't matter if you're prepared to receive criticism for something you did if someone tells you, “That sucked and no one liked what you did.”
Recoiling from feedback at this point would most likely take the form of the recipient becoming defensive in response to your criticism. We want the recipient of feedback to feel like they own the problem and can provide the solution to it. The closest situation we have to that in software development is probably a bug report.
Think about describing the problem in the way we might define a bug. A common template for bugs include defining:
- Reproduction steps or what happened
- A set of expected results
- A set of actual results
When the second half of the slides were displayed there were no data points attached to them. It seemed like this was done because the first half of the slides were full of data and the intent was to lessen the load of information for the team, but I think it actually came off as a lack of preparedness.
Feedback formatted similar to a bug report
If we frame how we provide criticism as a bug report then we end up 1) talking about the problem, 2) telling recipient we're trying to understand things from their perspective, 3) helping the recipient understand how their actions actually came off to other folks, and 4) giving the recipient the opportunity to identify the solution themselves.
Click here: Why you might stop at this step
The other positive outcome of having a conversation about the problem together is that your own take on the solution, intentions, or problem may be wrong. Presenting perspective to someone as a collaborator gives them the space to also help you to see blind spots and may lead you to find there is no problem to solve after all.
In the example above, a response to that feedback may be, “Oh, there wasn't actually any data for the latter half of the slides and I was trying to express that was part of the issue we should be solving.” This might indicate the overall message was not communicated clearly enough, a different issue, or maybe that you're the only one who perceived the lack of data as a lack of preparedness. This could lead you back to our first step of identifying a clear problem again or, simply, stopping here.
Summary
Problem -> Consent -> Collaboration
Simplified, these steps can be treated as a broadly applicable flywheel. Pick a problem, find someone willing to work on it, and collaborate towards the right solution. Using these steps in lots of different contexts can be really powerful, but we risk losing sight of how this process in the context of feedback to one person is different, so here are a few distinctions.
First, the problem identified is directly related to the recipient. Thinking of feedback as Problem, Consent, and Collaboration can be handy to recall or quickly communicate certain aspects of the process, but the shorthand should always be overridden by the compassion we have for the individual. We should always keep in mind the specific challenges they may be facing in their professional or personal life. Even framing points of feedback as a “problem” with the recipient can be potentially damaging if you don't consider how that framing can be perceived.
Second, consent is key and it can look like different things in different contexts. In a broad problem space, folks may give a kind of passive consent to work with each other on an issue because that is part of working together. In providing feedback, however, consent should always be explicit. If you ask a recipient whether you can provide some critical feedback and they respond passively or with a noncommittal statement, then consider if that is a sign you should pause and come back another time. When in doubt, ask or ask again.
Lastly, collaboration is a shorthand for a kind of ideal state of providing specific feedback. Collaboration during feedback requires time and trust and practice between two individuals. We talked about failing out early from each of these steps for different reasons, but all of those reasons are rooted in respecting the agency or boundaries of the recipient. This is because feedback, at the end of the day, is about helping someone else grow and it has to start with caring about that individual on some level. If you're trying to provide feedback to someone, but you really don't care about them or their progress then what the fuck are you doing?
Because it isn't providing feedback, I can tell you that.