Live data from Hacker News

Ask HN: What does engineering leadership typically do wrong?

news.ycombinator.com

1–10 of 18 posts

Re: Ask HN: What does engineering leadership typically do wrong?

#5
- 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

Re: Ask HN: What does engineering leadership typically do wrong?

#6
Ideally, the top individual needs to be fully capable of engineering at a level higher than most of their peers, and recognized for that with admiration at every step of their career. This respect is essential as they move through their careers toward positions where they will no longer be tasked with continuing to do very much more engineering personally themselves. From that point they will be dependent on their engineering staff and there has got to be a nice gradient up and down the line so every little transition is smooth, and this admiration is maintained. Most things are not ideal but if there is any gap that would make this type of smooth succession impossible in the entire engineering hierarchy, Murphy's Law will add another corollary right there if they don't already have one that you should be aware of.

That same person needs to be also admired likewise for their leadership ability, even when they are not exactly in a leadership position so much of the time when starting out and growing as productive engineers. Over the long run this means co-operation instead of internal competition which can be so destructive. Productive workers of all kinds should naturally favor the direction they envision, and there should always be meaningful positive responses as more leadership responsibilities are gradually shouldered by the suitable outstanding engineers.

And the whole organization should recognize the benefit as responsibility for the momentum of an entire engineering staff increases for those taking on leadership positions.

Nothing's ideal but there's got to always be a way for this to end up being one person possessing both top engineering & leadership abilities, supported by a cast of suitable likewise candidates for smooth succession, or something is wrong.

But that's just for an "engineering company".

There's lots of other kinds of companies for people who are nowhere near this kind of thing at all. There's lots of other things that do make sense too, that's just one of the things that I've seen that is typically so wrong. It can be easy to point fingers, but difficult to do the right thing anyway.

Re: Ask HN: What does engineering leadership typically do wrong?

#7
Not enough experience to say "typically", but things of my top of head:

1. Credentialism or "too narrow thinking" in hiring: we use AWS so your GCP experience does not count. That candidate is from Columbia so we should give this candidate a chance while the person from Rutgers gets passed on.

2. Not recognizing the importance of holistic system design. In backend or distributed systems you often need good design. It can often be good to stop the world for a week to fix the design.

3. Lacking a general sense of humility or having too much ego. Most people are not Alan Kay, nor are most leaders. As a leader, embrace some fallibility and limitations of being human.

Re: Ask HN: What does engineering leadership typically do wrong?

#8
Leadership is a hard to balance activity.

One common failure mode is to keep doing the old job. Do hard parts, don't trust other people with the most critical parts, ...

The opposite is just as common: Forgetting the technical parts. In my experience, it takes about 6 months to go from sharpest knife in the drawer to architecture buzzword bingo specialist. An engineering manager needs non stop contact with reality to stay real.

The good managers I knew kept doing a small part of engineering, but not anything critical. Say, a few hours a week. A good manager can be away for 2 weeks without anything technical failing and needing their immediate attention.

Another side is managing your people: Set quality standards, build processes, give vision and direction. Overly technical managers tend to forget this part of the job.

What tends to go reasonably well is managing upwards. If you do the legwork to know the numbers (money, man hours,..) and have some vision, you can help negotiating what can and can not be done. Don't get me wrong, this is hard work and eats calendar time. But at least the skills are there.

Re: Ask HN: What does engineering leadership typically do wrong?

#9
post #5

- 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 ex…

> - Not having skip levels

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

Re: Ask HN: What does engineering leadership typically do wrong?

#10
post #5

- 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 ex…

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