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'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 :)

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.

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

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

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.

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

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.

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.

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.

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!

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.

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.

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.

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)

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.

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.

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.

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.

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.

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.

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)

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

Biggest lesson learned: you're no longer the decision-maker on your technical stack. Your team is responsible. Still, you’re liable for the result and its impact on business. That duality is hard to reconcile for former engineer. The solution? Build a culture. Better: create the conditions for a sustainable culture to emerge and persist.

That insight, and many other advices for new managers are compiled at: https://github.com/kdeldycke/awesome-management

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.

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.

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.

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.

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.

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.

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.

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.

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.

Leadership is a skill like any other. You can't just promote someone into it. They have to be trained for it.

> pay parody

Definitely at a startup.

Most of us would be looking for pay _parity_ :)

https://apps.apple.com/us/app/team-lead/id1466421445?mt=8

https://play.google.com/store/apps/details?id=co.jmoses.manu...

Maybe this needs to be a new book?

Seriously, all of this sounds wonderful - and thank you (but I would love to hear some tips on getting a book published from zero - I certainly write enough that I could probably fill a book, whether anyone would read it though...???).

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. ¯\_(ツ)_/¯

- Leading people is 1000x less fun than coding

- Leading people makes your more money than as an avg coder

- Leading people too long makes you lose your technical skills slowly

- At some age and for most, there's no other option than leading, 'go or grow'

- Leading bigger headcounts is comparable to competitive sports 24/7 and shouldn't be underestimated

The hardest time in my life was trying to micromanage a large group. Once you let go, and focus on the bigger picture, it's quite fun. Challenging, for sure, but very fun.

I am sorry to hear you have not enjoyed your time leading a large group. It certainly has its challenges, but I assure you it can be quite fun and rewarding.

In all seriousness, I recommend not referring to them as "reports" at all. Call them "My Team", "us", "we". It creates a sense of collective ownership.

When talking up, I use specific names, or "the team" to reference tasks or successes, and "I" when we talk about failures. I own what goes wrong, they own what goes right.

If you fuzzed around with 'my team' while I try to understand you team structure, your direct report count, their profile, which and how many reports they again have, you'd drive me nuts with a fake 'my team' humbleness.

Using the term 'report' is absolutely ok, you shouldn't talk all day long of your reports of course or trying to impressive anyone.

There are very few "rules" in this game, so feel free to manage differently. You have 100+ on your team, so I'm sure your methods worked well for you, as mine have for me.

Management is work. But so is coding. Some people prefer one. Some people prefer the other.

It would be impossible for someone to be CEO of say Google under your logic.

Sure.

> If you're the type of person who enjoys the former, I think it's safe to say you won't enjoy the latter much

This seems like a bit of a leap. People can be good at and enjoy things that are very different.

My passion is about digital creation.

I think I'd like being a manager, depending on the context. Since I like to talk and listen to people their ideas and get energy from talking and listening.

I don't get energy from coding. I do get energy from creating something awesome (either myself or with a team).

I disagree, I volunteered (edit: to step up and take on) for a manager role and discovered I loved it. I really enjoy helping built teams and team culture, helping people learn and grow in their career and abilities, and working to coordinate work across multiple teams to get work done at a scale that I never could have as an IC.

Saying that people who enjoy coding don't like dealing with people is like saying people who enjoy painting won't like programming, it is a stereotype that is easily dis-proven by the existence of people who, in both cases, do enjoy both!

This is the biggest misconception most have you have never led seriously. I like people, I like meeting people for a beer, for pair-programming, to date. Managing people is not about being with people.

As a manager, I managed my team, and dealt with a lot of other teams!

I was spending a good % of my time coordinating, organizing, and paving the way for my team to do good work. Ranging from ensuring the UI specs that got to them had been well vetted, to negotiating release schedules with other teams.

This extends even to engineering decisions. As an example, there were ways my team could implement a feature that'd save us time, but be harder for an upstream team to integrate with, or we could take more time implementing something to their requests at a cost to our schedule.

Balancing decisions like that is just as much talking to people in hallways between meetings as it is attending those meetings. It is forming relationships across an organization so that even when schedules get tight and times are tense, things don't get ugly.

For reference, we had software running on the cloud, mobile, and devices, with multiple teams at each tier.

API changes were a mess of coordination. It wasn't "send JSON" it was "round trip this in a way that can be consumed by a device with 256KB of RAM." Multiple transforms of data across multiple mobile platforms meant just locking down on field orders could be problematic if someone didn't take proper notes[1], or if a Java programmer on Android didn't understand how to properly consume an unsigned 8bit int.

Early on in the project, we had a design team that hadn't yet been trained on what 96mhz CPU could do in terms of UI. I was doing careful reviews of UI designs, and eventually was just sitting in design meetings, to ensure that by the time specs got to my team the spec was physically doable.

Another example, when it comes to performance. I was going over EE schematics to ensure there was sufficient bandwidth to push pixels how the UX team wanted. Part of my job was working as a go-between for EE and UX and explaining the other teams POV to people with very different backgrounds.

Then there is the more soft-skill stuff. Seeing months ahead of time that another team would be having problems in the future, and suggesting to one of my senior engineers that making some friends over there and getting up to speed on their code base ahead of time might be useful, so that in a few months when help is asked for he can jump in and assist.

Letting senior management down gently that their favorite feature is going to be cut.

Prioritizing what features we need to implement to show "progress" to upper management so that we can all stay employed. This often required guessing far ahead of time what we'd eventually be told to demo "next week", and having work start on it way ahead of time. These were very much "do or die" demos.

The feature work? The team sat in a pod and discussed technical implementations with each other. I trusted the people I had hired to do good work, that is why I had hired them. I had the huge benefit of having personally hired every member on the team, which is one of the things that made any of the above possible.

Then there is the actual team management stuff. Inviting engineers to the right meeting so that they had visibility, giving them a chance to speak up in front of senior leadership so that their name was known. Taking someone who I saw leadership potential in and helping them see it, and giving them opportunities to grow that potential.

Rotating user facing features around between engineers so that they all had something they could point to and say "I made that shiny thing!" Good for both morale and career visibility.

Preventing burn-out. Telling PMs that work was going to be delayed because the engineer best suited to doing it was going to be working 6 hour days on light duty because they just went through a 2 month crunch.

Ensuring senior leadership heard the name of the engineer(s) responsible when something went right, and only heard my name if something went wrong.

Managing is a lot of work, but I think your judgements about it are unfair. Managing engineering projects is a blend of technical and people skills, and there is no law of the universe that says someone can't enjoy both.

[1] Or ignored the spec sent out. Or wasn't aware there was a spec. Or we were told we had to have this working in a matter of days so there was no spec. Or there was a bug in the deserializer that ended up swapping two fields. That last one took awhile to figure out.

- usually tackle bigger problems/projects than they could ever address as an IC

- make sure their team isn't wasting time on the wrong things

- accelerate the development of inexperienced team members

- make sure that the team is more than the sum of it's parts; hopefully very much more

- avoid getting bogged down on technical details that will not be relevant for long. Some of the skills you had that will atrophy aren't very impactful, just necessary at the moment.

Some people will find those things rewarding, and may not find your 1000x factor at all realistic.

The only reason I mentioned effective at all is that I don't think it is much fun to be a (knowingly) ineffective leader.

There is, in fact, fun to be found at every level. Perhaps not for every person, but that's life.

Yes, but we are not on HN for such generic advice.

Early in my career I thought that leadership is the end goal and just great, nobody told me that it's a bit more complex. My initial comment just says, guys, it's not getting easier, it's getting harder, much harder. Now we can do a philosophical debate what is fun, what is rewarding, that challenges are rewarding (YES they are) but it's about the fact the managing people is not easy and shouldn't be underestimated, the reward structure is very different than coding and much more complex than eg a k8s cluster.

I mean just check Glassdoor and how many people there hate their boss. It's so easy to f*ck up an org if you haven't any experience.

I have managed fellow coders, but always had my hands in the coding jar. I continue to innovate, and hope to be coding the week I shuffle off this mortal coil.

I do old school desktop, C++, some C#, Win32. Just converted to macOS through Qt.

My target market is firmly entrenched in desktop, for technical and political reasons. I have Web-based versions of my app using REST, XML, and JSON, but they only constitute 3% of my sales.

I switched from COBOL and mainframe Assembler to C in 1988.

Discipline, good hiring practice and clear goals and accountability at all levels are what's needed.

Would you please expand on this point? What do you mean and how so?

I look forward to reading this, I've been making this transition so I'm sure plenty will relate to me.

A couple of points :

Is there anywhere I can pay for this in pounds?

Your choice of excerpts is very teasing, but I haven't had a chance to read any of the in depth content. Would you consider one of the sub-sections? That said, I suppose they did work for me... So maybe you know what you're doing!

The publisher is in charge of choosing the excerpts, but I'll feed that back to them.

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.

https://afoo.me/books.html

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.

Congrats for getting published!

What I find strange is that most of big cos expect managers to not be technical anymore. There is that weird expectation that the manager should have been technical in the past but is now only used as an enabler for the team.

It is part of human nature for leads to gain more than the fair share even when the leads are doing disproportionally less work and less skilled work. This has happened across the board for almost every culture past tribal cultures.

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.

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.

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.

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 ;)

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.

yes this is sad part. hoping AI will take over leadership and only AI engineers will be needed. /jk

Really? How do I contact you?

Although, it may never top your blog circa 2001, it's a fine achievement nonetheless.

Is it / will it be readable on a Kindle?

Will we get the updates if we buy the beta version?

https://www.theengineeringmanager.com

https://pragprog.com/book/jsengman/become-an-effective-softw...