Guidelines for giving and requesting feedback

One of our values at B12 is to default to open. We practice this value in many ways from building open source software, to writing blog posts like these, to sharing work in progress. In an effort to increase transparency and cross-team collaboration, we recently set up a weekly meeting where we come together to share work in progress in a low-key supportive environment.

While the presenters in this weekly meeting are usually designers, product managers, or engineers, the event is open to the entire company because we believe sharing work and gathering feedback is good for everyone. In the couple weeks that we’ve had this meeting running, it’s helped develop an awareness of what’s going on across teams, given people the opportunity to practice their presentation skills, created learning opportunities, and leveraged the different perspectives people across the company bring — which ultimately all lead to better outcomes for our work.

The meetings also showed us that giving and requesting feedback doesn’t come naturally to everyone. It’s a skill that needs to be practiced regularly if you want to reap the full benefits. Thankfully another value we have at B12 is that we grow as one team and so we worked together to create some guidelines that will help people get there quicker.

Getting into the right mindset

As a primer, I always like to share the retrospective prime directive, to remind everyone that we’re all coming at this with the best of intentions:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

— Retrospective prime directive

Giving feedback

• If you’re looking at something that’s customer-facing, try to look at the work as if you’re someone that’s using the product. You can start your feedback with “As a user…”. This can help with focusing on the problems rather than the solutions.

• Giving feedback isn’t only about sharing what’s wrong — it’s also important to share what’s working well.

• Be precise. Don’t just say something is good or bad, try to explain why it’s good or bad.

• Avoid the shit sandwich (wrapping negative feedback with positive feedback) because it sends mixed messages.

• Unless you’re asked, try to stay away from providing solutions. It’s better to focus on the problem and articulating it as best as possible.

• Try looking at the work within the bigger context of our product. Has something like this already been done? Have we solved this problem in another way we can leverage and get this work out quicker?

Requesting feedback

• Start by giving context. Share a brief description of the problem you’re solving, the goals or outcomes you’re trying to achieve, and what stage of the process you’re in.

• Share the type of feedback you’re looking for along with what you’re not looking for. In the early stages of a project, you might not be ready for people to nitpick on the little details. Let them know you’re in that stage and you don’t need that kind of feedback just yet.

• Always assume positive intent and never take the feedback personally. People are not criticizing you as a person, they’re providing you input for your work to make it better.

• Don’t wait to get feedback. Ask early and often. Leverage asynchronous methods to collect feedback if you’re more than a day away from a synchronous feedback session.

If you are sharing work asynchronously, here are some additional tips to keep in mind:

• Share a timeline for when you need feedback.

• Make the work you’re sharing accessible. If you share a video, provide written notes and make sure your files are easy to navigate.

That’s a wrap

Thanks for taking the time to read this post. We’re always looking for ways to improve, so if you have any suggestions to add or improve our guidelines, we’d love to hear them!