3 ms·

- Not having skip levels - Not having a manager development program - Not having retros for engineering processes (e.g. does our 80% coverage rule still make

- Not having skip levels - Not having a manager development program - Not having retros for engineering processes (e.g. does our 80% coverage rule still make sense, should Jenkins be our job runner, etc.) - Reaching into individual teams to micromanage ICs - Trying to step in for deficient line management without context or relationships - Not having an IC development program - Not hiring ICs/managers smarter/more experienced than they are - Trying to solve problems by having engineers "do better", rather than designing and implementing better processes - Being extremely cheap on the one hand (cloud spend) and extremely profligate on the other (engineer hours on undifferentiated work) - Requiring coding interviews - Being reticent to fire underskilled or toxic engineers - Having no root cause analysis process

reverius42 2y ago
> - Not having skip levels Do you mean not having skip-level 1-1 meetings?
lucasyvas 2y ago
Awesome list - I'd add not letting go of solutioning if on the management track. Leave it to your ICs.
rkwz 2y ago
Great points! > Not having retros for engineering processes (e.g. does our 80% coverage rule still make sense, should Jenkins be our job runner, etc.) How is this usually done? Is this suggested by the team and get prioritized based on popularity or some other criteria? > Trying to solve problems by having engineers "do better", rather than designing and implementing better processes Can you elaborate on this?
- camgunz 2y ago
  One of my roles had an "Engineering Council" where this was done. I don't how well it worked--for example we were very Jenkins-dependent but everyone absolutely hated Jenkins. But, basically you get a cabal together and decide stuff. --- I forget who I was watching, maybe Rich Hickey, but whoever it was was saying that as an engineer, your ceiling is lower than you think it is. You'll never get anywhere close to twice as smart, or twice as creative, or twice as careful. You might some days be 20% smarter, which would be wild, or maybe over a year you might do 6% over, but you'll probably balance that out with down days/years and over time you'll age and get worse, not better. So the only way you're really going to meaningfully improve isn't by thinking harder or being more fastidious, it's through processes and tools. A lot of engineering managers don't internalize this. For example, they think they can just say things like "be more careful when pushing to prod", but in the history of software engineering that has never worked. What does work is CI/CD, testing, QA, design docs, etc.

reverius42 2y ago

> - Not having skip levels Do you mean not having skip-level 1-1 meetings?

lucasyvas 2y ago

Awesome list - I'd add not letting go of solutioning if on the management track. Leave it to your ICs.

rkwz 2y ago

Great points! > Not having retros for engineering processes (e.g. does our 80% coverage rule still make sense, should Jenkins be our job runner, etc.) How is this usually done? Is this suggested by the team and get prioritized based on popularity or some other criteria? > Trying to solve problems by having engineers "do better", rather than designing and implementing better processes Can you elaborate on this?

camgunz 2y ago
One of my roles had an "Engineering Council" where this was done. I don't how well it worked--for example we were very Jenkins-dependent but everyone absolutely hated Jenkins. But, basically you get a cabal together and decide stuff. --- I forget who I was watching, maybe Rich Hickey, but whoever it was was saying that as an engineer, your ceiling is lower than you think it is. You'll never get anywhere close to twice as smart, or twice as creative, or twice as careful. You might some days be 20% smarter, which would be wild, or maybe over a year you might do 6% over, but you'll probably balance that out with down days/years and over time you'll age and get worse, not better. So the only way you're really going to meaningfully improve isn't by thinking harder or being more fastidious, it's through processes and tools. A lot of engineering managers don't internalize this. For example, they think they can just say things like "be more careful when pushing to prod", but in the history of software engineering that has never worked. What does work is CI/CD, testing, QA, design docs, etc.