[lmilcin]

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.

[itronitron]

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.

[ionforce]

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.

[wool_gather]

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.

[bateman_]

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.

[ep103]

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.

[taurath]

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.

[Bombthecat]

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.