The Big Idea

Reviews are a powerful tool for providing feedback. We have a tendency to prioritize action over thoughtful planning because “time is money”. But it is when we stop to listen to those around us that we are best informed on what the next move needs to be.

The ability to provide really helpful reviews is powerful tool in the CTO toolbox. We get to help the team deal with feedback when it doesn’t land well, or is open to misinterpretation. We get to facilitate conversation between different squads in our teams or individuals that work on different parts of our systems.

Equally important is the ability for your team to strengthen how they deal with feedback. The reason for actually doing reviews and sticking to them is that it trains your team on how to deal with feedback. How we deal with feedback drastically impacts the productivity of the development team.

Just like with any relationship, we should define the parameters for our reviews. Members of our teams all bring different constructs of what reviews should look like based on past experience. As CTO you get to create the criteria by which reviews need to happen.

While we often think of the most common reviews that Engineering teams do, code reviews, the truth is that any conversation that we have within or across teams can include a healthy dose of feedback. We want to ensure that we are building a culture that encourages healthy feedback and exemplifies what healthy feedback looks like.

This block focuses on internal reviews that happen within Product Engineering teams. We’ll discuss external and stakeholder feedback in the Feedback block.

What does a good review look like?

Productive feedback, often referred to as "constructive feedback", has several key attributes. All reviews that provide feedback should adhere to these tenets. To ensure that feedback is helpful and encourages growth and improvement, it should be:

  1. Specific and Detailed: Good feedback goes beyond mere platitudes. It should provide specific examples and actionable suggestions. For instance, instead of saying "your code needs improvement", one could say "consider refactoring this function to make it more readable and maintainable".
  2. Timely: Feedback should be provided close to the event or behavior it refers to. This ensures the details are fresh in the mind of both the giver and receiver of the feedback, making it more impactful and easier to act on.
  3. Balanced: While it's essential to point out areas of improvement, it's also important to highlight what's going well. This encourages the continuation of positive behaviors and reinforces a positive feedback culture.
  4. Focused on Behavior, Not the Person: Feedback should be about actions, not personal traits. This helps in preventing defensiveness and encourages change. For instance, instead of saying "you are disorganized", it's better to say "the code lacks organization in certain areas".
  5. Solution-Oriented: Feedback should aim at improvement and provide solutions or suggestions for change. It's not just about pointing out what's wrong, but also about helping to make it right.
  6. Honest and Open: Effective feedback requires honesty, but it should be delivered with tact and respect. The goal is to help the receiver improve, not to embarrass or demoralize them.
  7. Regular: Feedback should be an ongoing process, not a one-off event. Regular feedback helps build a culture of continuous improvement and helps individuals adapt and grow with changing needs and objectives.

By incorporating these attributes into the review process, a team can ensure a healthy feedback culture that fosters growth, improvement, and a positive work environment.

Where to incorporate Reviews

Creating many ways for reviews to occur within Product Engineering teams is crucial for the continuous improvement of products and the growth of the team. Here are some mechanisms that are specific to these teams:

  1. Design Reviews: Design reviews involve assessing the architecture and design of a system before it's implemented. This proactive feedback mechanism helps identify potential issues early on and ensures that the proposed design aligns with the overall system architecture and coding standards.