R&D organizations nowadays have lots of different types of reviews, appraisals, evaluations, and assessments. It starts with the low-level code-reviews (commonly known as “pull requests” more often than not), reaches higher technical aspects such as The Architecture Review (capitalized, of course) and even performance reviews. These reviews are not meant to be treated like reviews on Rotten Tomatoes. If you just go through them, shrug, and move on – why did you even bother?
If, as the person presenting the review, you often leave reviews in the same state you went into them, you’re suffering from idempotent reviews. You can keep reviewing again and again, but your plans, code, etc. are not changed as a result. We know better than to waste a week “optimizing” if at the end there’s no apparent gain. Similarly, why spend time preparing for, going through, and then summarizing a review if it changed nothing?
As part of my overall war against useless meetings, these are some of the trickiest to spot. After all, sometimes people who were don’t get any actual feedback that requires changes see it as a win – they did good. But have they?
Reasons you’re suffering from idempotent reviews and how to tackle it:
- You prepared way too much: I’ve seen managers who insist on having every possible document present, every question that can possibly be asked already answered, and so on. If you over-prepare, it might indicate too much insecurity or mistrust in the organization. This is wasteful instead of helpful. Just like over-engineering, over-preparation is useless work.
- You are not talking at the same level: Lack of actionable feedback might be because you’re not providing the reviewer with things relevant to their role. The CTO (hopefully) doesn’t care about class names. Not all developers will want to opine on your data modeling. Tailor the review appropriately.
- It’s more a committee than a review: There are too many people present, each chiming in with their own 2 cents, yet not coming up with anything actionable. Useless. Invite fewer people, even at the cost of holding several reviews, and act as a facilitator – rants that do not move you forward should be stopped.
- Bad process: If you send an invite for a review and then present documents during the meeting, you’re effectively wasting everyone’s time. Provide them with the ability to let it soak and prepare. Send materials in advance, make sure everyone goes over it prior to the actual meeting. The meeting shouldn’t include going over documents unless it’s to point out an issue.
- Lack of trust: An organization with culture problems cannot efficiently produce candid feedback, and especially reviews. When someone has low trust, they are not likely to speak up their mind, especially if it’s against the prevailing opinion. What you end up with are rubber-stamping reviews.
Remember the rule: reviews without action items are wasted reviews. Whenever you suffer from one, review the review. Understand which of the above causes was involved. Address it.
Get a sample chapter
Get the best newsletter for tech executives online, along with a free sample chapter of The Tech Executive Operating System 📖. Tailored for your daily work. Weekly, short, and packed with exclusive insights.