Hacker News new | ask | show | jobs
by gwbas1c 2697 days ago
I firmly believe great software engineering managers are people who are adequate developers, but have excellent people skills.

Why? They need to understand enough software at a high level to be able to manage, instead of turning lower-level details into management problems.

But, they also need to find software development frustrating enough that they are happy to not have to do it every day.

5 comments

I have worked for Intel for a bit. I haven't stayed there for long but I have learned a lot about how great engineering management works.

Best managers I met had almost nil technical knowledge or if they did they were not advertising it very much. They were gardeners. They made sure you were occupied, you provided value, you did what you liked and all projects that needed staff were allocated staff. They will meet with you every week for mandatory half an hour 1:1 chat to make sure everything is heading in the right direction and have general sense of how happy you are and how happy others are about you. If the manager thinks you are doing well that's about how much supervision you are getting.

I like this style A LOT.

Best style I have seen is 'people' manager that has the soft skills and interest to do the organizational performance stuff, and separate 'project' managers that manage the work and teams. This allows technical staff to easily move around as needed to different projects without it being a big deal. That also encourages the project managers to be good so that people will be interested in working on their projects.
Most organizations don't have the foresight or bandwidth to organize things this way. It's always just one person do everything. I hate it.
Same. My current org actually got rid of our project managers over the last year and a half. So now my direct (engineering) manager is basically an overburdened full-time PjM, with spillover landing in my lap constantly (I'm an engineer and a team lead). It's extremely frustrating. And I can't even remember the last time he and I had a one-on-one.
I also work for Intel and I'd attribute this to the two very distinct tracks that are laid out, either the technical track to Principal Engineer, Fellow, etc. and the people track from manager, VP, etc. A LOT of people end up stopping after 3-4 promotions because it takes a lot to reach the final stages of this track but it provides a really robust pathway for people who want to have technical/people influence on dozens or hundreds of engineers but not necessarily thousands.
As a dev that has been promoted to manage (not just lead, manage) a reasonably sized team, but is still expected to code regularly, what you're describing sounds like paradise. From both the management, and dev perspective.
If you have a reasonable sized team that you're expected to manage, you should not code at all, let alone regularly. You will fail at one always, but more often both. My rule - if you have 5 direct reports (any role) you can code light stuff, sometimes. If you have 8 (a full team) you should not code - you will drop stuff over time and morale will sink a lot.
Funny, had an interview at a boutique consulting firm as a manager, told me something like : no no! You are not expected to bill like 90 or 100 percent. Aaaannndd I'm out. Those shops work like : bill 80 or still 90 percent while working with the team 100 percent. No thanks.
Or, like me, they love development and don't find it frustrating, but they would rather follow the money.
Often (I don't claim always), such a person is not as good at being an engineering manager as someone who was just ok with developing, because they keep wanting to interfere in low-level development decisions. Because, you know, those were the kinds of decisions they made when they were doing the job they actually loved doing.
This is my struggle. Do you go the management route for the money or stay in development where the pressure, and pay, is lower...
Have you considered consulting? Where you have more control and leverage over your earnings? (Especially if you have a spouse whose health insurance you can use)

Or perhaps PMing (which in many scenarios can lead to better pay, and less prone to ageism, though arguably even more stressful than being a manager)

I’m mulling these potential paths myself, to climb the pay scale and fend off ageism.

I haven't considered consulting mainly out of fear. I know a few very talented consultants that struggle to maintain a steady client-base. I'm the sole income + benefits in our household and with multiple little ones, my risk taking has decreased considerably. PMing might be an option though. I've worked mainly for smaller companies, so I imagine that's something I'd have to transition to a mid/large company to find?
In my career at least it’s never been true that the pay or pressure have been lower as an engineer vs a manager.
That's good to hear! My understanding was that as you move towards your 40's and 50's it becomes more challenging to find engineering roles that are willing to compensate you for your increasing experience levels. I hope I'm wrong.
The best engineering managers I've worked with still code every day or at least every other day. They are more than adequate as developers and they also have people skills.
But people skills is herein defined as lack of technical skills.
I recently realized that there are roughly two kinds of people, namely people who are good at symbolic/abstract ideas and people who are good at real/physical/touchable things, which can be considered orthogonal to the extrovert/introvert categorization. For a software engineering team, I find it tends to be suboptimal to have a physical-thinking oriented manager who dislikes abstract, symbolic notions, even though they are brilliant and would probably a good fit for say electrical or mechanical engineering teams.

My sampling space isn't large enough, but it's interesting to keep an eye on the personalities of the managers in your organization from that perspective.

In my experience there are two kinds of people; those who are good at many different things, and those who believe there are roughly two kinds of people.

I mean that only half jokingly. One of the reasons I like to work at smaller organizations these days is the pervasive belief in larger orgs that somebody has to fall into one of two categories. This is often rationalized as a way to identify strengths, however more often than not IMHO it's due to insecurity in ones own deficits.

This is interesting. I self-identify in the symbolic/abstract side of things and really struggle with how difficult it is when dealing with the real/physical/touchable camp. I've especially struggled with superiors who are in the latter group which tracks with what you say here. And as another point of anecdata I've personally been meandering my way into the leadership/management turf over recent years.
Yeah, I noticed that if I want to be perceived as good in x I often have to pretend that I am bad at y.

In reality, you can be good at both and like both and switch between them. You might have a preference and still be reasonably good at both. You might decide one is weakness and put effort into learning it overcoming initial dislike.

I only mostly agree. The soft skills are crucial. The other critical part of a good leader is vision. Engineering skills are helpful, but only so much as they help eliminate distractions from the vision. Junior engineers bring in all kinds of distractions to make things supposedly easier.