Hacker News Reader

Comment by PragmaticPulp | Hacker News Reader

> Not saying they don’t add value, but they get hired and rewarded way more than the value they add and ultimately drown the company

I thought similarly when I was younger, but then I became a manager and realized it’s not so black and white.

Going back to IC developer (for a while) was a surprising relief from the stresses of managing people.

I know some companies let managers run wild and make devs do all the work, but most successful tech companies actually have very high demands of managers. A decent manager will be good at hiding all of the behind-the-scenes issues from the team, but I didn’t truly understand the volume of problems managers quietly deal with until I was in the role.

View on HN

Google may not have "started" the whole get rid of middle management idea, but they have certainly popularised it. Only to learn later ( much like 99.9% what Google does ) that you do need middle manager. But then they have zero idea how it should work. ( much like 99.9% of their product ) May be A/B testing?

Middle Management is hard. Constantly being torn apart by top and bottom. You either have decent manager that gets your team a huge boost of productivity but stressed to burn out. Or they run wild and becomes the villain themselves. I guess this is either you die being a hero or do it long enough to become the villain.

Good middle management is hard. Bad middle management (as popularized by the pointy-haired boss of Dilbert) is easy.

As a former middle manager I completely agree with this. It can be a very difficult role. I called it the the A-symmetry of knowledge. As a tech person on tools you have such a small view of the company at large and all of the other issues that are going on. Most of which you as a manager cannot/should not share with your team.

I have had tech leads come to me with solid solutions for their little slice of the world except it would be detrimental to another team or project that you can't talk about yet.

So you have to delicately tip to about your tech team with out upsetting them. Which is difficult because they largely see you as useless middle management. All this while doing the dance with the senior managers/execs justifying why your team deserves bonuses and pay rises, or taking their half baked ideas and 180 flips in directions and trying to calm them and figure out what problem it is they actually want solved.

The idea that you can’t talk about it is fundamentally flawed. If you can’t give your reports the information they need to be effective, you and the company are failing the people who get the work done.

Yup. Super common to see organizations habitually creating problems for themselves out of thin air and then becoming wildly inefficient as a result.

unless it is required by law, such as ITAR projects, a company intentionally siloing information from groups would be a huge red flag. I understand that with a company the size of Apple, that becomes a liability, and maybe thats why I prefer start ups. I need to feel like I can trust my coworkers for me to be most effective

Actually ...

It's equally hard to do good or bad management, since most of the time you have no idea if you're achieving either outcome - and neither does anyone else.

The problem with all forms of management is that it's completely unscientific. The main resource you're working with is a "human" which has emotions and who will respond to inputs in very different ways depending on all sorts of factors you as a manager don't know about.

And, when you put a group of "humans" together you might expect a direct increase in productivity - 6 humans should be 6x more productive right - you'd be wrong. Also, for whatever reasons the dynamics of the individual humans change in groups! They are differently productive depending on what other humans they work with! And, since there's no scientifically proven way of categorising them - you can't even tell which ones will work well with other ones.

Oh and the big joke, even if you get that working, sometimes they *change* and then some part of the group is broken for some unknown reason.

Then there's the problem of measurement, and I don't mean the team members. As a manager trying to measure the outcome of your own efforts is difficult, bordering on impossible - maybe something you did changed something, on the other hand it might be some other factor you know nothing about.

Finally, you might expect that the individual "humans" might know what makes them individually more productive. But, nope - most humans have no idea what makes them individually more productive, and then throw in a team setting and you're in a whole world of pain. Some of them think they're "analytical" and can't tell that they're dragged around by their emotions, love life, caffeine, commute or sunshine quota. There's a variety of 'received wisdom' stories they tell themselves, but it's often just a random walk.

So actually ALL management is hard, and you often have a equal chance of doing it "well" or "badly" on pretty much a daily basis. It's as hard to do it badly, as it is to do it well since most of time you're not sure if either is happening.

Don't forget that as a manager there's usually a ton of information about the humans you're in charge of helping (both up and down the chain) which you're not allowed to know, either by law or social norms, and some that you know only partly through indiscretions or observation, and even if you do know, it may be information you aren't supposed to use for your decision making. And that's before getting to the rest of the "resources" that are expected to be wrangled.

100%. And it is even worst you cant share the pain with anyone else. Unlike IC where they do get more support from other IC.

I am willing to bet, if engineers were given the chance of doing management for 3 months, more than 95% of them would want to go back debugging computer code than debugging human emotion and debugging organisation.

The PHB is a line manager, not a middle manager.

> Middle Management is hard. Constantly being torn apart by top and bottom. You either have decent manager that gets your team a huge boost of productivity but stressed to burn out.

Because of this, managers are (intended to be) paid so well.

Can you explain?

If there are many people who love or can do a job, salaries typically decrease and vice versa (supply and demand).

Examples are:

- salaries for programmers are lower in game development

- the "everybody can program" hype is intended to increase the supply of programmers and thus decrease the salaries

- at least in Germany: jobs with a "social feel" like geriatric nurses are paid less, because these people are told that their job satisfies an important social responsibility

So, because middle management is so stressing, less people want to do the job, and salaries increase.

I'd like to see more evidence that the job is stressful; more than just 'it pays a lot and thus must be hard'.

Any chance you can provide some examples for issues you've encountered "behind the scenes"?

Not GP, but one example is protecting developers from pressure from higher up. When you’re a manager, you’re going to get lots of explicit or implicit questions like “you have X headcount now, why are we behind on this project? Developer Z was specifically hired for this - is he just goofing off?” And you know that the new dev has been on boarding and that docs aren’t so good and that his velocity is actually reasonable, and you basically stand in the gap between your engineers and the sharks in upper management.

That’s what it was like for me, anyway. I’m an IC again now…

Isn't that exactly what the OP is saying though. That's all fake work that's only done because the even higher ups are demanding it. It's not that the manager is bad because he's an idiot. It's that what the system asks of the manager doesn't actually make anything better.

The point is it's not fake work. In fact these types of problems just become harder the further up you go. When you're upper management, now you have the problem of wondering if managers are doing their job correctly/efficiently, something even harder to manage and plan for. Imagine handing someone several million dollars in labor budget and just having to trust them that they're building the right things...I would be asking questions too. Coordination problems are tough.

> When you're upper management, now you have the problem of wondering if managers are doing their job correctly/efficiently, something even harder to manage and plan for.

If this becomes a problem, I would rather assume this as a strong sign that there are simply too many management levels in the organization, which makes managing the multitude of management levels difficult.

"shh" - The management

That’s the nature of bigger companies. You can cut out middle managers and have each manager manage 200 people but… that would work exactly as you’d expect (via implicit leadership, which will go well or poorly based on mostly luck). The more people you have, the harder it is to know who and what is working well and what isn’t. Attention only goes so far.

> I would rather assume this as a strong sign that there are simply too many management levels in the organization, which makes managing the multitude of management levels difficult.

Turns out the flat structure doesn't work out either; you will have a hierarchy, one way or the other (that is, planned or emergent.) I think us techies underestimate the necessity of coordination, and yet we paradoxically chafe at meetings.

distributed systems are hard. if you're a techie worth his salt, you know this by experience earned in sweat, blood and tears. they're permanently broken in some fashion and there's a lot of work involved to just keep them running at all.

now realize that large organizations are basically distributed systems with more smaller unreliable components.

at a certain size, it is inevitable.

you could not have a horizontal spunky start up land on the moon in the 60s. It is too complex and too much information to possibly transmit to everyone.

There are distinct issues and hard problems at each level of the company hierarchy.

its a lot like software architecture in a way. Getting up and running is easy in the beginning, one person can dictate how everything fits together and things are straight forward. Then as you scale, things that were easy and simple are now bottlenecks, so through refactoring, you create a more solid foundation, that if looking naively at the initial implementation is more complex and structured, but it allows a framework to handle bigger challenges. Success at this stage is how well the architecture lends itself to scaling.

Large companies require structure, and their success is dependent on how well that structure operates.

small companies need a group of smart people in a garage.

i totally agree with you. i think if you were a small product focused company, you could conceivably have engineers with a PM, and cut it off at that. why a PM? because talking to the customer and getting that feedback is a must, and potentially offloading that to someone specifically as their role sounds like a good separation of labor.

If I had my way, I’d get rid of the PM title and call them Customer Advocates.

It’s fine for non technical customer liaisons to have input, but putting non technical people in charge of a product doesn’t tend to work well in my experience.

Yeah, I think it's not so much the middle management that's the problem, but as you get higher and higher up a large company, and more abstracted from the actual work being done, there are a lot of demands for leadership. But our culture (at least in the US) kind of assumes that founders are special, ultra-people on the basis of them founding a company and providing jobs for everyone. In my actual experience, most of them are just characters ranging from the eccentric to the idiotic.

It does take a lot of vision and leadership to successfully run a large company. Unfortunately, I would argue, we tolerate a lot of unsuccessful companies.

No it's not fake work, someone has to watch the organizational health, to make sure business goals can be met. Managers report up to other managers because one person can only do so much, and can't feasibly track the complex social dynamics across hundreds of other people.

> can't feasibly track the complex social dynamics across hundreds of other people.

indeed. i can't figure out what sort of organizations all of these "omg get rid of middle management" folks have worked for.

if you've got piles of middle management who only have a few reports each, well, sure, that's not great because now they've got too much time on their hands to pester you. but the other direction is no good, either.

i've seen a VP with 45 direct reports before. he didn't get much done, and shed bodies as fast as he could hire new ones. he didn't know anything about any of his people, and they didn't bother trying to take their problems to him, they just quit.

...sort of. I'm in this role myself, and I think a lot of middle management positions could at least in theory be eliminated. But it would require 'Developer Z' from the above example to have those uncomfortable conversations with management himself. Would that be a stressful distraction from the work he needs to accomplish? Almost certainly. Could it be a net savings for the company? Yes, iff the right processes/culture were in place.

Since taking this position I've started to think of middle managers as human lubrication on the gears of bureaucracy. The better the gears fit together, the fewer of us are needed. Unfortunately, we're not really incentivised to make ourselves useless, so designing better gears isn't something a lot of us spend time on. And I don't know how one could properly incentivise a whole class of mid-seniority people to work themselves out of a job.

If you've ever worked as a software developer in a small company you might have found yourself being both a developer and directly reporting to what constitutes upper management at a small company, often the owner or president of the company. I was in this situation early on in my career and managing the business side absolutely becomes a whole job, but also I think I did my best work and had a bigger impact of any job I had after because I was directly owning the outcomes of software I was writing. (Of course doing both well is incredibly challenging and often ends up resulting in poor software quality, or poor engagement with management) But it's pretty exhilarating if you can pull it off and maintain a high standard of quality.

> That's all fake work that's only done because the even higher ups are demanding it.

It's not, though. On the management side, you quickly learn that teams range from proactive (will get the job done without having to ask twice) to the most mind-bogglingly slow group of people you've ever worked with. If you're not constantly asking questions to understand each situation further, the latter group will abuse their lack of oversight to no end.

It doesn't make sense if you've always been responsible and ethical yourself, and you've always been surrounded by responsible and ethical people. But once you get into management, you realize that you can't count on everyone being honest like yourself. A small but troublesome minority of employees will take full advantage of any slack you give.

It doesn't mean you should make the situation bad for your high performers (common mistake), but it does mean that you do need to ask questions to understand what's going on when things are falling behind.

In the above example, the next management move would be to understand why the onboarding was so slow and to allocate some resources to fixing it so it doesn't happen again. Something that wouldn't happen if management hadn't started digging in to understand.

> “you have X headcount now, why are we behind on this project? Developer Z was specifically hired for this - is he just goofing off?”

Is it protecting developers though? Or rather protecting higher ups from direct consequences of their crassness and cluelessness?

If in absence of middle manager, the upper manager said something like that to me he would have my resignation next day on his desk, along with a request for a raise and strongly worded demand to accept one of those documents.

Maybe you're a super in demand developer in a super hot job market. However for lots of people they don't have the option of quitting on the spot over someone asking a very direct question.

So yes the Manager is protecting them, and helping set expectations for the higher ups.

Replace higher up with Customer and you get the same system. Customer demands something unreasonable, that doesn't get filtered to the team that is working on that feature as it's just a distraction to them. Let them do the job and execute on the roadmap as planned.

I was just directly told that I was specifically hired to do this project that is behind schedule and important and they have no idea how to make it go faster (because they are bugging me) so they don't have another person that could do my job and they can't afford delay it even further to look for a person to replace me.

If there's a better moment to negotiate, I don't know what it might be.

Would hearing this be distracting for me? Sure it would be. But it's not me who would get to pay for my distractions. So it's 100% of protecting higher ups not developers.

And that's the point: It's much more efficient to have one person to run interference for a team of 5+ developers rather than having them all fight with the CTO directly. They are paying, in part, to avoid have to deal with you directly.

The higher you go with management, the more blunt the conversations. Things aren't sugar-coated and the questions are straight to the point. That's not necessarily an accusation, but it is a clear prompt for an answer.

One of the things I learned very quickly was that I was naive to assume that all developers were diligently working on their tasks with reasonable effort. At first I assumed everyone was working just like I did as an IC: Straight to work, focusing until the task is done, and enjoying the satisfaction of finishing things. Unfortunately, a surprising number of developers won't do any work unless they're constantly pressured by managers.

Junior managers often need help identifying the latter and understanding how to performance manage people. It was actually surprisingly common for a new or junior manager to hire an unexpectedly underperforming employee and not have any real idea how to manage their performance. Or worse, they might hire someone who become actively toxic to the team and not understand how to deal with it.

Stepping in to help performance manage, or eventually remove the problem employee, was actually very critical as it prevented all of the good performers on the team from quitting. Few things will destroy morale as quickly as a deadbeat showing up on a team and dragging everybody down with no consequences.

From the employee perspective: Have you ever had a teammate who didn't pull their weight? Imagine how frustrating it is if management is clueless about the person's relative lack of performance and isn't bothering to investigate why there isn't any output. Eventually you're going to get sick of doing their work for them.

maybe it can be worded nicer, but this attitude seems myopic. Business people need to do business. Accounting does not operate on the swe/self declared tech artisan mindset of taking offense to any questions regarding timelines.

just give them the information they want. If they don't like the truth, that is a different issue. They are asking you, because you have more intimate knowledge of the situation.

Budget cuts / pressure. Justifying headcount. Justifying value of the team. VIP requests for stupid reports / features / meetings. Questions about schedule, scope, etc. Politics. Stupid meetings. Stupid emails. Good managers will shield you from all of this. A good manager will let you work and create the perception that everything is ok above him, when in reality its a series of constant battles and high stakes poker.

Endless negotiations with higher ups, customers,... Finding a way to fill the gap when the guy who everyone relies on just left. Find some work to do when things are slow, and make rushes more manageable. Take estimates from different people, all unreliable, the availability for their teams, and make a somewhat realistic planning. Convert developer time into money and plan a budget. Find the correct methodology and customize it (doing things "by the book" never works).

The more I work as a developer, the more I appreciate the work of good managers, and the less I want to do it.

> good managers

And that's the key - good managers.

Now, I think that it's pretty hard for most people to identify good vs bad managers, and that's why a lot of people who aren't sensitive to the difference get into the mindset of "management is a bunch of toxic leeches who don't add any value to the company".

Interestingly enough, it's also pretty hard for most people to identify good an bad developers - but most people aren't developers. It's far easier for those that are.

This raises an interesting question - is it harder for managers to identify bad managers than it is for developers to identify bad developers? What about the ease of developers identifying bad managers vs managers identifying bad developers?

I wouldn't be surprised if it's harder to recognize good/bad managers - management is all about abstracting away the stuff under you for the next level up, after all.

But, I also wouldn't be surprised if the problem comes down to something else other than identification - maybe bad managers are more prone to keep bad managers around than bad programmers are to keep other bad programmers around...

It's at times like this that I wish that I had more experience in the corporate world...

I just moved back to IC from manager.

Communication between teams on feature alignment (read: tons of meetings), planning my team's sprint workload, dealing with other manager's politics/bullshit, dealing with Directors political bullshit, etc. It's a huge time sink away from actual engineering.

I'm not the OP but I'll describe a "behind the scenes" situation I dealt with.

I inherited a team of seven working on a project. They were led by a very strong personality who led the project based on his principles (he was interested in funneling as much corporate money into "free software" as possible while resisting delivery of business value). He'd been running the project for a long time by the time I inherited the team. One of the upper level folks gave me a call on Thursday and said, "In the operations call on Wednesday I'm going to propose killing that project because it's gone off the rails. We can use the money elsewhere. Just giving you a heads up".

I spent the weekend figuring out how to pivot the majority of the staff into other projects, use staffing as-needed to develop features for business need, and provide a minimal maintenance budget. I called the guy who wanted to kill it on Monday, presented the plan, and he said he'd sign off on it.

When I told the lead that the project will need to change he was outraged. He accused me of abandoning free software blah blah blah. I didn't get a chance to tell him about how I saved his job and the jobs of everyone else on the team by working 32 hours on my weekend and finding them other work to do.

> I didn't get a chance to tell him about how I saved his job and the jobs of everyone else on the team by working 32 hours on my weekend and finding them other work to do.

Save the day by investing your free time into making things work, then collect outrage anyway. Management in a nutshell! Great anecdote.

> They were led by a very strong personality who led the project based on his principles (he was interested in funneling as much corporate money into "free software" as possible while resisting delivery of business value).

I've dealt with someone similar. It's strange how certain people can work their way into management while actively fighting against the company's mission. Of course, it doesn't work out well for themselves, the company, or the team they manage.

> I didn't get a chance to tell him about how I saved his job and the jobs of everyone else on the team

Why not tell them?

Not OP, so I don't have the full context, but here's an example I can think of where telling him isn't a good idea:

Depending on that lead's personality he may "go over your head" and start complaining directly to _your_ boss. Which means you'll be dragged into yet another 30+ minute meeting when your schedule is already packed with meetings.

Part of your job as a middle manager is to not only shield people below you from unnecessary drama, but shield people above and beside you from unnecessary drama also.

This is where you have to use your past experiences with each individual person to gauge how to act. Do this for long enough, and grinding leetcode an hour a night for 2 months and just going back to moving tickets left to right at a FAANG company for (oftentimes) more money starts looking appealing.

But then you have some days where everything goes great, a major project is shipped without any issues, and/or you're able to (finally) give a promotion to someone who deserves it which makes it all worth it.

I ended up switching into speaking/training. All the pros of management (mentoring people, getting to speak) all the pros of coding (coding training materials is fun and simple, zero tech debt to worry about) and less responsibility on both sides.

True, but I don't think it's the same for second and third level managers.

Basically, you as a manager do all the hard work.

The boss of your boss... he can do some hard work, or he can just rely on you and the other direct managers, and simply get the benefits.

I think management simply has way more variance, and maybe, I'm not sure, more expected returns.

Have you been a manager of managers? This sounds like the same problem the GP described (the problems are invisible until you are in the role).

An upper level management job can be very stressful. You have very little visibility into progress or issues, but are responsible for setting direction and making decisions with many consequences. If you get involved, you’re called a micromanager. If you don’t, you’re out of touch.

Cross-organizational pushes become harder, with more inertia, and more perverse incentives dragging things down. You spend all your time debugging the mess of an organization, not on the things that brought you to the industry.

It can be a very stressful, unpleasant job. I am not trying to claim it’s harder, or that the pay is proportionate or whatever. But the idea that they can rely on the work of others, coast by, and get the benefits is not at all true from what I have seen.

I worked mostly in startups and FAANG, maybe other sectors are different.

This. Debugging the organization is a great way to describe it.

Oh I like this I am going to steal it from now on. I use Debugging human to describe it. But Debugging organisation is just so much better. This also follows Conway's law.

>Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

And reorgs are often the managerial equivalent of a code refactor.

> the mess of an organization

Management is responsible for the organization, hence why comments about how hard it is to deal with a messy organization tend to fall on unsympathetic ears.

Just as developers are responsible for the codebase. Yet folks seem rather receptive to the concept of technical debt. It’s not much of stretch to imagine organizational debt caused by pesky human problems.

I'm not denying the existence of organizational debt.

I'm saying managers justifying how important and difficult their jobs are by pointing to all the organizational debt they deal with are missing the point.

I agree that’s what happens in practice, but it’s quite silly. The right organizational structure depends on the problems being solved, but the business’s problems are always changing - either because of new technology, or competitors, or changing economics, or something else. Tech moves ludicrously fast, so the structure put in place 5 years ago is unlikely to make sense today.

It's not just structure.

A shocking number of managers don't even manage. They just run around putting out fires caused by a lack of management. Organizations can get stuck in this mode and it's really hard to pull them out of it, for sure, but just because someone's navigating a stressful and dysfunctional organization doesn't necessarily mean they're doing a great job at management.

I've worked in and with hundreds of enterprises, and literally never seen this in practice. As one gets further into management the work has longer-term deliverables, and many of those deliverables are invisible to managers and individuals below them. Put another way, the work product of a good executive is effective long-term decision-making. Of course it's harder to see the effects of this day-to-day.

The daily work of a senior leader is mostly communication, alignment, and politics (i.e., resource allocation). From the outside (and sometimes the inside!) this looks like "lots of bullshit meetings." Coasting at this level simply means that your priorities aren't fulfilled, your initiatives fail, you're cut out of important decisions.

OK.

- you manage managers of three teams globally with 6 employees each.

- you know that your best IC is about to go on parental leave

- three others are either leaving or moving to another team in the next year

- your european team’s manager is not meshing at all and there’s pressure from all directions to fix it

- after shuffling or firing the european manager (who you genuinely like personally,) you suddenly have 8 direct reports you need to meet with weekly and support

- new teams form with overlapping responsibilities and you have to create a relationship with that team and its leadership so no one steps on the other’s foot and there isn’t confusing ownership

- you hire a new european manager and now you have to fly overseas and train them, while at the same time handling issues for your home team and your own personal responsibilities

- in the middle of all this and while your schedule is peppered with interviews to conduct, some random high-visibility initiative with no owner and outside your area of expertise gets assigned to you.

I’ve seen directors suddenly get 30 new ICs three levels below them and have to somehow write their reviews. It ain’t all pretty.

Exactly. All of a sudden debugging human problem is 10x harder than trying to debug your codebase. Multiply that by the number of direct report. Not to mention managers that may not have actual power or have their own politics to battle with.

I'm generally supportive of the idea that managers (and managers' managers' managers..) are in many places a value-add and it's hard to get to such roles by coasting, however I also am sympathetic with many of the cynical takes and think there's a lot out there in the world of open source and startups and small businesses supportive of less management. One take is I think management frequently create unnecessary problems for themselves that of course can only be solved with more management. Take for instance:

> you suddenly have 8 direct reports you need to meet with weekly and support

You really, really don't need to meet each of them weekly. Not even necessarily monthly. Depending on the individual, some you might need to meet more than others, but the idea that you need to meet each one weekly is a self-imposed problem that of course robs you of at least a full work day, and past a certain scale requires more managers to handle. This is ignoring the content of the meetings, which if you get into make the case even worse for management, because so often a short email exchange or even a short Slack exchange suffice for what otherwise would have been 30 mins to an hour. (One of my managers was rather skilled at digging out of me over the course of our 1-on-1s some of the minor problems/issues I felt were present with the team/company that I otherwise wouldn't have brought up in an email/IM (and if I did not more than once), but given that they never changed or went away in 6 years, and that I had already made peace with them, what was the point?)

Same thing with conducting a ton of interviews -- delegate to ICs of the team the candidate is likely to join! It's your own doing that you insist on having a screening chat with every candidate, or that you have this many candidates you're considering at once, or that you hire into a general "pool" where team selection/assignment happens later.

Same thing with the needing to suddenly write the reviews for 30 people -- the need for those reviews is entirely a self-imposed problem, and could be done away with or altered. (e.g. relying on ICs reviewing each other, or using objective metrics, or having an easier firing process than long PIP dramas, or just bumping everyone's pay regardless to keep up with inflation, or...)

Unfortunately system problems can typically only be done away with (rather than 'solved' with management work / more management) by someone at a higher level than you, whose higher role is in part supported by the problems existing in the first place.

> You really, really don't need to meet each of them weekly.

Somebody needs to. It's important to put in the time building relationships so that people are comfortable coming to you with concerns and so that you can recognize their patterns and notice when there's something they're not telling you.

Isn't it fascinating how many of the problems managers deal with are side-effects of a lack of good management?

People have babies, people change jobs, new hires don't work out. All of these things are known. You identified them as risks and planned accordingly, right?

> some random high-visibility initiative with no owner and outside your area of expertise gets assigned to you

Oh, I see.

Sorry dude, that's not true, and is very naïve.

When you're an IC, you have no idea what your manager does. You have even less of an idea of what your manager's manager does.

I know I was naive about direct management until I tried it and realized just how much they do that I never was aware of. And as I became a more senior IC, now working directly with senior managers (managers of mangers), I found out just how much they're involved with.

At high-intensity high-output companies (including gaming ones), it's very rare that senior managers end up just resting on their laurels and letting the line managers do all the work.

First of all, it's an all-encompassing job. You are effectively oncall for various escalations, personnel issues, priority/project issues, conflicting incentives - you are responsible for all the people underneath you, and all the conflicts that might occur that direct managers don't handle - they escalate to you. At that level, there is no expectation of work-life balance, you might get called in the evening/weekend to deal with something. While you're detached from the depth, you are responsible for way more breadth.

Secondly, line managers are still expected to be primarily focused on their technical projects and their people. Senior managers have to start dealing with Legal, Marketing, Sales, Facilities, office issues, christmas party organization, press release, etc. Sure, some of it is just coordination and delegation, but the point is that you have to organize all sorts of disparate considerations that frankly are not in technical people's forte. This arguably becomes 50% or more of the job, and this is where things get really tough. Do you want someone technical for this that will be MISERABLE spending time on 50% of their job, and not doing an amazing job at it? Or do you want some MBA type that will be great, but then have no credibility with their team, no ability to influence the techncial direction, because their people will sniff out their technical weaknesses and not respect them for it.

Naturally none of this is universal. There are exceptions of exactly what you're imagining - someone that just steps back, lets everyone else do the work, and they aggregate/summarize and take all the credit. But I don't think those are actually the majority.

> frankly are not in technical people's forte

Amusing to see this attitude on HN in the 21st century. Have not the last 20 years of startup successes having very technical founders successfully transition to more managerial roles more than demonstrated otherwise?

It would seem to me founders, technical or not, would be well suited to management positions with a lot of control/freedom since that is likely not so different from starting a business, except scaled up.

Is your suggestion that they wouldn't do well in more constrained middle management roles? Perhaps (I don't really agree), but then does coming from the other side with the whole idea of "technical managers" and ICs "retiring into management" (many later ending up as high as any level you want to pick with various domains of focus -- some even go get MBAs!) matter to you? I find it laughable to create a technical/non-technical dichotomy as it relates to predictive managerial suitability (programmers deal with absurd complexities in software, but somehow aren't suitable to organize a Christmas party?) and even fundamental preferences. The father of quality management (Deming, whom more people in software should read, especially managers) was himself quite technical.

Maybe you're right. My overarching point to OP who was doubting what managers-of-managers do, is that this a big part of the job, and it takes time, and effort.

There is also a big difference between doing these things as the CEO of a 100-person startup, where every choice you make is a reflection of you, a reflection of the culture you're setting up, and contribute to the legacy that YOUR company will have, vs as the Sr. Manger of a 100-person org in a huge company, where ultimately it's not your company.

No, absolutely not. Going from a beeing an expert into a new management role is almost a different career, and there’s no predisposition for « technical people » to succeed at it.

There's no predisposition for them to not succeed at it either on account of them being technical. That's my point, drawing a technical/non-technical dichotomy for who is best suited a priori for management (let alone organizing Christmas parties) is silly, and extremely old fashioned given the broad successes of technical people switching to management at every level from front line to CEO over the last decades.

as someone who is considering switching to a management role, what has been your experience as a prior developer, and now coming back, do you feel like you have lost any "edge" being an IC? Also what new perspectives have carried over? I think I'm hoping to get basic team building and management skills to one day start a business, my preference is to be by myself struggling with technical problems, but I see the value in the management skill set

A decent manager isn't so different from a scrum master in the agile world. A good manager is an intentional bottleneck; they are careful about what gets through the pipeline.

"hiding all the behind-the-scenes issues" that COME from the management/ops/marketing/sales layer. it's kinda like a snake eating it's tail.

Reply on news.ycombinator.com