How do we evaluate people for their technical leadership?
He had just returned from parental leave, having departed in September. Before he left, he had proposed ambitious end-of-year goals to the executives above him. What he hadn’t done before he left was tell his team the goals, or appoint a backfill for his position. I spent a lot of time that autumn being the backfill we didn’t have to keep existing projects moving. I suspect it won’t surprise you to learn that, when the manager returned to his team in December, he found his ambitious goals unmet.
During his absence I had, in his estimation, merged an insufficient number of lines of code to the repositories that my team maintained. This cardinal reason headlined my lackluster performance review. At this organization, reviews run late by about six weeks; the manager puts them in, then a lattice of other steps happen, and finally your manager meets with you in February about a review covering your performance through last December.
The week before the meeting, I had finished up and merged a long-awaited structural refactor—one that answered a number of the team’s complaints about the repository. Due to the size of this refactor, I had done a lot of team socialization prior to merging. From start to merge, those changes took about five months. By “start,” I mean a period of observation to understand how the team used the existing system. That step preceded one-on-one interviews with teammates, socializing a solution, and finally building it. The building step—the step visible to Github—took about three weeks and came, of course, last.
