Another ex-Googler here. This seems like a viable strategy, but it seems rather inefficient for the organization, don't you think? E.g. > Write some queries, r

Another ex-Googler here. This seems like a viable strategy, but it seems rather inefficient for the organization, don't you think? E.g. > Write some queries, run an internal survey > Write a proposal doc, get it reviewed by others Even if one could convincingly claim a causal effect on those noisy metrics, that sounds like quite a bit of overhead. IMO the majority of cleanup or bug fixing work shouldn't require any sort of formal planning or justification. At other companies, we would just go ahead and do the work. Then if an IC's work shows a pattern of code quality improvements, the manager should take notice and make sure it's considered in any promotion decisions. Moreover, the strategy you mention requires a concerted effort to improve the quality of a particular component in a short period of time. Ideally one should evaluate bugs and quality issues as they arise, and most of them should be fixed promptly. But if a Googler is optimizing for promotions, it seems better to let code rot for months or years, then fix many issues in a short sprint to create a nice dip in the metrics.