[kabdib]

Good managers realize they have to be managers and can't do an effective job of engineering (this is certainly true of a first-level manager with more than a few reports).

The best managers I've had have sighed wistfully and wished out loud that they could do engineering, but made a conscious decision not to. The really good managers will be very interested in how you are getting along with your career, and it will often not come as a surprise to them when it comes time for you to leave ("time to go, grasshopper").

The bad managers were bad for numerous reasons, but many of the worst were micro-managing, getting in the way, having technical arguments, dishing out unreasoned mandates to solve things one way or another, or generally trying to be Boss Engineers without actually being part of the team. Sucked hard. The times I've switched jobs underneath these bozos, I've called it "Firing my boss."

[scottm01]

I'd go a step further and answer the question "What are some common mistakes new managers make?" with "Accepting a promotion to management".

If you're coming from a technical role, understand that your new job is not to be an engineer. If you're lucky and are good enough at your new job that you have some spare cycles, you might get to guide some architectural discussions

It can be rewarding to help guide a team towards something you could never accomplish alone, but you must resist the temptation to step and do "do things".

Disclaimer -- I moved up to a director-level position and realized within a year that to be good at it I would probably not be able to continue expanding my technical skills, at least not on company time. I moved on to an "individual contributor" role with a company that provides higher level career opportunities that don't involve having direct reports. The minutia of actual line management wasn't bad as long as there was a good team, but I definitely underestimated the people skills, budgeting, planning, and politics that goes along with being a good manager.

[ulms]

> I moved on to an "individual contributor" role with a company that provides higher level career opportunities that don't involve having direct reports.

Well, that sounds pretty slick. How's it working out? As someone who was just approached by management about a director position, and this being somewhat familiar ground, I'm concerned about the lack of expansion and technical progression as well. Haven't really seen many "no direct reports" situations in my neck of the woods, unfortunately... but it seems like that could be something to aspire for.

[scottm01]

I was probably a bit negative with that reply (though I do think "X is our best engineer, let's have them manage others to make them more like X!" is far too common).

I'm enjoying the new (now 2 year old) role but there are also negatives -- I have less visibility into the direction of the group/company and "stuff happens" that I would've known was coming at the old role. I'm definitely getting to stay hands on, and satisfying the "big picture" itch with involvement in architectural and project planning discussions.

I think if you're considering that sort of move just make sure you find the management challenges interesting and be willing to invest as much time and effort into getting good at the new job as you have at your "individual contributor" role. Have a good relationship with some existing managers and directors and talk honestly about the role with them if at all possible.

I don't regret the short move to management or the move back, and I'd consider either in the future. It's important to understand that they are usually almost completely different jobs though.

[jontas]

The company I work for (based in NYC) offers exactly this kind of career track. Individual contributors are comparable with management in every way (salary, seniority, title, etc) but are not forced into management in order to continue advancing. I don't want to hijack this thread with an advertisement, but if anyone is interested in more information feel free to get in touch.

[joncooper]

As an aside, anyone got recommendations on learning the skills scottm01 mentions? "people skills, budgeting, planning, and politics"

[scottm01]

Maybe as a common mistake, I read a number of "management" books before accepting the promotion. The one that stuck with me was Managing Humans by Michael Lopp. That is much more people skills and some planning.

Budgeting seems to differ significantly by company culture and practices, but is probably the easiest to get help with from peer managers or your accounting department.

Politics I have no idea.

[jevanish]

I'm working on an app to help managers with the people / soft skills stuff. It helps with 1 on 1s, goals, and personal stuff for your reports.

Would love to talk to you if you're interested (check my profile for contact info).

[zyxley]

> dishing out unreasoned mandates to solve things one way or another

This is the problem I've run into most often with management: the command to do things using method or technology A instead of B, not because A is better (in fact, B usually is the better choice both for development and for internal user support), but because A is the pet preference of a manager not involved in the work and who doesn't actually work with any of the people who will be using or supporting the end result.

[greenyoda]

"Good managers realize they have to be managers and can't do an effective job of engineering..."

I can't agree with this strongly enough. When I was a manager (I've since gone back to being a developer), trying to do engineering work at the same time was probably my biggest weakness.

There will be times when there's an emergency (real or imagined) where your upper management wants you to come up with a fix for something right away, and you'll be tempted to drop everything you're doing as a manager and put out the fire. (One rationalization for this might be that you don't want to break the flow of your developers, who are working on important stuff of their own.) Resist this temptation. Not only will your management work remain undone, but if the people on your team don't get experience dealing with emergencies in parts of the code that they don't know much about, you'll be stuck doing this stuff forever and they won't learn these skills. Learn how to delegate, and learn how to set the expectations of your own managers so that they don't assume that every problem can be fixed instantly.

[ansimionescu]

I just read your bio blurb – wow, that's pretty damn impressive! I'm a CS grad looking for a job, and am very passionate about Valve and what it stands for (while at uni I tried to create a startup based on basically the same principles).

I don't know how to contact you, so if you ping me at [0] or [1] I can send you a link to my resume. Thanks!

edit: I'm a big dum-dum – it was quite easy to find your Fb profile, I sent you my resume there (check 'Other' messages). :)

0: https://plus.google.com/+AndreiSimionescu

1: my username at gmail