Show HN: I wrote a book for engineers that want to become engineering managers
Last year I was fortunate enough to sign a deal to write a book with my favorite technical publisher, The Pragmatic Bookshelf.
When I started out as an Engineering Manager many years ago, I found that there wasn't a huge amount of material that specifically and practically helped me understand how to do my job. When you learn to program there's all of these amazing tutorials, examples and guides, but what was there for new managers?
In response to this, a couple of years ago I started a blog over at https://www.theengineeringmanager.com which got a decent amount of traction - I had a few front-pages here too, which was awesome. I improved a lot as a writer.
This gave me the confidence to pitch a book to numerous publishers and thankfully my ideal choice wanted to work with me.
The book has now been released in beta, which means you get DRM-free access to the first 240 pages (13 chapters) and more chapters will be pushed out as they get finished. I've written 17 out of 19 of them so far. The hard copy should be out in the Spring.
It's available with free excerpts here: https://pragprog.com/book/jsengman/become-an-effective-softw...
If anyone's at all interested in learning about what it's like to pitch a publisher with their own book idea, then I guess I've been successful at that now, so I'm more than happy to give you any advice. I've had a great time working with PragProg and my editor and the other staff there have been (honestly) fantastic.
I'd love to hear your feedback, and the nice part about the beta process is that the book still isn't finished, so there's plenty of scope for improvements.
Thanks all!
244 comments
[ 5.3 ms ] story [ 257 ms ] threadWill we get the updates if we buy the beta version?
That's a good point though, and I do mention it in the book. I talk about how when promoting people it's good to define a 30-60-90 day plan (although there are many similar frameworks) and bake in a "no bad feelings" back-out clause if they don't enjoy doing that particular job. We've had that happen at our company numerous times.
Additionally, in the later chapter on defining management and individual contributor tracks, it does talk about levelling them in a such a way that allows mobility back and forth. People shouldn't get stuck going through the one-way management door. It's perfectly fine to go back (even though it's not really "back", it's just "across").
However, I think that I could use a sidebar to the reader to allow them to further question their own motives, and help them make that decision more clearly.
I definitely feel the lack of management training.
Being a nerd for decades doesn't mean you know how to lead a bunch of nerds ;)
I don't enjoy long-winded, pointless meetings - but if you're organisation has so many of them, you'll get pulled into them anyway once you're senior enough.
I think the "secret" is simply to make sure people know what they're suppoesd to be doing, that they want to do it, and that they feel they have everything they need to do it. That won't necessarily always work, because not all under-performance is work-related - if you've just had a baby, going through divorce or bereavement, I'd expect you to be 'under-performing' and wouldn't try to fix it.
If you do want a chat, I'm available on email (it's on my profile page).
- Do you have autonomy in your job ? You need to be able to do your job without having to ask for permission every five minutes. You should also have some freedom on how to do it.
- Do you feel you are getting better at your job ? Every day you need to have the feeling that you are becoming better at it. Is your job hard enough but not too hard. Too many unknowns may cause frustration. Too few unknowns make the jobs too easy and boring.
- Purpose - Do you feel that everyday you are making a difference? You need to feel that you are making somebody's life better.
to be fair tho, i don't expect most tech jobs to actually have a strong sense of purpose. it's that old SV trope of "we're making the world a better place through minimal message-oriented transport layers".
#2 is a great question. its kind of like looking at the job through game design. its true i dont feel like i'm becoming better and i dont see a clear path to becoming better. I will probably actually use this line of thinking to have a convo with my manager.
If I could do it all over again, I'd completely omit the technical from my decision making. Odds are that you're probably doing just fine and suffering from something like imposter syndrome. In my case, my billable hours had started to fall, which is the one thing that can't slide for long. I was having doubts about my project and my contribution to it, for personal reasons stemming from my financial troubles after the housing bubble popped. I should have asked for a sabbatical.
Maybe you can step back for a moment and imagine that if the technical needs of the project are being met, what is your vision for the future of the company and the prospects of the other employees? Have some of them been snatched up by Fortune 500 companies? Will some of them benefit greatly by having your company on their resume? Have some of them been able to grow as individuals, perhaps continuing their education or even finding happiness and love? If you feel a resonance with those types of things, you might be surprised to find an interest for it reflected in your own bosses. Maybe they are focused on making payroll and haven't had the support they need to consider those other things. If you have an HR person, maybe you can sway the conversation in those directions. If not, maybe you can talk management stuff long enough that people start to want you in that role. Please don't underestimate vision like I did.
i have rarely had a helpful convo with an HR person though. always hear the warnings at the back of my head that they're not on my side, they're on the company's side.
This is a pretty nice approach. Congrats.
Often people are chosen in senior positions because the sell themselves. They are articulate and have "executive presence" and they seem to know what to do, but often they don't. I wish more of them were chosen because they listen, and they knowledgable and thoughtful.
Moving from tangible daily outputs (code etc), to longer term feedback loops can be just as rewarding, you just need to step back slightly.
Empowering others to achieve their potential, watching them grow. Watching great products evolve. Understanding and directly influencing tech decisions. Being able to look further than the next sprint. Interfacing with external parties, seeing how they approach similar / new problem spaces.
IMO, this never gets boring.
Keep a log throughout the day. It helps.
Failing that, use email, issue trackers, repos, purchase orders, inventory logs or other major communications channels / process interfaces to retroactively summarize progress. I currently do this weekly, and use it as input to reporting and planning processes.
A more senior leader I very much respect - when I was about to make the transition - put it this way: "I was doing great as an engineer but had so much I needed to get done, so they helped me put together a team of 4, which was great, because I could accomplish almost twice as much; then it was 30 people and we had a whole product I was proud of. With 200 I know I'm changing the industry..."
You have to learn different skills - how to motivate people, how to see potential conflicts and roadblocks and use them constructively - but the technical skills you bring to the table can make your impact much stronger; and I think I get to learn new ones at a much faster pace at a compromise that I can't go as deep in more than a few spots compared to full-time engineering.
However - if you don't mind - I would love to use those as examples in the final chapters where I mention the opportunities offered by moving into start-ups, and also where our managers will be given more autonomy to set the culture of a wider organization (of which that culture could involve much looser management structures).
Great pointers, thank you.
There are still roles that resemble the classical management role, i.e. there is a role that is responsible for setting strategies and assigning people into roles and monitoring role fit within their 'circle' (think team or business unit), called the circle's lead link. Yet there is a process for any role holder to propose putting those accountabilities into a new role or into a process. Role holders can also propose the creation of new roles or policies if they feel a tension. Then there is a structured process to deal with these proposals, and people need to demonstrate that the proposal would cause harm and reduce the capacity for the circle to achieve its purpose in order to have a valid objection. People in roles ultimately have ultimate autonomy on how they want to achieve their role's purpose. The lead link role can give relative prioritization if there are conflicts, but the lead link can't say 'you have to work on this right now and this is how you gonna do it'.
What ultimately happens is that the traditional accountabilities of a manger end up being distributed across multiple roles, so people might have software developer role, but might also be responsible for defining the hiring standards, or do people development etc.
It's kinda similar to the book "Turn the Ship around" where you don't have to ask for permission to do something and there is a process to address any tensions that arise from this power to act autonomously.
I tend to assume that everybody else in the company knows that my team works in the way it does because that's how you deliver software successfully. Often, this comes back to bite when I learn that other managers think the team should be managed differently, and because I haven't made enough efforts to sell our methodology, those managers can have more influence than I'd like.
So, as an Engineering Manager, it's not enough that everybody in your team is happy and produce. You also have to be an advocate for your team to the rest of the company.
As an example of something I personally struggle with: what's the best way to have the rest of the company know what all of our teams are working on without A) going into too much detail B) being obtuse C) opening ourselves up for miscommunication to customers or deadline promises D) giving ourselves room to fail, because not everything will work out.
The current iteration is a fortnightly newsletter that I curate between product and the engineering managers in the department and it gets sent around, but making everyone happy with it is /so/ hard.
I like the idea of the newsletter. Do you focus mostly on achievements, or discuss 'ways of working' as well?
I'm really looking forward to the book, by the way.
The target audience for the newsletter was decided as "the busy exec". Not too much text, lots of gifs of functionality that we've built, etc.
There's some separate newsletters we do as well - there's a fortnightly "what's going on in the backend" one, curated by our infrastructure teams that's aimed at engineers.
Currently the general case newsletter goes to Engineering, Product, Product Design, and the exec group. We don't think it's quite good enough for the staff@ mailing list yet, but maybe we're just being over-cautious. It's really hard to get the balance right.
In my experience, newsletters don't work well for internal communication. As you said, keeping the content relevant to a wide readership is too difficult. It does, however, work well as a recognition mechanism. A team seeing it's achievements blasted out to the company is very motivating, even if they are the only one's who notice it.
The "outwards" part is teaching your team the right ways to evangelize to people on other teams at levels below you. They'll almost certainly be interacting with engineers on other teams, and the quality of these interactions is greatly enhanced with a combination of good documentation and good presentation skills.
This is so important that it doesn't really matter how good of a job your team does as long as they can talk about it in a positive way and work effectively with other teams. All of your "good engineering practices" should be geared towards enabling this kind of culture because the technical deficiencies in your code don't really matter.
This makes me feel bad about my past behavior. I've walked in on past managers when they've been talking about my accomplishments or background with other managers or company owners. My instinct, and the way I was raised (military family), is to play it down and be humble ("eh, it was a team effort", or "I was in the right place and right time") or make some self-deprecating joke, but now I can see I was likely (unintentionally) undermining my boss.
I had already realized this wasn't a good idea the last time it happened, and resolved next time to just smile and say thank you or something similarly neutral. However, this comment underlines how bad of an idea it is to play down your successes at work, even if it's in your nature (I've also had people openly tell me to be careful about this re: my own career).
I just can't stand people boasting about bullshit at work, and want to avoid coming across like that. But I'll be more careful about playing down my own successes now.
I’m going through this right now at my company, and it’s completely devastating our engineering org’s morale. I’ve never experienced anything like this.
Managing expectations is hard. Everyone will have different expectations of you unless you handle it for them.
https://www.theengineeringmanager.com
https://pragprog.com/book/jsengman/become-an-effective-softw...
You need to really want to manage and develop people (with all the idiosyncracies that real human beings come with!), and to communicate, co-ordinate, and delegate for a living.
Some will love this, others hate it. But don't view it as a natural progression that will work for everyone.
It is a different role, and not merely a coder who tells people what to do. It has a different skill set, and some people will fail at / only muddle through it just like learning a new language or tool.
If you don't like dealing with people's problems, enjoy solving the problem at a detailed level and being quiet and working things out on your own, then management may not be for you.
There are companies that reward talented individual contributors as much as good managers, but they are rare. Also I would say that an individual contributor needs to be quite good to match a mediocre manager's salary, unfortunately -- but that's how the hierarchy is generally set up.
> Clearly, the way to more money in the long run is the manager path even if you find it horrible.
Gotta break this down. How much more money would one need to make justify having a shitty time 40+ hours a week?
I would actually be okay with doing this, if it were an option. I believe it is not, due to how ageist tech hiring is.
The scam is that every retired person is going to get every dollar they have promised to them and they are still going to wear rags and eat cat food.
Could this actually explain why a lot of people don’t like their managers? Because they are just too damn inexperienced.
Re: knowing few staff or principal engs, my personal anecdotal observation (and other people have told me the same), is that many engineers don’t change their titles on LinkedIn, or say they are “staff eng” etc in public. In fact, for some people, the higher they go the more they downplay their title in public. Don’t have data to back this up, just anecdotal convos with some people I know.
I’d also like to think the culture is slowly changing, about feeling forced to get into people management to progress your career. But that could be wishful thinking!
that's exactly why! i've worked and had managers who were so green and bad at their job. the staff engineers that i worked with were older folk that really have been around the block and had better communication skills than the managers. it's all extremely backwards
What's hard about firing people? I actually don't know and would love to find out if you could share your thought
This is flipped on its head for things like abuse where the company could be liable for not responding to reports in a timely manner. Cross a line behavior-wise, and you can get fired quickly.
If a team hits their metrics a good (super-) manager knows if it’s because of the manager or in spite of them, and vice versa.
What we really need is to train people to be better at identifying these organizational concerns, and set the right incentives, so that people choose to be Engineering Managers for the right reasons.
Edit: and to answer your question directly, in a healthy org, it’s definitely possible (and in fact in some very rare cases easier) to fire your manager than for them to fire you. Also depends on the level of trust you have built for yourself as in individual contributor.
If you can do interesting work and use your team to help, it's great. The problem with management IMO is all the politics, "managing expectations" (I think this term must have been coined by some hardcore sociopath) and team quality.
You rarely have team of senior experts only so you can focus on doing great job. You have people underperforming, having issues with others etc. Also, employee personal agenda is often more or less different from company goals - it's a constant battle.
Do you like the idea of managing people, setting goals, spending time thrashing out plans with colleagues where your team, not you, will do the "work" - or are you simply preparing to tolerate all that for the extra salary and perceived career progress?
Honestly, it's not a trick question - you might really like all that!
The most common reason somebody becomes an EM that I've observed is because somebody else tells them to do it. It's a promotion, so you should want it. I'm one of very few people in the SwE world I've encountered who very actively and clearly wants to do it, and for the reasons you listed - to spend more time on humans and less on code.
Most of my managers have at best tolerated the position; several have confessed being miserable and just wanting to code again ("okay, let's switch" hasn't worked, though). That includes my current and previous manager; the one before those 2 said he didn't want to manage and despite being CTO was trying to maneuver into more of an architect position, the one before that quit within a month of being promoted. I've known several people who were EMs and switched back, and had a friend confess that she was on the verge of quitting before she got offered the chance to be an IC again.
Not a one who got promoted and then loved it.
Given that it's true most ICs want to code and not manage (even if many can learn to be good managers), and these days big company ICs are very well compensated... it really feels like the driving force is external - somebody else tells them to do it, it looks like the natural progression, and that's "just what you do" more than anything else.
At first I really disliked it but the more time I spend doing it, the better I get at it, the more rewarding it becomes. I fear by the time I find someone to actually replace me, I won't want to go back to being an IC.
Very few of the skills overlap even within the same categories such as architecture and execution. One is about the code, the other one is about the people.
Once the core skills are developed e.g. being able to clearly communicate a vision and plan, ability to have tough conversations, building interpersonal trust, being an effective salesperson for the team. Once these skills are adequately developed, it becomes a good job again.
Most people have spent at least a few years training to become a professional software engineer before being able to do that job, and yet most engineers don't give themselves/others the same understanding for developing the necessary skills to become a professional engineering manager.
That is the difference between being a renter in SV for the rest of your life versus being an owner. It'd also set you up for retirement and potentially let you be a single income household.
One thing: the description starts with "Software startups make global headlines every day". That line seems completely disconnected from the rest of the description and it seems nothing would be lacking if you started with the next sentence instead.
And for me as a Swede the most alien thing for me is the "lone genius startup"-thing (that probably is very over represented/emphasized here at HN) where developers work for stocks(?) and hope(?) that the company will blow up and seem to take great personal risks. Of course that exists here as well in small startups but we have so strong work force-regulations that I don't think it can get that extreme. And now that I think of it it might be that we are the odd ones so maybe it's not so much u.s. vs. e.u. as u.s. vs sweden. ¯\_(ツ)_/¯
I've bought the book and read until the Delegation chapter.
Up until now I find that the topics are interesting and the writing is very direct and unpretentious which I appreciate.
I also like the approach you took of wrapping it in a story, I think it makes the topic a lot less dry.
At the same time I feel that it doesn't go into the detail I would like.
For instance I feel that the “How to Measure Your Output as a Manager” is a bit hand waved by using Andy Grove's equation. This is a topic I struggle with because I sometimes feel that I don't produce anything as a manager and that is frustrating.
Nonetheless, the chapters I've read are fine as a starting point and appreciate that you suggest additional literature to deepen the topics.
Overall I'm positive about the book, would buy again :)
Although, it may never top your blog circa 2001, it's a fine achievement nonetheless.
Upper management in different companies would have different expectations from what an engineering manager should be. Some would want them to code, some wouldn't. Some would want them to utilize developers as much as possible while some would want them to keep work life balance of developers in mind. Same with teams. A much younger team would have vastly different views on what a good manager is compared to a team which is filled up of more senior people. A younger team might want the EM to be more hands-on while a senior team would want more autonomy. Then you also have HR and feedback from various teams to deal with. Company culture and popular managers would also drive some of the traits of an engineering manager.
Having been an EM for multiple teams I've had to change my management style multiple times to better suit change in higher management and different teams. But I've always been appaled by how less content exists for learning about engineering management. Nice to see someone focus on this area!
Some organizations want them to engage with end users and do a lot of business analysis others want them to focus on coding.
Some organizations want engineers to follow protocol and coding guidelines to the tee. Other want you to make the right call for the circumstances.
Some organizations don't care how long something takes but want it to work perfectly. Others want to make sure you deliver a product on time even if it's buggy.
Some organizations expect you to always choose the right language/tool for the job, some want you to choose the organizational language/tool everyone is familiar with.
I'm a consultant and sometimes run into this issue. Building out an MVP for a start up is a completely different mindset than working on a fortune 500 Enterprise app.
I studied Civil Engineering many years ago and was a grad. member of ICE. I'm not an Engineer or an engineer of any sort these days.
Nowadays I'm just the MD of my company.
https://afoo.me/books.html
https://apps.apple.com/us/app/team-lead/id1466421445?mt=8
https://play.google.com/store/apps/details?id=co.jmoses.manu...
Really? How do I contact you?
Here is a pattern that I've observed over a few jobs that I've held as a developer at different companies. Wondering if anyone has any similar experience.
The first line manager (only manages individual contributors) exhibits these characteristics.
1.)He used to be a coder, but that was a long time ago. SQL hasn't changed, so that's the bit he's drawn to when he feels like he needs to roll up his sleeves and contribute.
2.)He has some form of attention deficit, demonstrated by the fact that he can't hold down a conversation really well. Especially if it gets technical.
3.)He really overplays the busy body persona. Always checking phone, always late for a meeting.
4.)He's really insecure in his position within the company, always fearful that he's going to be cut loose. This is extremely amplified when he gets a new manager himself.
5.)He has very little influence over direction. He's really just a proxy mouthpiece for higher level management. And he loves to have status update meetings where he informs the team of all the important updates he received in the big important meeting he attended with other big important people.
6.)Instead of being someone who is respected by the team, he becomes more of someone you have sympathy for.
7.)You wonder why he never asks the real questions, like "are you happy with your role?". And you realize it's because he doesn't really want to hear the answer. He couldn't really do anything about it anyway. See point #5.
8.) He's way too preoccupied worrying about his own safety to nurture the team.
9.) As a developer, you have the safety net of knowing that in the worst case scenario (terminated) you could find another job fairly quickly with pay parody. As a manager, you don't have that comfort blanket. So you cling on to your current job no matter how badly you are abused. And people lose more respect for you because you look pathetic without a backbone.
10.) As a cynical developer in his 40's, you realize that you don't observe many 50+ developers in the wild, and you bemoan the idea that you're going to have to suck it up and play manager eventually.
Anxiety and existential crisis is built into the tech career trajectory, and I feel like the only winning strategy is to be ok with moving backward income wise at various points in your timeline.
Leadership is a skill like any other. You can't just promote someone into it. They have to be trained for it.
1) I was given a few opportunities by the partners to step up into a management role, but in hindsight, I was too knee-deep in code to see what was happening, so I doubled down on keeping my nose to the grindstone rather than stepping back and thinking more about how to change the workflow so that others could come in and contribute. The symptoms of this were things like: I never got invited to any public-facing events, team building exercises or drinks with the partners when they were in town. I think they viewed me as a big fish in a small pond, someone to be utilized but not groomed. They came from a big city hustle mindset whereas I came from small town America. So different value systems, not necessarily superior or inferior, but at high risk of miscommunication.
2) When they finally promoted the other guy to a management role, he fell into the exact sequence you enumerated. He was highly disciplined and methodical, but sometimes had blind spots about different local maximums in the search space (had trouble seeing the forest for the trees) and was a bit too focused on maintaining the hierarchy since he came from a military background. I admired his tenacity, but truthfully, it had a tendency to wear on the developers (several of which had an antiauthoritarian mindset like many in tech).
3) When he moved on, a void was left that was never filled. We ended up changing over to nontechnical project managers, which worked well for about a year, but inevitably the agency drifted towards enterprise work, which is not my cup of tea. We had a bit of a falling out and I moved on. I still wonder to this day how things might have ended up differently if I had stepped up and basically listened to the universe and manifested whatever the next chapter of my life as a team lead or manager was going to be. I would have been a highly egalitarian manager, working for the team as much as for the partners and clients. Now, I dunno, I'm not sure that my heart is in software engineering anymore. I'm focusing on the gig economy and attaining some financial independence outside of hierarchy so I can finally work on projects within my own calling. As a 40-something this is scary but rejuvenating.
> pay parody
Definitely at a startup.
Most of us would be looking for pay _parity_ :)
I think for someone considering engineering manager track your point #9 is really something to keep in mind. Many managers I've met are well aware of the fact that they're simply unemployable outside of their current company, which essentially becomes a "prison" for them.
I've even had past managers they had no worries about me having the skills or knowledge to do it... but it still doesn't happen.
Personally, I got promoted from within at the beginning of my management journey. Have you been applying to external companies? I wonder if others on here have more experiences in that area that they'd like to share.
I have tried this on a limited level in the past, and either get no response or get told that I don't have experience (I have a few months with one direct report)
You're right about the other bit, though. Even as the most knowledgeable and senior person on the team, I do have something of a habit of letting people who are loud derail me from my ideas (or simply talk over me), which can damage perceptions. It's a thing I try to fight every day, though.
I tend to get talked over as well, but it’s a slightly different subject. To clarify I mean that you solve problems without being asked. As they say about actions and words.
Incidentally I've never seen any of those things. At most of the smaller companies I've been at I've been the most senior woman simply as a senior engineer. Reporting to a woman sounds fantastical. I know it happens; I know a couple of female EMs at my current (bigger) company. I've essentially never had a woman in my reporting chain outside who is in the engineering org. (Across 7 jobs and about 15 years of career).
I tend to dress the part anyway and have had interview candidates assume I was the manager and my EM was the IC, but it hasn't been helpful outside of that. At worst, it can cause people to assume I'm non-technical, so it's a dangerous game to play.
That said, you do need to unlearn a bunch of stuff. You have to (at least pretend to) be confident, do things without permission, be self-motivating, etc. It's going to be very difficult to manage people and have them take you seriously if you can't get yourself to do those things.
I've been in a Technical Leadership position for about 10 years, with the last four having an explicit Manager title. If I were looking for someone to groom as an EM, that person would at a minimum have to show a strong level of initiative. You don't need to be "bossy" but you do need to be able to assert yourself while still considering alternate points of view.
I can point out some of the things you need to be, but I can't tell you how to get there.
You're right about unlearning behaviors, though easier said than done. I'm relatively self motivated when I'm not interfered with, but when I get negative feedback can easily get stuck in an analysis paralysis loop trying to figure out "what does my manager want me to do?" It's not a good sign when I'm spending time on the question of if I should even ask him or if that will be perceived as me not intrinsically knowing which will reflect badly on me.
And all that stressing about what my manager wants or how a given action will be perceived looks like laziness at best.
I'll admit, part of what I want out of being an EM is external validation that somebody trusts me to lead something. I've had a lot of bad experiences that really undermine my confidence and make me question myself.
An example: at my last job, I had a coworker who made it his personal mission to slow my velocity as much during code review as possible. One of the more egregious examples - he told me to consider using a regex rather than == to evaluate equality of strings. No particular reason. What resulted was an hours long argument... his main justification was that if I had just spent an hour to benchmark it we could have found out faster than the argument took.
You can imagine how when even extremely basic decisions of yours like that are routinely questioned it sucks out your confidence. The lead of that team explicitly had no interest in mediating this ongoing problem, and eventually promoted that guy to be the team lead so he didn't have to manage it. I meanwhile had to plan all my code around the times he'd be out of the office; I could get a month of work done in a week he was out, because somebody else would review my code. I got a reputation for missing estimates, but my timelines were entirely driven by code review cycles and thus at his whim and availability.
And yes, I repeatedly asked to work with literally anyone else, and it was only when I threatened to quit that anybody at the org actually made that happen.
There's a long history of stuff like that happening to me, and it means that I tend to just wait for somebody to tell me exactly how to do whatever it is, because the way I will do it will be seen as wrong. Who can forget the manager a couple jobs before who admitted to creating fake crises and yelling at us over nothing to keep us motivated?
This org is the first one that has actually respected me enough to do more, and where my manager's main complaint is that I act like I don't have any power, when I do. Everywhere else, it felt like they were really trying to make sure I didn't get any, and it's tough to unlearn.
1. What type of product/service has your team been building?
2. What did you do when 10 non-permission-seeking engineers went off in different directions doing their own things?
2. If you're managing people you should know what they're doing, and immediately correct this behavior. I'm a big fan of the phrase "stop doing that" because, yeah, it happens. By now my team knows that they have agency, but if they deviate from the plan to let me know.
In fact, my first three jobs all involved reporting to women for a good chuck of it (and they all reported to women too). Those women were all fantastic managers too. Great mentors and great empathy.
Now that I think about it, they were all promoted to management via internal promotions given to them by female managers.
So maybe one tip for you is look for an IC role that reports to a woman who is interested in mentoring you into management?
I don't know what magical place you work at; at the smaller (<250 people) places I've worked at, I'm the most senior woman as a Senior Software Engineer.
There are Female EMs at my current employer (enough that I can't just count them), but they are a tiny minority and I don't know of any at the level beyond that. It is a strategy I've considered, though... especially because women just seem to understand me much better.
Also a mentor or role model would be AMAZING.
This is apparently because of recruiting, too; we do great at recruiting from campuses, Grace Hopper, etc, and not at recruiting senior levels. Stats show women are getting promoted just as fast, we just don't get the candidates.
Do you know how you guys recruit more senior women? We'd love to know!
She may not have been a great engineer (I'll never know), but she gave us the tools we needed to do our job, shielded us from the upper management pressure and BS and got out of our way. In return, the team shipped a ton of functionality in an impossibly short timeframe that she later confessed she never thought we'd be able to achieve.
Excel at what you're good at and the rest tends to take care of itself.
One of my bigger challenges is that the older I get, the more I care about people and want to work on those issues... which means I gradually lose interest in code and pure technical stuff. The longer I stay stuck on the IC track, the more obvious this is going to become.
If you have a good manager, they'll set you up for success, working with you to create a roadmap to get from IC to Manager. The steps in between would probably entail taking on larger projects, mentoring others, leading a project with multiple developers on it, and then after demonstrating all of that, you get the promotion.
In my experience, you get the promotion when you're already doing the job. In other words, you do the work and the promotion is recognition of the work you're already doing.
The other thing I'd say is that you don't get what you don't ask for. If you want to be a manager, ask for it. If you want more responsibility, ask for it. If you want better compensation or a new title, ask for it.
Unless you have a FANTASTIC manager, you will never just magically be recognized for your work. They will assume you're happy doing what you're doing and focus on greasing the squeaky wheel. To further your career, you should be a little squeaky. Ask for what you want. If you can't get it now, ask for help getting to that point.
I, as a manager, really appreciate it when someone gives me direction on what they want. Otherwise, I have to guess or try to pull it out of them, and I feel like I'm pulling teeth. It's hugely beneficial for a manager to have proactive direct reports. Be that person.
Good luck.
OTOH, I’m also surprised by the number of managers who (1) implement something because “my friend at <massively successful co> uses <tool/process etc>; (2) don’t understand that their colleagues have lives outside work; (3) don’t realize that they’re being partial to some folks; (4) take advantage of the “meek” contributors; (5) don’t protect their team from upper mgmt when needed; (6) don’t do the grunt work when needed (and it’s always needed) etc.
In other words, just like any relationship, as you say.
If your team is not growing then you'll never get the opportunity to become an engineering manager unless your manager quits and you fill the role. That's something to keep in mind if you've been working on a team that hasn't lost or added anyone in a while.
Incidentally this strategy is why I worked at startups before this job. One did land me a lead position with 1 report, but it was when the company was falling apart and thus not the most meaningful experience. Another took the role I'd been doing by myself, and replaced it with a team and a newly minted manager... who wasn't me. I got shuffled under someone else who didn't want to manage and promptly quit, so that didn't work out either.
My company theoretically prefers senior ICs internally sourced for EM roles - it's the only place I've been able to interview for EM positions, and I very nearly got one - the hiring manager said he was set to pick me, but then they decided they really wanted somebody with deep experience at the last second.
Actually, interviewing for an internal transfer at a big company has been the closest I've come. I've also found that the big company is a lot more inclusive; startups tend to be cliquish and if you're not part of the boss's in group you will really struggle. Here, I can get involved with many things and many teams directly, so even if my boss doesn't have a job for me, I can work the network and find my place.
At least... that's the strategy I'm trying now. "We're a growing team and that position will totally be there for you a year or two down the road" applied to 4 jobs over almost 10 years without yielding any fruit. (and 2 of those companies imploded, so I didn't even get RSUs like I get now)
I don't know how common this kind of program is, but I went through it and found it really effective. I was able to build the skill set I needed while having an "out" if it turned out I didn't like management; the company gained an effective manager after training me; and my direct reports didn't have to suffer too much during my incompetent phase because they still had a "real" manager supporting them while I was transitioning.
If you can get an IC position at a company with a program like this (or at least a strong track-record of promoting managers from within), you might have more opportunities to move into management. But no matter what, it won't just "happen" -- you'll need your direct manager's support to get the opportunities as they arise, so you'll need to have an ongoing "here's where I want to go, let's make a plan to get me there" conversation with your manager.