Literally the way to "manage" developers is to enable them to do good work, and then get the hell out of their way. The git logs, uptime, and slack messages are all the records you need for evals.
Oof, please no. Simple metrics like LoC, story points and number of commits are lazy ways to evaluate developers. And people will recognize this so the metric becomes the goal. Might as well replace managers with a bot. Good managers should be in touch with the full picture of their reports work and not rely on simple heuristics. That's what makes a really good manager.
> Simple metrics like LoC, story points and number of commits are lazy ways to evaluate developers.
I mean, looking through the git logs means you look at code contributions. If you're a software engineer, that's kind of, ya know, your entire jobs. You can get a lot from looking at someone's contributions, especially in code or documentation or slack responses. Volume doesn't mean shit though, that's the trick.
> Volume doesn't mean shit though, that's the trick.
Based on having studied lots and lots of open source projects, I can say volume has a very strong correlation with experience. The more people contribute, the more likely they have been contributing for a long time. A novice contributing a lot to me, can be a sign they are extremely good or they are trying to game the system or they don't know what they are doing and are constantly fixing previous mistakes.
My git logs don't represent all the code I didn't write. Solving a problem doesn't necessitate me writing the code, or even having code written at all.
Or do away with performance reviews entirely. In my entire career I've never once seen a review cycle that was a net positive, and more often than not they cause the best performers who normally don't care about such things to become disgruntled and leave.
As a manager they create perverse incentives especially if you have a high performing team (which you want to have) that all deserves a promotion but a limited budget. The incentive is to keep that low performer around so you have the budget to promote the others.
It's a systematized way for management to shoot itself in the foot. But for whatever reason we think something must be wrong if we're not giving and getting report cards at the end of the year. Waste of time and counter-productive.
I'm a VPE at a small-ish org (30 devs or so, currently), and I regularly skim through commit history and keep an eye on various technical chat (we're fully remote, so there's lots of chat). I don't think I spend more than 15 mins per week looking at git history, but that's very informative -- it is not enough to make robust decisions but it is good enough to spot issues once in a while. (I have written my fair share of code in the past, so that helps.) So it's like going to a book shop, reading two pages from a book and deciding whether I like the style or not.
Full disclosure: I'm trying to find a way to use development insights to help us develop software better, together.
I tried a lot and I mean a lot of ways to see if we could use git commits to help us better understand productivity, but I've found commits by themselves lacks a lot of context. Especially since some commits may never be merged.
What I've personally found so far, is that using pull requests is a very good way to help us understand development effort. By looking at pull requests, like the following for cockroach:
it is much easier to grok what everybody is working on or has worked on. Having studied a lot of open source projects, it is kind of shocking how some developers can move and manage so much.
As a side note, if you are wondering what the lightning bolt icon is for, it means another pull request is modifying a similar file. The left arrow means the pull request has a file that is not up to date with the target branch.
edit: fixed autocorrects