You would hope so, but I've seen an Engineering Director at an otherwise well run software company use number of Github commits as the central reason to put someone on a performance improvement plan as recently as 2019. Granted, this was someone who was a professional manager and hadn't been an engineer for the last 90% of their career, and many people were shocked by it, but it happened.
Were they right about the person being a low performer?
I'm curious if this is "everybody knows this person isn't doing any work, here's a blindingly obvious metric to use to defend this move to HR" because HR orgs often hate things that don't have metrics attached, or if it's "I don't understand what this person is doing, and I don't see any commits, so it must be nothing"?
Completely valid question, and I think you make a great point here. A lot of baffling managerial behavior is because the manager is working in a baffling bureaucracy. Unfortunately, I think this situation was largely of the latter case, and maybe some motivations I'm not aware of.
They were a senior engineer that spent a lot of time coaching the rest of the team, and less time on their own personal work. The commits data point, in my opinion, should have been the beginning of a conversation that ended with the manager asking this person to adjust their priorities. Instead it was presented as an accusation that the person wasn't getting their work done, which ultimately lead to them feeling insulted and quitting.
I agree with you on what a manager who doesn't know what they're looking at should do there. You gotta dig in and find out![0]
I've been fortunate recently to not work in orgs where mentoring and collaborating like that is looked down upon - instead, it's encouraged - but my ongoing struggle is to figure out how to quantify it.
I've got two similar but distinct motivations for wanting to quantify it:
* If I have a manager who looks less favorably on it, I want to be able to demonstrate my worth; but also,
* If I'm spending most of my time trying to mentor the rest of the team, I want to see how well I'm doing - and I want to be able to change things and see if it results in positive or negative changes
Sadly I've completely failed at coming up with how to quantify this so far. It all comes down to qualitative peer feedback/manager feedback...
[0] As a technical person, I try to practice the reverse of this: if someone asks for a feature or claims there's a bug, I try to dig until I fully understand why they're asking for what they're asking. So I think asking for similar curiosity and depth from a non-technical person is fair.
Well, just spit balling, but you should see it in team velocity. The effort you're spending coaching should show up in the output of your team members.
Assuming there's some kind of constant ongoing engagement with one person or group, I'd expect an immediate dip in velocity as your productivity goes elsewhere, then it growing, and maybe evening out to before-engagement numbers (approximately), as they reap the benefits of learning from a senior engineer. Then, as you're able to return to normal duties and they're able to apply the lessons, you should see velocity greater than before the engagement. That delta should be somewhat quantifiable and, ignoring other variables, should represent the benefits of coaching.
There's also huge value in the increased job satisfaction for both mentor who enjoys mentoring, and a mentee who is learning. That should show up in any kind of employee satisfaction survey, or retention numbers.
Yeah, I’ve been in this situation before (without the PIP), where I had to explain to my manager that I can either help everyone get their work done, or do my own work, but given the number of people asking for help it was not going to be both.
Which leads me to want to fill the rest of the story in: the manager of the senior engineer had a friend he wanted to promote, and this was the expedient way of getting the obstacle out of the way.
That could be completely wrong, of course. But would it surprise you?
I think it's fair to use this as supporting evidence. If they are assigned tasks that aren't too difficult and they aren't completing them really fast, and there is a PR process in which changes are landed into the repo, then I think it's fair to use the number of commits to the repo.
If anybody can push commits to the repo, then it's a useful metric. Finally, this sort of action should be take after the manager has worked with their report, by having somebody else help them, or put them on a different project.
