Hacker News Reader

Comment by camgunz | Hacker News Reader

- 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

View on HN

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

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?

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.

> - Not having skip levels

Do you mean not having skip-level 1-1 meetings?

Reply on news.ycombinator.com