The truth is you need near-100% understanding of the code going into the product to really gauge someone's participation accurately. Looking at LOC, # of commits, etc. is all fluid so while they describe properties of the story, they're not the actual story itself.
Also, there's up and down weeks. I've watched my top performers have poop weeks where they've only been able to crank out a couple of small features, or maybe just resolved one issue, etc. I feel like if micro-managers saw this they'd put the hurt on em... for me it literally never came up because within 1-2 weeks they'd be back on the rails. I was always like "huh - musta been some human stuff." Or, heck... sometimes I could tell they just moved a bit slower on more mundane tasks. When I put myself in a position to relate to that I find that I have the same lulls, lack of motivation for mundane work, etc.
People NOT getting back on the rails after 1-2 weeks of meh was the exception! I also felt like I could demand more of my team during the 2-3 crank-it-out periods that inevitably occurred throughout the year because I had respected their time leading up to that... IDK.
All-in-all if specs were being respected, code was clean/reasonably PR'd, deadlines were hit, and meetings were well prep'd for + attended I felt that we were being successful.
When I'm having off-weeks, I'm painfully aware of them. It causes me a lot of personal stress and anxiety. My manager is like you and never calls me out of it during our standups. He may ping me and ask how I'm doing, etc. I'm glad he doesn't call me out on it because that would just amplify my anxiety and probably make things worse.
You're right, after a week, maybe two, I get right back on the horse and manage to catch up.
People wanna feel safe... And go figure, when they do their output usually goes from being minimal effort to above and beyond. Also feeling safe has sooooo many more institutional benefits etc. Errors are identified + corrected quicker, people don't play politics near as much, things just get "easier"... hard to explain.
But yea - definitely give that guy some positive feedback in your 1:1's. That was one thing that helped me really design a system that people wanted to work within, solid feedback when things work/didn't work =)
He put -1998 lines on his daily email?
And I think that hits to the core of Goodhart's law:
""When a measure becomes a target, it ceases to be a good measure.""
This story came up often when I said I read the commits daily. I would just roll my eyes and say "I read code, I don't look at arbitrary LOC".
If the story is true it shows incompetence with the managers to pick such an arbitrary metric to measure with. Plus, when you start policing people like this you can damn-near guarantee motivation goes in the trashcan because now it's a "me vs. you" thing... and eww who wants to come to work with THAT?!
Thank you for finding it.
https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...
I learned quick to not make assumptions, and to hire/retain people who I could trust... I also requested informal reports ever 48hrs or so with links to what you'd been working on, PR's, documentation, etc. Reports were sent to a distro list of all team members and replaced traditional stand-ups. So generally if I was in the dark it would all be figured out in due time without having to get up someone's butt. I feel like it kept everyone accountable and transparent when everything was in writing.
Also with ramp-up specifically... since I was paying attention to the hard metrics I started to get a feel for when something was difficult vs. easy. Projects that would kick people down for simple tasks would get priority for refactor, difficult onboarding was usually met with aggressive documentation, etc. Over time you got a taste of what these beasts were without even being an IC on them.
The next set of questions: "If you are a higher-level manager, are your first-line managers capable of reading programs ... ? ... Our surveys indicate that nine-tenths do not ... Do you think it is possible for a first-line manager to know how good his programmers are or how well they are doing without occasionally reading their programs?"
I'm glad to read your report to know that at least somewhere out there exist software managers that seem to 'get' that code is (or should be) the central artifact in all the crap we programmers produce. Not that the other stuff isn't valuable, but things can still work without it, whereas without the code nothing works. My remaining fantasy is to encounter a software manager who is familiar with Deming's work and has thought about how to apply it to software management.
Am familiar and in my experience TQM is just as cargo-cult as Six Sigma, Waterfall, Agile, etc etc. You get these highly-stylized idealist models, often which have books and courses, then the consultants... Ugh. IDK - all of this crap is noise to me. I found Deming's work super thick, and honestly I'm probably too much of a simpleton to really "get it"... =|
In contrast, my personal commandments are near-100% inspired from the two lists:
* Tom Sach's "10 Bullets" (how to work)
* Joel Spolsky's "The Joel Test" (how to run an effective software company)
It doesn't surprise me to hear there's a ton of BS around Deming's work (it's had even longer to build itself up) but I still think there are valuable things there that software companies, especially larger ones, are missing... And we seem to have the existence proof of there being something to it (i.e. Japan's rise, and later on US companies adopting things... though as Jobs once noted (https://www.youtube.com/watch?v=kib6uXQsxBA) customers won't think highly of your quality if you keep shipping garbage despite winning a Deming Award or having all sorts of advertising that claims high quality).
Even starting from the surface root level with Deming's "System of Profound Knowledge" -- his 4 key components -- I see a total lack of "Knowledge about variation" all over the place. Without some intuition of variation you can't even appreciate what you mentioned about how programmers sometimes just seem to have "off weeks", and from what I've read Deming wanted the understanding to be more deep than a basic "yeah things vary" instinct, and to know it applies not only to individuals or individual units of work (e.g. red beans experiment) but to larger scopes as well. Ultimately the knowledge needs mathematical grounding (specifically in probability and statistics), which is something else sorely lacking in management trees (and even more and more on the programming side). If there are things like TQM certifications out there that don't imply a holder has a certain level of mathematical sophistication with statistics, that's all the more damning to the certificates and bodies of work around them, but not I don't think to the importance of such knowledge...
> Ultimately the knowledge needs mathematical grounding (specifically in probability and statistics), which is something else sorely lacking in management trees (and even more and more on the programming side)
This is one of the biggest struggles of my career... dealing with quantifying something that's incredibly difficult to quantify.
---
Glad you're checking out Tom Sachs' list! It's an odd one for sure - weird artsy video and all. It's about an art studio in NY and how it manages it's people/process. It's sorta hokey I'll admit, but I find the simplicity of it helps me get back on the rails myself during those times of variation =)
I really related to this in my last role. It's the butts-in-chairs method vs output because let's be real... most of the people promoted to middle-management can't measure actual output.
I've always been on the edge of being a manager vs. being IC and the times I've bled over into management I have this style: you're expected to be here early by 30 minutes for meetings, and if you wanna leave directly after to go work from your home office I could care less. I expect workers to be highly available via chat and phone during normal business hours (adjusted to the timezone), and generally flexible if something comes up where I need 'em in the mothership.
To measure output and success, whelp I just get on the corporate GitLab and read everyone's commits daily. Not only do I learn a TON working with solid talent... I also know who's jerkin' me around. Does this work for every WFH-type employee? Nope. Managing devs gives you a ton of black-and-white paper trails to ensure people are working the right direction.
In contrast, throughout my IC career none of my managers have managed ME this way which blows my mind. I know I'm not the most talented leader but I don't understand why dev management doesn't look at real metrics to gauge success outside of "I don't know how to read code"... =|
The way I managed also bought loyalty... like a lot of loyalty. When you get out of the way of people's lives and say, "I'm willing to make this career work with you as a person" you get an insane amount of forgiveness for being a poop manager in other areas.
Did people take advantage of me giving them this slack? Yep. Did I fire 'em for poor output? Yep - at will state sucka. IMO you'll get people taking advantage of the system regardless of how you wanna lead so the best way to hedge that risk is looking at metrics + engaging consistently with your team. Bad apples tend to stick out in a few months and you just gotta learn to fire fast to maintain the integrity of the team vs pumping your staff numbers.