Ask HN: What does engineering leadership typically do wrong?

promote engineers to Managers.

Coddle developers.

In JavaScript land most employers set the baseline as low as they can. They would hire illiterate people so long as they see the right frameworks mentioned on a resume. They would rather hire/fire people while simultaneously complaining about the poor quality and poor productivity. The end result is supremely overpaid developers that are never capable of programming and struggle to deliver anything. Attempts to fix this generally mean passing the buck onto some senior developer without any voice in leadership or trajectory, a scapegoat.

If you want a strong team that delivers strong results do the opposite of everything I just mentioned. Management should own more than just hiring/firing people. If tech managers were directly liable for the shit their team delivers their level of involvement would be different.

At the same time expect and impose valid business considerations on product development and hold people liable for failures to deliver. This means actually measuring things and expecting software to not taking forever to do absolutely everything. It also means considering the operating expenses for having a billion dependencies in your code, the inability to refactor quickly, regression, and so on.

That said one of the worst things engineering leadership can do is promote developers to leadership positions without any degree of liability. It’s the blind leading the blind, and they are better off with some ignorant MBA that knows little about software.

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.

Well, planning is a common one. It's rare that teams actually manage to estimate the time needed properly, so projects end up overrunning like crazy. To some degree this is inevitable (software planning is hard after all), but for the most part, it's due to poor planning, failing to push back on developer estimates and generally not understanding the work needed.

Hence we get things like:

Manager: Hey Bob, how long is this new feature going to take?

Bob: 2-3 days max

Manager: Okay, 2 Jira points it is

2 weeks later

Manager: Bob, where's the feature?

Bob: Well, the library we use didn't have the feature we thought it did, and there were more features in the brief than we imagined, and browser compatibility was mixed for the JavaScript API our code depends on...

All of this probably could have been caught during the planning stages, but it wasn't.

Other things they often get wrong are:

- Not knowing what the client actually wants, or letting themselves get sidetracked by constant feature requests. Seen plenty of projects sink into the abyss because days were spent building the wrong thing, or overly optimistic sales guys promised the world and management didn't push back on it...

- Not checking in on the work people are doing, and letting projects fall apart. It's obviously a fine balance between 'checking in with people too often' and 'checking in with them too rarely', but I've seen team leads pass off work to individuals/small groups, then fail to check how things are going until everything's on fire and 2 weeks behind schedule.

- Not being willing to teach or train staff. Obviously you need to be qualified enough to do the job, but there should be chances for growth anyway.

- Not hiring enough staff. This is often a sign the company is floundering or layoffs are on the way, but if ex employees aren't being replaced and no one's been brought on in years despite a growing workload... that's probably not great leadership.

- Not getting staff out of their comfort zone/giving people a chance. This is something I've seen with teams where 1 or 2 people are classed as senior devs, and lots of others are classed as junior ones. The former get all the challenging, interesting work, while the latter get saddled with the boring gruntwork. This hurts the latter's career prospects big time, and gives the team a high bus factor due to the overreliance on a few 'star' performers.

- Micromanagement in general

- Hiring people who aren't the right fit for the team/work, or who aren't qualified for the role in question

- Not firing people who are underperforming, or toxic. The latter is probably worse really, since not only does a toxic environment put people off doing their best work and make good employees want to leave, but the negative consequences of the toxic individual leaving are often way overblown. Yes they might be popular or talented or someone you've personally been friends with for a decade, but they're definitely not irreplacable.