Non-Blocking Feedback
Some of the best and most productive engineers I have met were folks who could effectively address blocking feedback or treat feedback as input instead of an obligation. In other words, if they find the feedback useful, they will use it. Nonetheless, feedback that blocks work is seen almost everywhere within an organization, either culturally or due to lack of efficient processes. Let me give you a few examples.
Blocking pull request reviews
When I google for “non-blocking feedback”, what I generally get in my first top five research results are things related to code reviews. If you gel with your colleagues or you work on a shared project, you will usually get very quick and reasonable feedback on code reviews. Nonetheless, in my experience, if you’re new to the team, or work on separate projects, or on someone else’s codebase, you might find that it takes days to get your pull request reviewed even when code changes are small and inconsequential. This feedback cycle when writing code is very disruptive since it effectively blocks execution.
Architecture Review
You write a request for comments (RFC) or a project proposal; usually, if the project is big enough, it might be reviewed at an Architecture Council. Folks in very senior positions, like Staff or Principal, are generally primed to give feedback and sometimes get evaluated based on their ability to drive change through feedback. Therefore you might also get a lot of inessential comments on the API contract, database schema, and choice of technology. You look at all the comments and as you try to incorporate them, you realize that your project is getting bloated in scope and complexity, and you wish you could feel more comfortable saying no.
Why is feedback blocking?
I usually find that there are two reasons why feedback is blocking. One is procedural, which is not dedicating effort to designing policies that improve workflows. The other is cultural, which often happens in situations where there is a power imbalance between roles.
One business day is the maximum time it should take to respond to a code review request (i.e., first thing the next morning). — Google Code Review Guidelines
- Procedural: The first reason why feedback is perceived as blocking is not having clear policies in place that streamline the feedback loop. Google has a code review policy that requires a maximum of one day time to respond to code reviews and some organizations measure that in hours. The lack of policies means that the speed and the quality of the feedback are often driven by more subjective factors like how well colleagues like or know each other.
- Cultural: The second is because of cultural norms. You might naturally not want to offend folks more senior than you. For example, imagine the uncomfortable feeling of ignoring the advice your manager gives you on a project or going against the wishes of a principal engineer on the architecture council. You might have a very legitimate reason for saying no, but might not be as articulate in your arguments, or not willing to rock the boat, so you end up with feedback that blocks you from executing.
How to alleviate blocking feedback?
Procedural feedback is usually easier to fix since it involves writing a policy and designing an enforcement mechanism that feeds into a performance review. For example, RFCs that get circulated in a public setting might come with a time limit for giving feedback. If no feedback is provided, this means that there is silent agreement that the work should proceed as planned instead of being blocked in limbo.
The bigger challenge is fixing cultural blockers, where you have difficulties managing upwards or saying no. I generally find the following things useful:
- Feedback should be non-blocking by default: if you’re in a position of seniority, the first thing you can do when someone joins your team is to be very clear that all feedback you provide is optional and can be ignored by default. You trust that your colleague is competent and that they are the most informed person in the room when it comes to the execution and planning of their projects. When feedback is non-optional, you will clearly communicate so. In Architecture Council, you could adopt a similar philosophy by mentioning that the person who wrote the document is free to ignore suggestions unless they go against existing policies or when the majority of attendees think the proposal is a bad idea.
- Performance mechanism: the second way you can encourage folks to push through blocking feedback is by communicating very clearly that it is better to have an imperfect project fully executed than a perfect project that only exists on paper. Most projects tend to be evolutionary. I expect an engineer to work iteratively, learn how customers behave, and then continue pushing features while optimizing their architecture. Moreover, I expect a lot of learning to happen during the execution process that the original architecture specs missed. Communicating very clearly to the engineer that execution trumps perfect planning can nudge them to be more selective in how they integrate feedback and gives them an incentive to say no.
- Escalate: Although I would like to believe that I can resolve all blockers on my own, in practice, I find that it is more efficient to escalate to my manager and partner with them in finding a solution. Unfortunately, the more senior you are, the more likely you might find yourself not wanting to escalate because you might think this reflects negatively on you. For example, you might be afraid that failure to resolve blockers might be perceived as a sign of poor communication or lack of independence. Personally, I think it is more productive to just have an open line of communication and let my manager know through 1:1 docs about any potential difficulties. For example, I might leave a note as follows in our syncs: “For project X, I’m seeing some blockers related to Y from team Z. I will try to resolve them on my own, but I’ll get back to you if I can’t make progress.” This way my manager is always in the loop and can also create a organizational mental model about teams or individuals that act as gate-keepers and prevent the organization from being successful.
Ignore feedback at your own risk
A consistent pattern of not following or incorporating feedback is also detrimental. At some point, folks are going to notice that there is no point in providing feedback because it gets ignored. Moreover, a lot of genuine feedback you get on projects is something that elevates the quality and performance, decreases complexity, and improves impact. Feedback is a gift and should ultimately be appreciated and balanced with your execution needs.