Skip to content
Home » Blog Posts » Fresh feedback is finest

Fresh feedback is finest

The longer it takes for feedback, the less useful it is.

As we build our thing with our team we should expect to make mistakes. This is normal. No one does something well when learning. We make mistakes and learn from them. We also learn more from mistakes, than if we didn’t make mistakes. This means we need feedback on our team collaboration.

Any feedback on our work is useful. Even ‘I don’t like it’ is useful. This is an opportunity for a conversation. What don’t they like about it? What’s confusing them?

What would make it better? There are so many things that could be asked.

Maybe there is a misunderstanding. You were trying to do one thing, but people using it miss something important.  Or, maybe the team misunderstood what the client was wanting. This feedback an opportunity to sort out the issues. 

Feedback is essential 

We always need feedback. It helps confirm that we’re achieving our goals. We want to know that we’re on the right path for our work. Plus, we also want to know that we’re building it right. This suggests two types of feedback. 

We need feedback from the people who will use what we’re building. They will validate our assumptions about what we’re building. We should be showing them prototypes, as well as other work. They can stop us from building the wrong thing. On a good day, showing them a paper prototype will stop us from doing unnecessary work too. 

Feedback on how we do our work is also important. These are tests for the code, and discussion with team members about the work. Here a good day is pairing or mobbing so that work is seen and discussed as it is being done. Again, it prevents the wrong code from being written. After that tests and then merging code will provide feedback on the work. 

Sooner is better than later 

In both types of feedback fresher feedback is finest. Show people the scrappy first version. Pair on your work. Push your code often to the repo. The sooner people can point out that we made a mistake, the sooner it is fixed. 

Be humble, assume you made a mistake, and you’ll handle the feedback better than if you assume it is perfect. If you strive for perfect, then you’re less likely to show your work at an early stage to people. When you strive for perfect, you take too long. Show your work when it is ‘good enough for now’.

Guide your people to share their work early

Provide them with examples to show that sharing prototypes on paper is better than waiting for a running version. Point out that they are not the expert on the app, as they are probably not the person, who’ll use it after release. This means finding people who’ll use it. Show them how to do this.

Teach them the value of testing from the start of their work. Point out that pairing and mobbing help spread knowledge in the team, which is also a form of feedback on what they need to learn.

Show them how to shift left to speed up feedback.


This post is part of a project pulling together my materials and ideas about Teaching Team Collaboration: the Human-Side of Software Development for software development to students.

If you’d like to be notified of future posts, then please sign up for more using the adjacent form. When you sign up, then I’ll send you a free copy of the collaboration rules as a PDF from the book. You can also follow me on LinkedIn

The ideas above are from my book 101+ Ideas to Improve Team Collaboration, which covers all of these little things that students can do to improve their collaboration. Also available via Kindle.

Cookie Consent with Real Cookie Banner