I've read plenty of them years ago, but never got any real opportunities to utilize the skills. Management is so many steps away that it doesn't matter (I work at a large company). On top of that, even if I get promoted into "management", it would only be a 7% raise and at least 40% of my time would still be dev work (thanks development chapter lead model...). What's the point if there's not a clear and reasonable path to the real money ($200k+)?

But if the idea of real people management, so supporting others and helping them grow and advance their careers (not just "being the boss"), is interesting to you, then these kinds of resources are great.

Good people management is harder than it looks. I've been on a 2-year journey to learn the skills required to do it well because I am no longer interested in day-to-day coding, but I like the idea of staying close to the practice and helping more junior developers grow and get better.

If you still have to code and be a manager, that sounds.. like a good reason to look for a job elsewhere.

Unless you're talking about a tech lead role where you mentor and guide, which is different.

But managing people's careers, helping them with salary conversations, HR stuff, job coaching and more.. that's a full-time job.

Switching companies won't help me. I need stability due to several family medical issues and a limited job market in my area (fully remote is not a great option for me, at least initially). I also wasted a large part of my career working on FileNet and Neoxam, so switching is not so easy with the limited experience in other tech. It seems most posting are for seniors and almost nothing for midlevels.

"If you still have to code and be a manager, that sounds.. like a good reason to look for a job elsewhere."

That's why I don't really want to do management at my company anymore.

"But managing people's careers, helping them with salary conversations, HR stuff, job coaching and more.. that's a full-time job."

That's my thought, but apparently my company doesn't think so.

that's not management, that's a leadership position.

if in doubt when they offer you a management position ask what the budget for the role is, if it's none, you'd be just either a secretary doing the grunt work for some other real manager (nowadays known as "middle management") or a lead they gave a sounding title in lieu of the dangling carrot.

If I knew minors were totally worthless then I wouldn't have wasted my time on it. My company cared more about me getting a CFA Foundations cert eventhough I said it was 99% stuff I learnt in my minor. The manager was shocked when I got a 95%+ 2 days later (most of them study for weeks or months). Hey, I tried to tell you it was a waste of time and money, but I guess I need an MBA from Stanford or Wharton for people to listen to me...

The whole hiring and human resource management stack is in shambles, built out of century outdated concepts and prejudices.

Funny thing is, the opposite can be simultaneously true.

My company makes a big deal about diversity. I look the part etc, but I don't fit any of their diversity metrics. So you can't fit the stereotype too closely or you're hurting their metrics, but you also can't be too "out there". You have to fit in that narrow band of helping them meet their metrics while also towing the line enough to preserve the "culture".

That's an important one. In one company I was "director" for 15 people but had no say in salary or hiring decisions. This gets really frustrating after a while.

Yep, exactly what's going on.

There is no clear path to the real money. I stepped off that path long ago.

Does anyone know of any good books, blogposts, podcasts, etc. about how to set up a management structure for your startup? Like how you even decide to have Eng Manager and People Managers and Team Leads? I'm curious about the different ways people have tried organizing relatively small (10-50) teams of high-performing individual contributors. There are books like this one (I think, can't buy it yet), Will Larson's, and some of the others referenced in the episode notes which are all about how to make a specific structure work, but I haven't yet found information on other kinds of structures.

So your tree splits — you pick a couple nodes to continue directly reporting to you, and all others now report to your direct reports. As your reports gain more resources, they’ll do the same. Your children count probably maxes around 7. The new resources get a title from their level in the tree, along with some arbitrary suffix signifying their responsibility scope.

This is also the same with responsibilities. As you gain too many, eventually you’ll force a split and push the responsibilities onto your children resources. If there’s none available with time/ability to do it, you pull in a new resource directly reporting to you. As that new resource takes more responsibilities, he ends up creating his own tree..

And then for top-down titling (eg appointing a CFO in a company of 5), it’s mostly a matter of fluff/marketing. You want customers to think you brought in the big guns. In a mid-size company, it’s more about solidifying the future. People don’t question the positions existing before they joined. They question the promotions after, the promotion of a peer to the big boss of their group. So it’s a bit of a power play, though responsibilities and importance aren’t all there to really justify the titling.

What you want to do is have the smaller teams/squads be the place where new managers can cut their teeth, and have the larger teams/squads be the home for managers looking to become directors. Assuming your statement about growth startup is correct the manager will eventually manage more people and the directors will have to deal with splitting the team, re-org and potentially then managing managers.

I'd add another thing to all of this: Why have managers?

The answer isn't the reason you think. It's not project planning, co-ordination, etc. Books like "Turn The Ship Around" or "The Effective Engineer" show how engineers can more fully own their role and not need micromanaging, and the benefits of that.

The reason for managers is different: Let's say that every 3 years a person has a life event. A life event is defined as something big, traumatic, emotional... both the ups and the downs: Birth, marriage, divorce, death, home move, home renovation, moving country, etc. In your startup of 10 people 3 such events will happen this year... and as a leader you can get involved and help support people. This leads to better retention, no loss of institutional knowledge, improved morale, improved loyalty (we're all human and when someone looks out for us we look out for them).

What happens when you have 100 people? ~30 such events this year. But each is large, will last many months and need a lot of support. Potentially you're now going to have 20 concurrent life events to manage.

At 500 people? ~160 such events to manage each year.

Managers and the People team aren't critical to your success, but their absence or a poor setup is absolutely going to be a large factor in the demise of your startup. The earlier you can structure the organisation to absorb these life events and really support people, the more likely none of this impacts your startup.

Then... once you have managers in place, great... there's a lot of spare capacity there to do more than just wait for the life events to occur. Now you can look at books like "An Elegant Puzzle - Systems of Engineering Management" and look to be a value-add to your team, supporting your engineers on a daily basis to be happier, healthier, more effective. Managers now can help nurture and grow senior engineers, help juniors find traction within their career, etc.

Who helps push tools and services through procurement? Who spends hours working with HR re-working career ladders so engineers have options _other_ than becoming a manager once they reach a certain level of seniority? Who is your voice in the leadership team when they don't get what you do and just see you as a high cost? Who explains to senior management why that high cost is worth their money?

Speaking of "not doing real work", who do you think bargains to give you time to deal with that tech debt, instead of being death-marched to ship feature after feature? Features make money, right?

You think all that just happens automatically?

I was a hands-on coder for 2 decades. Now I've decided I want to spend my time helping developers earlier in their careers make the most of their time and their skills, I want to help them enjoy their work and grow their careers in a way that I couldn't do because the field had not matured as much as it has now.

But sure yeah, I'm not doing real work..

Also, some of the work a manager does is invisible to the people they manage. In fact I would argue that the "good" work is often the most invisible of all the work.

So when that role, at some level, is responsible for you being able to do your work, whether you see it or not, calling it "not real" feels even more naive.

But yes, there are absolutely bad managers out there. I agree with you on that.

This is just another version of the mantra often seen on HN that the "silent, behind-the-scenes" dev work of refactoring, maintenance, etc. is extremely valuable but under-acknowledged.

The same holds for all levels of an organization, whether it's the CEO or a straight-out-of-school IC, but we seem to keep forgetting this principle when presented with a new face.

But my ICs don't see all my work, just like I don't see all my director's work. So it's still somewhat asymmetrical.

So it's easy to fall into that "they don't do anything of value" trap when you don't have the big picture.

I believe that this is why as a manager it's actually super important to be transparent, and where possible (and desired) provide as much of a view into my work as I can for my ICs..

Some stuff I can't share of course, but if I can, I do. Hopefully this helps everyone in the end.

unlike engineering, there's not really any formal "engineering manager" education. so it probably boils down to incompetence.

In my early career, I never had any managers, we were just "the developers" and left to figure stuff out on our own..

But in the last 5 years of my coding career, I had some excellent managers who really helped me grow and do my best work, which is what inspired me to go that route myself and try to do the same for other developers who are earlier in their careers.

I will say, there actually is formal management education. It's just not often a requirement for promoting developers into management positions, and a lot of time the people who get put into those manager positions are either the least-good coders, or people who don't want the job but take it to get the promotion and (maybe) salary increase. And once they're in the roles, they are not properly trained or supported in the new skills they absolutely need to do a good job.

That's not a recipe for success... but it's also an organizational problem just as much as an individual problem.

at the risk of sounding exceptionalistic, I think managing engineers is a different beast than managing other roles

You could apply this logic to any practitioner discipline, like medicine, research, sports, construction, cooking, etc..

Of course someone with practitioner experience will be (or appear?) better able to manage people doing that work, because they understand the finer details.

But people management itself is also a learned skill, and that's where in my experience companies fall down on the training sometimes. They assume that the practitioner experience and the seniority is enough, and it's not.

Then there's the whole empathy/EQ side of things. Being a manager requires a ton of emotional labour and that's not for everyone.

Same. Additionally, "management" seems to be the path chosen by the most incompetent programmers to try to salvage a career.

It sounds a bit like you have a good gig that you enjoy, good for you, but you can't extrapolate like you are. You are being a bit ignorant, frankly, grossly generalizing a career it sounds like you don't understand well.

While there have been a few who weren't completely toxic, the vast majority had no idea what they were doing, struggled mightily, and had very unhappy teams.

> You are being a bit ignorant, frankly, grossly generalizing a career it sounds like you don't understand well.

Yeah, I do understand it well. I had some management experience early on, and was actually good at it, but I hated it because it made me stop doing actual software development.

Yes I do, because no one has ever done that any place I worked.

If you're doing all the stuff you claim, then I tip my cap to you.

I guess all I can say is there are good and bad managers out there just like there are good and bad engineers out there, or in any job title.

Maybe an idea would be to use the list I made to formulate some questions for your next round of interviews, to get a better sense of the management culture of the places you're applying at, on top of the engineering culture.

Happy to discuss my experience and give further pointers (although I certainly don't have all the answers) if you want.

Contact info is in my profile.

True. I see far more bad managers than bad engineers, though. Bad engineers get weeded out early. Unfortunately, in many cases, that moves them to being managers.

> Happy to discuss my experience and give further pointers (although I certainly don't have all the answers) if you want.

To be blunt, why would I want to? You previously mentioned being a 20-year hands-on coder, then made a late career switch to managing. Do you really think you've already learned enough and matured to the level of being consulted as an expert or resource on this?

I never professed to being an expert, but I've been in all corners of our industry, from a tech lead in big org to a consultant to strategic leadership (CTO-type roles in small companies) to freelancing for large enterprises. In all those roles I was doing some portion of hands-on coding, but it's only in the last 3-4 years that I don't code at work anymore. I still code plenty in my hobby time though.

I offered because, to be blunt, you seem to have a very narrow/naive view of the industry we work in, in my opinion.

And it seems to be to to your detriment (you seem bitter about a lot of things), and I thought maybe a different perspective would help.

But fair enough, we can leave it at that. Best of luck!

At a rough guess, you would have switched around age 42. That's late career by just about any definition.

> I've been in all corners of our industry, from a tech lead in big org to a consultant to strategic leadership (CTO-type roles in small companies) to freelancing for large enterprises.

Jack of all trades, master of none.

> I offered because, to be blunt, you seem to have a very narrow/naïve view of the industry we work in

Naïve? No. Cynical? Absolutely.

> in my opinion.

It's hard to give that a lot of weight considering you've got 3-4 years in this sort of role.

I'm not sure why, maybe you resent my career choices or simply don't agree with my viewpoint and are choosing to take a stranger's opinions very personally.

Either way, I apologize if I said anything that offended you.

Have a good one.

Well, to my eye, you started it. But if you didn't intend that, then I apologize for misunderstanding.

> I'm not sure why, maybe you resent my career choices or simply don't agree with my viewpoint and are choosing to take a stranger's opinions very personally.

I don't care about your career choices one way or another, I just don't understand them. But it's your life, live it how you choose. If you can be happy as a manger, then fair play to you.

I know we've been going on for a while, but surely you remember making that hyperbolic statement at the start?

I took the time to itemize the things that a manager actually does, more time than you spent just making a throwaway offhand comment about a whole profession.

I never took any shots at you, I only reacted to the words you wrote and gave you a different viewpoint, but you come back with shots at my skills, my experience, my career path, etc... you made it personal for no good reason.

You don't see that?

Maybe self-awareness is something else to stick on your personal roadmap.

That wasn't to you directly, it was to OP. You felt compelled to take it personally, though.

> I never took any shots at you, I only reacted to the words you wrote and gave you a different viewpoint, but you come back with shots at my skills, my experience, my career path, etc... you made it personal for no good reason.

Seemed like it was personal, with you essentially offering counseling and guidance with "Happy to discuss my experience and give further pointers (although I certainly don't have all the answers) if you want." Pointers? What swaggering arrogance from an essentially new manager!

And also this howler:

> Maybe an idea would be to use the list I made to formulate some questions for your next round of interviews

As someone else mentioned, "It’s a little telling that 90% of what you describe is undoing the actions of other managers." I agree, and to me that means you're part of the problem perpetuating a broken system.

> Maybe self-awareness is something else to stick on your personal roadmap.

Perhaps you should take this advice, before feeling that you can advise others.

Most managers exist because most people believe a team has to have a manager, and that creates opportunities for many people.

Many engineering managers dislike software engineering, and sometimes even dislike engineers themselves.

The idea that somehow the people "at the top" should have complete understanding and appreciation for all the details of all the roles under them is unrealistic.

It is actually part of the job to advocate and bring the relevant understanding up the chain, and believe it or not, that knowledge is welcomed and appreciated in many cases.

And you may have assumed (perhaps I did not write it well) that this knowledge is received grudgingly, but it is not.

Good senior executives appreciate context and details (it is a skill to know which details to give), and it helps them make the right decisions. But companies are webs of competing priorities, and you don't get what you don't ask for.

Features vs. tech debt for example is a good one. Senior management wants to make money (so we can all keep our jobs), so they want new features. That makes sense to them. They don't really get what tech debt is, because that's not their department, it's ours.

So we explain why it's important to tackle tech debt from a business perspective, and long-term product health (security, performance, developer happiness, etc).. And then that helps them see the value of that work, and it allows us to prioritize it alongside new features, because now they understand why it's good for the business.

If no one explains it to them, they won't know what they won't know, and they will just keep asking for features.

Building something past a certain scale requires people to work together and building a system of people working together is just as much an interesting challenge as building a computer system of components working together.

They could have replaced Vannevar Bush with another manager, it would have been much harder (if even possible) to replace Oppenheimer.