7 Gotchas & Fixes for Accidentally Crap Feedback
Technical reviews can be a shockingly emotional process. They can feel like the most rewarding parts of our day, compressing years of experience into appreciated nuggets accelerating the next generation’s technical prowess. Or they can be surprisingly fraught sessions crushing people’s hopes and egos. No matter how a review session goes down, we owe providing technical feedback at least at a minimum quality level to those who go out on a limb with their most vulnerable selves at the most impressionable points of their projects. When is feedback below an acceptable quality bar? Here’s the 7 most common traps to accidentally delivering crap technical feedback I’ve seen… and of course, fixes.
Overfitting – Incomplete Feedback – Correct but Unimportant – Speaking Klingon – Mismatch of Comm Channel and Importance – Timing Mismatch – Disheartening
Overfitting. With the rapid growth of tech, review boards commonly have junior folks with one big wonderful project under their belt. For these folks, it’s tempting to immediately feel valuable and knowledgeable by overfitting every project being reviewed to their previous success. It’ll follow something along the lines of ‘Oh! I’ve seen your problem before. I solved the exact same problem in this manner. You should solve it exactly the way I solved my problem.’ Oddly enough, this type of feedback frequently comes from not just junior folks but professors vacationing from academia as well. Don’t get me wrong, there is information to be provided here, but it needs a bit of help to get above the minimum quality bar for feedback. As phrased, the example feedback destroys the ownership and decision making power of the folks being reviewed, potentially preventing them from considering the valuable information. A better approach would be ‘Do you see this as a problem in your project? If so, I worked on a project with commonalities xyz and one option for solving this problem is A.’ Now the project owners can own the next steps in their project with a much better connection of your advice to where it might be helpful.
Incomplete Feedback. I find this to be a common trap for senior folks. Senior folks often sit in meeting after meeting after meeting after meeting…, regardless of where they fall on the introvert to extrovert spectrum. For folks not recharged in meetings, by their 6th meeting of the day the input is often terse. Complete technical feedback needs 3 components of varying depth, but always 3: tagline, why, and how. The tagline is so project owners can remember, refer to, and prioritize incorporating valuable feedback. The why, as senior folks we love to skip this assuming why is self evident, but this is often the most critical part. The why at the project review stage often involves the linking of theoretical company priorities down to a practical component. For example, if there is no downside, consider providing the feedback of updating batches to run not daily but weekly. If in a review session that is left as a comment, the best case is one batch is updated. With the why missing, the reasoning of that feedback is unlikely to be applied on a daily basis to the other batches being created and that is a huge missed opportunity. Attaching the why that the tweak is an 86% reduction in ongoing compute costs and helps protect the company margin, suddenly helps project owners think in a manner that connects a high level company priority to their day to day work. Finally, the how. If you get through the tagline and the why, it’s so tempting to bow out with a ‘Google it.’ Well, you can’t find it on Google. How much industry knowledge is taught at exactly this stage of the feedback and never shared in classes, blogs, or papers is amazing! Take the time to write the equation, link to a github PR, or write a skeleton, and make sure the how is communicated at a level of detail folks can make those changes, if they prioritize your feedback. Rarely, a how is unknown. If so, the unknown should be escalated as a severe risk point in a project. And yes, each one of these feedback gotchas will have a tagline, why, and how component ??
Correct but Unimportant. Not every problem needs to be fixed…..it’s so tempting to show off our knowledge and abilities to fix problems we understand, but if they’re irrelevant, best leave the showboating for SXSW. There’s a certain speed that needs to be maintained in tech, specifically at the cost of not everything is going to be perfect or even sometimes great. What will make a difference to the project’s success should be strong, but perfecting the rest of a project can doom it faster than anything else. The best insurance for avoiding this type of feedback is to invest in understanding the goals, context, and definition of success before even evaluating a project. Then, filter the feedback you want to provide with goals, context, and success in mind. Sure, sometimes there’s still that itch to encourage improvement in craftsmanship, just leave it as a comment with a /nit or ‘for future projects consider’ note.
Speaking Klingon. If it hasn’t become apparent by now and you're still with me - providing feedback is a skill. One of the first skills to learn is how to speak in a way that’s heard. If you’re taking the time to provide a review - you have knowledge, perspective, or energy to share! They have a project that needs to succeed. Matching the two is incredibly valuable and involves an idea hopping from one brain to another. No hop, no value. Ideas can only successfully hop brains when the words spoken can be interpreted by the receiving brain. Obvious. If in a review you start to notice one person’s feedback is either met by dead silence or by tedious rounds of clarifications, then there’s a risk the reviewer might be speaking Klingon and the project owners want to move on. No hop, no match, no value. I bet this paragraph was painful to read and a bit Klingony. Cutting to the chase, the best way to protect against ‘Speaking Klingon’ which defeats the purpose of providing feedback is to periodically stop and ask project owners for feedback on your feedback. Make sure to ask detailed questions around what feedback was acted on and what could be improved on clarity and support for acting on that feedback? Oftentimes, after junior reviewers hear none of their feedback is being acted on, they naturally work on improving their delivery of feedback.
Mismatch of Comm Channel and Importance. People naturally weigh the feedback they hear in person heavier than the feedback they see in Google comments. When reviewing a project for the first time in person, it is tempting to jump in on the well understood areas of feedback, get your feet wet and then build up to larger feedback. Unfortunately, this leads to running out of time and the important feedback being sent over via comments on docs, PRs, or hard to understand Slack messages. Prioritizing ‘Marquee Feedback’ (or ‘P0 Feedback’ depending on your terminology) for in person sessions and closing the meeting with an explicit ‘did we cover everyone’s marquee feedback?’ helps project owners have a clear understanding of what the most pressing feedback is and whether or not they have a complete list of must know feedback items. Another tactic for efficiently steering in person review committees is if folks are exploring what could be better at the weed level is to reground in the goals/context/definition of success and ask ‘what are the risk points that would keep this project from succeeding?’
领英推荐
Timing Mismatch. We’ve all been there. While trying to take a victory lap for your ground breaking, spectacularly hard, and soon to be award winning project, the most senior person in the room announces ‘You should have done it this way. Your work doesn’t matter until you fix it.’ And of course, it was a solvable problem, IF the feedback had been provided at the right stage. Well timed feedback is a key reward of well designed review processes. Projects march steadily through differently named but invariably similar stages: prioritization, resourcing, scoping, architecting, executing, iterating, concluding, releasing. If feedback impacting the scoping stage is provided when the project is at the executing stage, it’s like through a wrench in the gears and asking an antiquated steam engine to reverse uphill. It’s much more efficient to match the feedback to the current project’s stage with maybe just a bit of foreshadowing to the next stage, but not so far in the future it’s irrelevant.
Disheartening. The worst feedback stops good projects in their tracks, not from a prioritization perspective, but from a perspective of destroying the will and motivation of project owners. For some reviewers, it’s like they keep a victory tally of projects they’ve crushed…or worse the number of times they’ve crushed a specific person. Fortunately, I’ve seen this type of behavior being weeded out of Silicon Valley, as the toxic venom that it is. But all the same, even with good intentions it is possible to accidentally be disheartening with feedback. It’s tempting to be efficient and implicitly optimize a feedback to action ratio metric. But that’s not the North Star of providing feedback! The purpose of review sessions is to increase a project’s chances for success. Happily, providing positive feedback of what is going well and why it’ll be necessary for the project’s success helps drive that North Star. If too much negative feedback is given, project owners may pull resources or effort from what is going well in order to manage the needs work feedback areas. This shift of resources may inadvertently lead to the project not having the strength to succeed. Taking the time to see why a project might succeed and what is already going well in creating that success provides great reinforcement for project owners. For the projects where nothing is going well, consider offering perspective on why this project is hard, prioritization of what needs to be solved, and solidarity in ‘the struggle.’
Going Forward
So what does good feedback look like? Ha. How things can go right is often a much shorter list than how things can go wrong. Here’s the shorter how feedback can go well list ??
Great feedback also:
World Class feedback additionally: