Ask HN: Developers who became engineering managers, how was the experience?

I made this jump from researcher to network engineering to applications and systems management to tech group management. I sucked at people and project and process management and I was very lucky to escape back to research and technical communication. Tech management required skills I lack and now, I report to a professional technical manager who is wonderful, a kind, humane and also appropriately critical man. What I sucked at most was giving negative feedback. That and time management. Good managers manage expectations upward and downward, keep blame, share recognition and do not excuse failure but reward admitting mistakes. Don't ever be tempted to lie, and don't shaft people. Don't keep dud hires unless you can find the role they don't suck at. Don't allow bullies to triumph.

Tech management should be more like an anarchist collective of mutuality but I tried, and it doesn't work well in a hierarchical reward structured environment.

Tech management can be learnt but I now understand not everyone can apply it, and you need to be open to the possibility it's not for you. On one management course I was told that if you find yourself in conflict with the goals you're being asked to deliver you may be getting a signal to move. As a wage slave with no reports it's possible to compromise on this but in a leadership role, its untenable to command outcomes you cannot adhere to. Don't do it.

I'm in a role as manager/lead dev, so it's kind of mixed. The transition to the managerial part was pretty rough back then and I wished I had gotten more support, many companies don't know how to do that well.

With a developer mindset, what helped me was this (no particular order)

* Go about it as a problem solving task. This can be as complex and fun as building a new system - you are building organization and culture. The way you treat them will mirror in how they treat each other and your customers.

* Don't assume too much what a manager should do or what you have seen, but see your new job as an enabler of other people and find out what the particular needs there are. You're the user interface for other people to get things done in the company.

* The hardest thing is probably to stop solving implementation problems yourself. That's again an enabling position. All the stuff you were the expert in before you now need to transfer to other people. Don't just quickly solve their new problems because you know it better.

* One thing about micromanagement - If there's something that appears to be micromanagement, it's often a problem of too little actual management and not enough. That sounds weird, but the reason is that management interferes with people's work directly, where they actually should have given them the tools and the knowledge to do it themselves. So when you start hearing or sensing that notion, don't stop managing, but try to find out where you really need to help.

I was a Sr. Developer. My boss refused to relocate, and I was offered the job. We have the following leadership roles on a team: Scrum Master, Technical Lead, Product Owner and HR Manager. Originally I was Technical Lead and HR Manager. Later I was TL, PO and HR.

I gave up TL to someone but retained PO. I was just too busy to do all three and decided that Power of the Pen trumped Power of the Code Review, though I still do CRs.

It's hard to let go of the technical leadership, not just for me, but also for everyone else who is used to coming to me.

The people management role is the least rewarding and the most challenging. Hiring can be rewarding, but unless you work somewhere where you're always hiring, you quickly hire some decent or great folks, and then you're done with that. Like really done -- letting people go can take a long time in a big company.

I still write code, but it tends to be emergency fixes or prototypes, not the type of code that requires days on end of focus, because it is impossible to be left alone for any length of time, and not have to do a million simple but important tasks.

Being somebody's boss typically carries a lot of weight, as long as you have their respect, and I find it challenging not to suck the technical oxygen out of our team by doing the research while writing the requirements and taking that fun phase away from developers, thereby limiting their satisfaction and growth. I mean, a good developer will still do their own research even if you hand them something on a silver platter.

Also, you have to learn how each team member works and communicates. Some people are very focused on dry facts, and others on feelings. If you don't speak their language, you'll never be on the same page with them and your relationship will be constantly frustrated.

Some people work fast, and others more slowly. When people seem to be working slowly, you need to consider why. Are they on the wrong path? Did you not give them all the info they need, and they're hesitant to admit they don't understand. Maybe they just the real thorough type? Find a way to get people into their zone quicker, and leverage their individual strengths.

Finally, there is the whole issue of what role do you play. You may have been friend/peer to people who now report to you. If you notice they are slacking off, it's a bit more challenging to get them back on track, but not that hard. Just ask for a detailed status update, take a few notes, and then do it again a few days later, and compare what they've done, or schedule a demo.

Larger or less flat organizations will have a dedicated people manager for 1-3 teams, and their full time job is to manage people, foster moral, etc. That may be rewarding for some folks, but I tend to think the majority of engineering types would hate it.

Good tips. A few more:

* Resist all tasks that you and your team can't figure out next step for. (They're not actionable.)

* Find the maximum task length you're comfortable with doing yourself; try to delegate anything that you expect will take you longer. Keep this number very low (e.g. 15 min or 5 min).

* To balance the latter, find the maximum hours you're comfortable with having someone else do work you'd do in an hour. Keep this number high (e.g. 8 hours or 20 hours), and step in to do things yourself only when delegating will make you over it.

(Edit: Also, there are good lessons learned from the past; don't forget to read books books, like PeopleWare.)

Go have a listen to this excellent podcast on delegation [1] from Manager Tools. They hit the same notes you’re hitting, but provide some additional actionable tips and tricks for figuring out when things are going well, about to go wrong, or going wrong.

[1] https://www.manager-tools.com/2005/08/the-art-of-delegation