It is a mixed blessing to have multiple folks pinging for my attention at the same time. On the one hand it suggests that I am viewed as an asset to the community, but on the other it can wreck my basic productivity as I try to keep up with the daily work of code reviews and testing, and sometimes even writing code.
I had a moment this week where I was working with three different people at the same time, spanning three different project teams. The conversations lasted from approximately five and twenty minutes each with significant overlap. One involved spot checking a change, another involved call trace analysis, and the third involved a failure without a clear place to begin diagnosing. The context switching was a challenge, but I am getting better at that over time. That becomes a key bit:
Context switching is a skill, and we can improve with practice.
I don't know what the greater cost of that practice is however. Obviously, that is the enough of a disruption to break any sense of flow but does it take longer to get back into the groove after a longer context switching event than from a 5 minute context switch? How about adding two new contexts? I'm not sure it matters, in my case.
The value of getting three other folks overcome their barriers is likely to be significantly more valuable than the alternative. This is something that has become easier for me to see over time. First, I know I don't work at anything like 10x what my peers do. Secondly, the value of having progress on multiple fronts at the same time is far more valuable to OpenStack than having one fix merged faster.
Part of that is due to OpenStack having 2 releases per year, and the operator community tending to trail well behing the latest release of OpenStack. It's not like this bug fix or feature work is going to actually get widely deployed faster simply because it was merged one day earlier. Secondly, OpenStack is huge and complex, which means one feature or fix is not likely to have a large impact.
No, in this context, the greater value is to unblock three other people, who can then build their understanding and in turn pass that on to others who follow. The superior outcome is to hedge our efforts across many features and bugs and those which make the cut for the next release will stand collectively. So I accept the interruptions without reservation.
I'll acknowledge right away that I'm placing value on marking achievements. A record of achievement can lead to opportunities to work on new and interesting problems, the chance to bump your pay, or another way to impress your dog when you get home from work, but importantly it feels good to be recognized. It can be better than having a birthday to lay down a marker showing the distance travelled or to celebrate a new mastery and it can be comforting to reflect with others along the way to solving a challenge even if the desired solution still eludes. Sometimes we won't be able to see an achievement in the moment but a performance review can provide a means to recognize gradual change and protracted efforts as well as recalling the incremental achievements along the way.
I'd like to contrast this idea with SMART Goals _ which are commonly used in performance reviews. This can contrast with OKRs _ or KPIs  as well, though they can sometimes be used independant of individual performance reviews.