Scaling effective communication as a team grows is tough. We have found recently as our team has expanded to multiple sites that the remote element exacerbates this problem. I have decided to collate my thoughts on what effective feedback could look like, with the hope that this will be useful for anyone who works with any number of other people to build a shared product.
I won’t go too far into the merits of feedback in the building process, hopefully if you are reading this you will already understand its importance. Also examples will be from github but the principles should apply to any tool used by your team.
Asking for feedback
Asking for feedback is very important. Firstly, if you don’t ask, it’s much less likely you will receive it; and secondly, asking allows you to control the process. Controlling the feedback will help you benefit the most from it.
When asking for feedback it’s important to consider:
- When do you want the feedback
- What, specifically, you want feedback on
- What stage the work is at
I think we’ve all suffered at some point from the fear of sharing our work with others, there have been many studies done on this phenomenon. It’s better to focus on what you want to achieve from the process. Think about the collective end goal for the product and not what people may or may not think about your work. Shared products belong to the whole team and the quality of the work is everyone’s concern.
Submitting a pull request or a request for thoughts with no information other than the title of the task is of little use to any potential reviewer – Something I have clearly been guilty of in the past.
It’s far more helpful to describe the stage of work and what you want feedback on, such as ‘work in progress – ready to have eyes on the structure’. It can also be useful to specify and tag the peers you want feedback from. Engaging with the people you want to hear from will greatly improve the likelihood that you will benefit from the process.
We have implemented a system that a pull request is created as soon as a task is started and the information of the current state of the task is kept up to date. This allows you to have eyes on the task at any stage, even if you are not yet ready for feedback and you just want peers to follow the progress.
Giving feedback is a challenge and it’s something we should all work to improve. Remember, the quality of the work that the team is producing is everyone’s responsibility, and feedback is a huge part of that of that process.
Everything should come back to two words: empathy and critique.
Putting your work out for your peers leaves you vulnerable as you wait to hear what your colleagues feel about your work. Before you begin to comment on other people’s work, time should be taken to consider:
- what stage it is at
- how they have described the solution
- what they may have been thinking at the time
Make sure you have in your mind how you want the person to feel once they have read it and what actions you want them to take.
Negative language should not form part of the feedback process. You should be looking at all times to offer critique and not criticism. Phrases such as these should be totally avoided:
- Never do this
- That is stupid
- You are doing it wrong
Instead we should be looking for positive reinforcement:
- I like how you have done this, how would it look if we changed this part to do this instead?
- Are there any performance implications if we do it this way instead of this way?
Giving good feedback is a time consuming process. It’s frustrating for both parties to give or receive feedback at the wrong time, or about the wrong thing. Make sure you understand the stage of the work and what feedback has been requested before you start. There is no point in critiquing the code standards or fine details if an overview look has been requested at an early stage. Likewise, feedback when something is ready for live should require a fine-tooth comb review. If it isn’t clear what stage the work is at, make sure you ask for clarification.
The review stage of the work should be considered to be a conversation. Suggesting that work looks fine if you don’t understand what it is doing can be harmful. Ask questions about what the goals are or how something is supposed to work.
Good feedback will also cover the implementation of the work and consider how it fits in with the bigger picture based on the context of what the work is supposed to achieve. You should always have the end goal of the project in mind. It won’t just refer to actual lines of code/minor tweaks that the change consists of.
You will come across work that should be changed to adhere to style guidelines or coding standards. When picking up on these, clearly explain the reason why something should be changed.
Responding to Feedback
Reading someone else’s critique of your work can be difficult, but remember it is not about you, it is about the quality of the shared product.
Make sure you step back from the responses and you are really hearing the feedback you have been given. When you respond, keep it in reference to the end goal of the project.
Always respond with gratitude; someone has taken their time to help you in some way. As above, make sure you ask for clarification if you don’t understand a piece of feedback. If a situation arises where confusion or disagreements occur, step away from the written word and switch to a more direct communication channel to resolve.
This is a blog I have been meaning to write since seeing Keavy McMinn’s excellent talk “Better Work Through Better Feedback” at hybridconf 2015. A huge amount of what you read here is directly influenced by her.