Crappy management begets crappy managers. Agreed.

I have a counter/supplementary theory that it is just as disruptive to assume a good developer will be a good leader or manager, too.

Rant time (aimed at no one in particular, especially not parent comment):

Managing is a very different skillset. There needs to be some significant knowledge of the industry at large, the specific domain that is relevant to your biz, and "generic" (for lack of a better phrase) management skills (i.e., communication and management of the squishy bits of your org that show signs of sentience and sometimes speak)

I've lost count the number of times I've heard colleagues say "They are such a bad (technical) manager, they'd never be able to do what I/we do." and have responded with "They don't need to. That's why they pay you."

I get very tired of this "debate" that it is management _versus_ IC/developer/engineer/worker. I also strongly believe a lot of what is perceived as "top-down" management is harbored by a "bottom-up" resentment - or just plain resisting authority.

You are a team, so work together.

I also hold the opinion that if your organisation has this mindset ("versus") within then you have a much bigger problem than what is presented at face value.

> I also strongly believe a lot of what is perceived as "top-down" management is harbored by a "bottom-up" resentment - or just plain resisting authority.

As long as the people calling the shots still make more money than I do and I am the one cleaning up the mess that creates, I feel pretty justified in resenting them.

This is spot on in my experience.

The first thing that comes to my head when talking about bad management are manager positions with the power of taking decisions they they either don't fully grasp the consequences at-large of, or will not be hold accountable of bad results for.

How do you know they don't have a bigger-picture view than you? How do you know that they haven't had to acknowledge your problems but have to compromise because the alternative would be more problematic? (It's been my experience from both sides that even simply telling people this is the case isn't enough.. I've seen peers get upset when management explicitly acknowledge and explain why compromises are made but some on the team still feel resentment to that manager - but not the reasoning, despite it being objective) as well as members of the team I am managing hold resentment to me despite my own objective reasoning, and even support from other members of the team, not being enough to, I quote, "show them I am a good enough manager."

I'm not going to pretend managers are automatically all massive value-adds. A bad manager is a bad manager. But a bad developer is a bad developer. A bad person is a bad person.

My previous rant is mostly about those who perpetuate this nonsensical adversary between managers and workers everywhere they go, often wearing their repertoire of conflict with management like some kind of accolade.

To assume any given manager is bad because of previous experience, or based upon your own misunderstanding of what a manager does? That is ignorance and prejudice, which is your cross to bear.

"Managers" (the collective/stereotype) don't deserve any resentment. An individual manager that is disruptive and/or a drain on the team's productivity then sure, there is a valid grievance.

Consider that you may be making messes that you are unaware of, and that layers above you may be cleaning up all the time. The "bottom of the pyramid" is not all knowing and a reservoir of wisdom.

Look, I'm just saying it how I've seen it.

When I create messes I get fired.

When I fix messes my boss gets promoted.

This has been the case anywhere I've gone. It is the reality most places I think. Companies that operate differently are the exception.

Spot on.

I have no problems with managers dictating things as long as they take the responsibility of delays, failures, outages

While I agree that managing is a different skill set (have switched between the roles several times in my career) the problem with focusing on "it is a different skill set" is that it allows mediocre managers to get in who have neither a clue about the product nor about real life software processes but e.g. are great "agile master"s or have a sales background. A lot also depends on the nature of the project - some are more tangible and some other are very technical.

We need people who know where we want to end up, can recognize problems, understand dependencies, can remove hurdles, can provide resources, can communicate, make sound and stable decisions, motivate and plan. Some of these skills are mandatory in a developer but there are quite a number of managers who have a surprising lack of ability to recognize dependencies, mentally juggle dependencies, plan and making stable decisions. And when they are coming from a pure "agile master" factory they may even not be able to communicate and focus on a product goal.

> You are a team, so work together.

I agree but there are cases where managers are such a bad fit that exchanging them is the only option. Two days ago I put out feelers to see whether others thought our project manager was in over his head and we needed to escalate it. Working as a team together was not really an option as we as a team would have to do all the managers work, deal with the overhead he was creating and still had key questions undecided. Yesterday I learned the manager is quitting which is good for everyone, clearly he was not comfortable in his role and had looked for alternatives. And no, there was no animosity from the team and he had a lot of help when he started. A nice guy but not a fit.

This is a great comment, and it helps reveal to us why there are approximately zero good managers.

Imagine a job advertisement:

Position available for (Software Development, but any industry really) Project Manager.

Hard requirements:

• Take ownership • Delegate • Know where we want to end up • Recognise problems • Understand dependencies • Remove hurdles • Provide resources by identify bottlenecks and resource constraints and remove them • Be able to communicate to the team collectively and each member individually to a high level • Make sound and stable decisions • Motivate the team • Do all of these things well above average level • Not just this project and this team, but also the next project and when the team gets shuffled around from time to time

There are approximately zero people who can do all of this on a consistent basis. Maybe one in a million can do some of it well some of the time, perhaps. Maybe.

If you have a manager who is simply a reasonable sort of person, though they may be lacking everything else, I strongly urge you to do everything you can to keep that person where they are. If you don't mind tolerating them, you're on to good thing, because there's a fair chance ousting them will result in your team finding the next person is much much worse.

Yeah, but we do have an awful lot of middle managers, who know very little about software.

Consider e.g., https://en.wikipedia.org/wiki/List_of_current_Premier_League... except for one or two, all managers are former players. Why? We all know something about that industry at large.

My theory is that when you are competing on equal terms you cannot afford managers that are not part of the game.

I agree managing is a skill all on its own. Yet IME it's easier to respect the choices or difficult circumstances when they come from someone who clearly knows the important parts at a conceptual and deep technical level.

Most managers climb the corporate ladder by leaving the rubble behind for others to deal with. They usually never learned to actually solve problems, and just scale the same tactics organisation-wide. This creates a culture of helplessness and shifts problems downwards. So they add processes to "manage" problems they themselves are unable to solve! The processes are just a cover for depending on local heroes and informal tribal gatekeeping, though. And so it goes on and on.

You usually hear in such orgs, that they are like family, and in most cases you don't get hired unless someone knows you.

My current manager, who is one of the best I have ever had, used to be dev and rewrote a lot of our systems so they were better organized.

I think your comment explains at least one aspect of what makes him a good manager.

Can you tell us more about what they do well? I’m a dev who has often been encouraged to consider management but I’ve scared of the Peter Principle. I’m keen to learn from good examples.

If you're being encouraged to take up management, then they've probably already identified that you're already doing some of the right things.

I hate it when I promote a team lead, and they change what they've been doing. I promoted because they were already doing the job.

That’s good advice, thank you.

Very underrated comment. The more nepotisitic/tribal an org is, the worse this gets. Everyone's just pushing the problems below.

The only way around this for devs is to say No to solving their problems and letting management deal with the fallout (loss of customers/revenue)

Yes, very good comment; pity to those of who have lived it. I am living it now! It's kind of fascinating really, to see the coping mechanisms in a dying company. The people on the lower rungs seeming to go along with the same charade over and over, going through the motions. Waiting for another storm to pass, to get home to their families at the end of the day.

> I have a theory on why we're seeing so much "bad management" for software engineers: most leaders at workplaces have not been engineers themselves at a company with a great engineering culture (I wrote about what I think this means [1]: it's all the high-growth small and large tech companies we know)

I think that's part of it, but the bigger reason is that the management talent pool is too small to meet the industry need. The same is true of engineers as well.

There's little apprenticeship, little mentorship, and little experience is gained seeing things done well. Capable people are being shoved aggressively and prematurely into decision-making roles (whether in management or engineering) before they've developed the skills and perspective necessary to do the job well. No question, talent scarcity makes for lucrative pay and easy mobility for the average tech professional. But quality suffers, nonetheless.

I think it's more than lack of experience with great engineering culture. I think bad management is actively incentivized by a spandrel of how our organizations fit together. There's a mismatch between the time it takes to yield measurable impacts and the time scale on which rewards accrue to individuals. Because large and complex projects take time, and are hard to measure, and it's hard to attribute the portion of success or failure to an individual, when three quarters in a manager is promoted to some new position which the CEO thinks desperately needs to be filled, it's off of the narratives the manager has been able to produce, not the actual impact. The tools for making a narrative of competence and success are understandable, punchy process and organizational improvements, cherry-picked measures that don't really mean anything, meetings, 1:1s.

So, when a sequence of directors each wants to "refresh" how the planning and prioritization process works, or reintroduce OKRs because they believe that what the org was doing up until that point was an incorrect, or champion some new set of Principles that obligates all existing projects to re-justify their existence in new terms, or move all project management into a new tool, they're creating a narrative of leadership. And they can tell a good story well before the non-impacts become visible, and without having to examine or deeply understand the technical aspects of what it is they're managing.

In some cases, this can be a modest productivity tax to the impacted teams. Some number of weeks from every quarter gets dedicated to servicing the most recent process changes etc. But sometimes it's actively harmful (creating separate silos for functions that really need to be in close coordination, etc).

> But it actually doesn't work with software engineers as well as it could.

Part of the reason is that relatively small details have organization-wide impacts. A handful of services might be under-resourced and overdue to drop calls to legacy APIs... That causes ongoing effort to maintain those APIs, the outdated technology they depend on, ad infinitum. Entire migrations can grind to a halt. Engineer productivity could be cut in half. Gaping security holes can be unfixed.

Top-down solutions to those problems ("Here's budget. Fix it!") don't necessarily help as solving the systemic problems can require technical analysis to fully map from strategic needs to particular patches to particular projects.

The people that understand systemic technology impact and the people who understand systemic cost and value need healthy and active lines of communication. Passing status messages up, down, and across the chain of command only gets you so far.

It's the idea that money/technology can fix a people/process problem. I see it all the time. It takes many forms:

If we could just find the right magic tool then all our problems would be solved! Step 1 is build automation, step 2 is define the process! What we need to fix this broken process is more people. These two teams have different goals/OKRs so they have trouble getting along, let's fix it with technology

Technology and money are great accelerators but if you don't have a process that could be performed manually with enough people then technology is just going to make you do the wrong thing faster.

There's this weird notion among directors, VPs and svps that any problem can be fixed with staffing. It just needs more staffing, no biggie. They just can't grasp that it could be done by motivation of existing engineers, lesser micromanagement and more inspiration.

When you have a hammer, everything looks like a nail.

But dont forget, Bezos is a business guy. Here his original idea: https://www.youtube.com/watch?v=rWRbTnE1PEM

That's a good interview, kind of like the early interviews with Gates when his enthusiasm for the tech was really shining through. Its great to hear Bezos talk about creating value for the customer, something that I feel is to a degree lacking in some of the bigger startups we see these days.

I agree with your theory. I find the company I work at really interesting, I think it had the opportunity to have engineers as managers, but over time, more and more engineers decided not to become managers, and as that happened, more managers were hired from outside sources, which tended to be non-engineering managers (or managers who hadn't done actual software work for decades). I would not be surprised if this is a common issue.

Apple takes the approach of essentially forcing their best engineers to become managers.

[0] https://hbr.org/2020/11/how-apple-is-organized-for-innovatio...

I think there is another powerful force that explains why so many managers are perceived as bad: in most companies, career growth for managers means moving up, and moving up is at best uncorrelated with managing your team well and with respect. I would actually go as far as it is negatively correlated in some cases.

A lot of stuff I see about what an EM should do, on places like leaddev, in the well known eng. management books, those are all great. They cover most of what I enjoy doing as an engineering manager. But they also means shit for moving up in many (most ?) larger orgs.

Part of the issue is that as the company grows in size, it becomes essentially impossible to correlate company success with certain teams. The complexity becomes such as people above you cannot possibly understand properly what's happening there. At this point, it starts to become all about managing up and lateraly, which takes an awful lot of time. People above you even has less mental space than you on what's happening in your org. So one trick that many senior managers will us, in engineering and otherwise, is to be behind some big salient initiatives. It is kind of a marketing trick. Do something visible that be associated to you.

And then unfortunately the trick often becomes to leave before people can understand the mess that creates. But I think it is important to understand the incentive behind that: it is not because people are evil or stupid. It is just inherent to most large organizations. Very very few large orgs has been able to prevent this behavior.

The key is finding the right mix between autonomy and direction. You really need both cause there is a need for direction and organization esp as the group grows beyond team size.

But most problems aren’t a result of following the correct “science” of management, itself a dubious proposition, but can be traced back to what’s really important. You have to have the right people in the building to start with.

Fred Brooks had it right oh so many years ago. Communication is an exponential cost, so the more skills that you can give to a single person, the more they can do.

But it's even better than that, as every time communication occurs you are playing a game of telephone with translation errors. The essential complexity might be very easy, but when you need to translate that problem from users to project managers to architect to developer(and I'm sure many teams have many more layers than this) the complexity grows out of control.

I thought about this topic when the StackOverflow blog on Scrum ruining great engineers came out[0].

Imagine you have a chart where the x-axis is trust, and the y-axis is skill. x-axis at the far left is management focused. x-axis all the way to the right is developer focused. x-axis in the middle is mutual trust. bottom y-axis is no skill, top y-axis is extremely skilled.

Now let's look at some of the spaces this chart provides. If we start at the top right, we have Professors. They have a lot of skill and have tenure to be able to do what they want. On the bottom right, I imagine something like Adam Sandler's character from Billy Madison(1995), a son of a billionaire who wasted his life and had no productivity.

On the bottom left side we have government contractors or outsourced developers. They do the work they are told to do. In this spot Scrum can be a reasonable way to filter between the very least skilled workers and someone who is doing decent work. But by applying Scrum, you are naturally holding the management axis to the left.

The Top Left doesn't exist. The developer leaves for some place better.

So now we can talk about the middle. At the top of the middle we have Skunkworks projects. And as we can see, this balance between management and development can yield incredible results, if the developers have the skill to back it up.

So we can see there is a careful balance, most developers are probably somewhere in the middle "strike zone", and by applying Scrum to a developer who is highly skilled you are handi-capping them, and if you apply to much force they leave for better pastures.

When you have developers in this strike zone, give them advice, allow them to learn, but let them make their own decisions.[1]

[0]: https://stackoverflow.blog/2020/06/29/does-scrum-ruin-great-...

[1]: https://jessitron.com/2021/05/26/a-high-resilience-org-chart...

Too much autonomy is too much of a good thing. You end up with 5 "send a email" microservices, multiple design systems, etc. People won't bother to look outside of there team's scope to see if anyone else in the company has solved a similar problem. Or without a culture of external contributions, people will make their own versions of things that are 90% identical to an existing team's service.

This describes the org I’m in right now. The upper management (all former engineers, several ex-FAANG) are not only supportive but have explicitly reaffirmed that duplication of that sort doesn’t matter: every team must be as autonomous as possible even if it leads to a high degree of overlap.

And it’s already biting us. There are at least two issues I’m aware of that are a direct result of this policy which are very bad. When they come to light the company’s reputation (and share price) will very likely be harmed.

Too much autonomy can be too much of a good thing, but this is not universal, and when it turns out to be a bad thing, that says more about the group who has been given the autonomy than it does about autonomy itself.

A sibling comment talks about trust/skill, and these are factors that are more important than just focusing on autonomy as a stand-alone concept.

Open Source projects show both ends of this spectrum, with absolute autonomy yielding both amazing and mediocre results.

Having a manager who is also an engineer doesn't help that much. It's like seeing a movie about split personalities. They can be a good engineer and yet when they switch to management mode, they commit the exact same idiocy as any other crappy manager. There are good managers too, but an engineering background doesn't seem to automatically produce them. I don't know if it even helps.

It's not "traditional". It's common sense. You can't let an X company be run by someone without any affinity of X.

Would you let a painter do surgery on you?

> Would you let a painter do surgery on you?

False comparison. It should read "Would you let a painter _manage the surgeons_ who will operate on you?"

Having worked in the healthcare industry - the answer to that might surprise you.

To be fair, I am pretty sure most people here in HN wouldn't be at all surprised. We're very used to watching laymen having to manage potential millions of revenue.

I guess it's the right example, because healthcare is a mess as well

> Works with finance, works with marketing, works with IT support, and should work with engineering as well... right?

I think there is a variation of Gell-Mann's amnesia effect but for management. Everybody sees how their own manager/boss is mostly wrong and useless. However, when we deal with somebody else, for example as customers, we somehow conveniently forget that fact and we continue to believe that managers need to exist.