GRAD in theory represents a huge improvement on Perf. Rather than having to please a faceless committee by stopping the whole company for several weeks per quarter to write performance data for the committee, you now have to please your manager and it's their job to gather that data.
The layer of indirection between you and the calibration committee in Perf meant that maintenance work, since it does not generate nearly so many “artifacts” (design docs, engaged user statistics, lines of code written, code review requests) it was nearly impossible to quantify and reward. Your best chance was to ask people on neighboring teams to give you Kudos or Peer Bonuses for it, so that the committee would say “well it must have been important they got all of these gold stars!”
This is how you get a dozen competing chat apps, “improved the last chat app” cannot appear easily on Perf, “wrote a new chat app and we already have 50 users!” can.
However, though it affords an opportunity for things to be better, the internal rollout of GRAD has also been botched this past year. In the absence of strong leadership, managers are assembling the same data as before “we just must not call them perf packets”, and potentially reinstituting the same biases as before. (I was actually told by my manager that I could not get a rating above a certain ratings ceiling even though he wanted to recommend me higher because his director phrased a general rule that would apply to me, “if X then they should not get a rating above Y,” but hi I am also X on something of a technicality—and my manager was not sure he would have the political capital to argue my case.)
The botched rollout means that these culture improvements from not having to prioritize only what can be easily quantified, are delayed. Like, seriously delayed. Imagine that with really strong solid leadership you could have changed the culture in one year, but now that people are reconstructing the broken familiar process inside of the new process, the culture is not going to change for the next 5 to maybe even 10 years as second order influences slowly nudge it into a better scenario.
The layer of indirection between you and the calibration committee in Perf meant that maintenance work, since it does not generate nearly so many “artifacts” (design docs, engaged user statistics, lines of code written, code review requests) it was nearly impossible to quantify and reward. Your best chance was to ask people on neighboring teams to give you Kudos or Peer Bonuses for it, so that the committee would say “well it must have been important they got all of these gold stars!”
This is how you get a dozen competing chat apps, “improved the last chat app” cannot appear easily on Perf, “wrote a new chat app and we already have 50 users!” can.
However, though it affords an opportunity for things to be better, the internal rollout of GRAD has also been botched this past year. In the absence of strong leadership, managers are assembling the same data as before “we just must not call them perf packets”, and potentially reinstituting the same biases as before. (I was actually told by my manager that I could not get a rating above a certain ratings ceiling even though he wanted to recommend me higher because his director phrased a general rule that would apply to me, “if X then they should not get a rating above Y,” but hi I am also X on something of a technicality—and my manager was not sure he would have the political capital to argue my case.)
The botched rollout means that these culture improvements from not having to prioritize only what can be easily quantified, are delayed. Like, seriously delayed. Imagine that with really strong solid leadership you could have changed the culture in one year, but now that people are reconstructing the broken familiar process inside of the new process, the culture is not going to change for the next 5 to maybe even 10 years as second order influences slowly nudge it into a better scenario.