back
57 comments
Is it wrong that these sorts of books demotivate me?

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+)?

If money is what you're after, then changing companies is the way to go.. especially right now while the market is so hot.

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.

I basically want more money so I dont have to deal with the corporate BS forever. I would enjoy helping develop people though. I currently love being able to help people with technical issues. I wonder how much I would actually be able to help people within the BS corporate constraints.

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.

Smug self fulfilling positions premised on socially engineering computer engineers.
> and at least 40% of my time would still be dev work

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 it's titled as management at the current company it looks like management to the next company. Your larger point is true but that title can be leveraged into a number of positions that are 'real' management so I wouldn't discount it.
You need to understand and speak the language of managers. If you are manager who never has had to deal with budgets the interviewers will quickly find that out. We probably need leetcode for managers. Or an MBA will help.
chances are the other company knows as well what's up and upholds the veil, if your background is in the field and you haven't had any management focused education at start or on top, your resume will give you away.
I have a business admin minor.

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...

Yep. I've by now driven three projects trough successful exits, but when I apply to leadership roles I get talked down because I'm too young and don't "look the part", so to say.

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

"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".

"ask what the budget for the role is"

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.

"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."

Yep, exactly what's going on.

One possible answer is developer burnout. How many more years of high intensity coding do you have left?

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

0 years. I have no motivation and lots of frustration.
(This is only somewhat related, but I'll try asking here, apologies if it seems offtopic.)

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.

I imagine it’s like a b-tree. You simply have more reports, until it becomes untenable — it takes more time to coordinate them than you have.

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.

Thank you for your perspective, much appreciated.
I'd go further... the average number of direct reports is likely 7-8 people, but as you want to cluster direct report by team/squad to a manager sometimes they are unbalanced as the team/squad size isn't neatly divisible by that.

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.

Thanks for your perspective. This approach could be useful to present to companies where reluctance to managers and structure are prevalent.
You can check out a book called INSPIRED: How to Create Tech Products Customers Love. It's focused on product management, but it incorporates ideas from Silicon Valley management, which should drive the structure at your early stage.
Thank you, I'll check it out.
Dang, would you mind adding [podcast] to the title?
I've never understood engineers who decide to go manage. Why would you give up actually doing real work? Whatever floats your boat, I guess.
As an engineer, do you ever wonder who keeps your path clear, who makes sure you can focus on delivery, who advocates for meeting-free days, good work practices, or explains why those conference passes are money well spent?

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..

That's what a manager should do, yes. But I think a lot of developers have had managers that don't do those things at all. And I think that's where the resentment of managers come from.
Sure, there are bad employees at all levels. I've seen plenty of bad/lazy developers in my time too. In fact I was probably on my way to becoming one when I decided I needed to do something new with myself after 20 years of coding.

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.

> In fact I would argue that the "good" work is often the most invisible of all the work.

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.

Not quite.. I can see all the work my ICs do, even if others can't (to your point, which I agree with).. So I am aware of their challenges and their effort.

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.

indeed. I've found most managers have been a hindrance to getting the job done.

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

I'm sorry you've had that experience.

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.

is there a formal engineering management education, though?

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

> I've found most managers have been a hindrance to getting the job done.

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

I am fed up and bored to death with the perpetual tooling renaissance we are having, I love programming but career software is often anything but the good bits of programming. I am interested in transitioning to tech leadership so Im not burnt out on software bullshit and can enjoy coding on personal projects at home.

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.

> do you ever wonder who keeps your path clear, who makes sure you can focus on delivery, who advocates for meeting-free days, good work practices, or explains why those conference passes are money well spent?

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.

Like I said somewhere else, I'm sorry that this is the experience you've had.

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.

> 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.

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?

Lol well I wouldn't consider myself "late career", I've got another 15 years ahead of me at least, probably more as a consultant later because I love my work and don't think I'll want to completely stop working.

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!

A minority of managers care about those things. Most managers do not care about tech debt or advancing the careers of people.

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.

It’s a little telling that 90% of what you describe is undoing the actions of other managers. :)
Ehh there are many layers of management, and the higher you go, the more detached and abstract things become.

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.

Why would you give up actually doing real work?

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.

I am one of these people, and whether I was doing "real work" or not I can guarantee that I had a MUCH larger impact to the product & company while in management (growing the team, setting goals and finalizing roadmaps, assessing priority of different tasks/bugs/features, incentivizing and rewarding engineers) than I did coding and resolving Jira tasks all day.
I'd wager that most of the people you ever managed would consider that "larger impact" to be a negative one.
There are various reasons. A big one is money (in most companies higher salaries are reserved for managers), people may also get bored with coding over time and creating and managing a good team can also be fun.
I would argue Vannevar Bush was more instrumental to the Manhattan project than Oppenheimer was. This is a pretty dismissive take on what "real work" is.
> Vannevar Bush was more instrumental to the Manhattan project than Oppenheimer was

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

Scientists will self organize; but managers alone will not invent atom bombs.