4 ms·

> He micro managed everything. He had an office manager sitting with the engineers reporting to him multiple times a day on if the engineers were sitting on the

> He micro managed everything. He had an office manager sitting with the engineers reporting to him multiple times a day on if the engineers were sitting on the desk. 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.

james-mcelwain 6y ago
I've often been tempted to show my less-technical manager our commit log, but have always avoided it because I can't see any way it wouldn't turn into some stupid game about commits and lines of code changed.
- caseysoftware 6y ago
  "Your lines of code contributed is negative! Why do we pay you? You should be paying us!" - No one, I hope..
- folkhack 6y ago
  I'd say about 70-80% of managers I've had couldn't build or work on the product that they're tasked with managing. And... I resent that. 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.
  - ishjoh 6y ago
    where there are dips in productivity it can also be that they're getting up to speed on an area of the codebase they are not familiar with. Ramp-up time is always difficult to account for but is absolutely something everyone needs when looking at new code.
    - folkhack 6y ago
      Yep! Or even just people documenting could look weird on metrics/etc. I'd admit I was in the dark a lot, and that many times I would be perceiving a "productivity dip" when it was a situation like you're describing. 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.
kyuudou 6y ago
In a way remote work removes a lot of the "kiss my butt for rewards" crap. Funny how that fleshes out.
Jach 6y ago
I've been reading The Psychology of Computer Programming recently and enjoying it quite a bit. One fun bit is each chapter ends with some questions for reflection -- both for programmers, and for managers. I laughed a bit at the end of the first chapter, where the first question for managers is: "If you are a first-line manager, are you capable of reading the programs written by your programmers? ... If you are capable, do you read them? If you don't, why not try it and see what you find?" 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.
- folkhack 6y ago
  > 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)
  - Jach 6y ago
    Haven't come across Tom Sach's list, I'll give them a look and reflect. I still like Spolsky's list though. It's always fun to think about which points the industry (or one's own employer) has consolidated on by now and which it hasn't -- hard to imagine there exist many 12s on the prevalence of this item's open offices topic alone, and even Microsoft isn't a 12 anymore as far as I know. (Maybe parts are.) 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 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...
fancyfish 6y ago
This. You need to be able to constantly and quickly cull the weakest from your team. After a while you’ll recognize the best ones and run a Tier 1 top-talent team supported by metrics, and the weak will move on. The strong will have room to grow without micromanagement.

james-mcelwain 6y ago

I've often been tempted to show my less-technical manager our commit log, but have always avoided it because I can't see any way it wouldn't turn into some stupid game about commits and lines of code changed.

caseysoftware 6y ago
"Your lines of code contributed is negative! Why do we pay you? You should be paying us!" - No one, I hope..
folkhack 6y ago
I'd say about 70-80% of managers I've had couldn't build or work on the product that they're tasked with managing. And... I resent that. 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.
- ishjoh 6y ago
  where there are dips in productivity it can also be that they're getting up to speed on an area of the codebase they are not familiar with. Ramp-up time is always difficult to account for but is absolutely something everyone needs when looking at new code.
  - folkhack 6y ago
    Yep! Or even just people documenting could look weird on metrics/etc. I'd admit I was in the dark a lot, and that many times I would be perceiving a "productivity dip" when it was a situation like you're describing. 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.

kyuudou 6y ago

In a way remote work removes a lot of the "kiss my butt for rewards" crap. Funny how that fleshes out.

Jach 6y ago

I've been reading The Psychology of Computer Programming recently and enjoying it quite a bit. One fun bit is each chapter ends with some questions for reflection -- both for programmers, and for managers. I laughed a bit at the end of the first chapter, where the first question for managers is: "If you are a first-line manager, are you capable of reading the programs written by your programmers? ... If you are capable, do you read them? If you don't, why not try it and see what you find?" 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.

folkhack 6y ago
> 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)
- Jach 6y ago
  Haven't come across Tom Sach's list, I'll give them a look and reflect. I still like Spolsky's list though. It's always fun to think about which points the industry (or one's own employer) has consolidated on by now and which it hasn't -- hard to imagine there exist many 12s on the prevalence of this item's open offices topic alone, and even Microsoft isn't a 12 anymore as far as I know. (Maybe parts are.) 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 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...

fancyfish 6y ago

This. You need to be able to constantly and quickly cull the weakest from your team. After a while you’ll recognize the best ones and run a Tier 1 top-talent team supported by metrics, and the weak will move on. The strong will have room to grow without micromanagement.