Ask HN: What does engineering leadership typically do wrong? |
Ask HN: What does engineering leadership typically do wrong? |
- 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
> 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?
---
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.
Do you mean not having skip-level 1-1 meetings?
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.
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.
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.
More often than not the second type has a middling technical background, and can't really manage a technical team because they don't know how.
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.
I guess that's typical ;)
Probably somebody who works for an engineering company and thinks there are no other things that make sense.
Sorry about that.
I do have undying respect for outstanding engineers & true leaders.
Technical leadership should bring problems or goals to their teams, and let the team surface solutions. But too often they come up with bad/unvalidated items that they assign to teams with no time or space for feedback.
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.