I asked a similar question some time ago: https://news.ycombinator.com/item?id=13284742 not about the experience, but more about what to keep in mind when switching. Hope it helps.
The role of project management is very different from that of engineering management. For e.g., the former doesn't have any people management, whereas the latter does.
Ask HN: Developers who became engineering managers, how was the experience?
11–20 of 75 posts
Re: Ask HN: Developers who became engineering managers, how was the experience?
#12Learning to limit scope from both engineers “wouldn’t this cool new feature be great” and end users “we want this new feature we never talked about after agreeing on the MVP” has been a learning experience. Also learning to explain how and why one feature is stupidly simple and another is exceedingly impossible has been an interesting challenge. Otherwise nothing particularly revelatory, you will hear all of the typi…
Re: Ask HN: Developers who became engineering managers, how was the experience?
#13Re: Ask HN: Developers who became engineering managers, how was the experience?
#14Learning to limit scope from both engineers “wouldn’t this cool new feature be great” and end users “we want this new feature we never talked about after agreeing on the MVP” has been a learning experience. Also learning to explain how and why one feature is stupidly simple and another is exceedingly impossible has been an interesting challenge. Otherwise nothing particularly revelatory, you will hear all of the typi…
What's an MVP? Is that like an SoW?
Essentially, the first draft of a product that does what it needs to do to show capabilities to others. Similar to a proof of principle
EDIT: Thanks for the clarification @kweinber, an MVP is put into production whereas a PoC/PoP is not
Re: Ask HN: Developers who became engineering managers, how was the experience?
#15Earlier quoted context omitted.
What's an MVP? Is that like an SoW?
I read MVP as: Minimum Viable Product. Essentially, the first draft of a product that does what it needs to do to show capabilities to others. Similar to a proof of principle EDIT: Thanks for the clarification @kweinber, an MVP is put into production whereas a PoC/PoP is not
Re: Ask HN: Developers who became engineering managers, how was the experience?
#16Earlier quoted context omitted.
I read MVP as: Minimum Viable Product. Essentially, the first draft of a product that does what it needs to do to show capabilities to others. Similar to a proof of principle EDIT: Thanks for the clarification @kweinber, an MVP is put into production whereas a PoC/PoP is not
Ah, thank you. Couldn't get past the "Most Valuable Player" association; it is called a Proof of Concept in my industry.
xkcd [0] made an ingenious comic about this that I keep coming back to
Re: Ask HN: Developers who became engineering managers, how was the experience?
#17Answer from a different side of the fence: As an executive who elected senior engineers into engineering managers three time in different companies, there are three challenging areas for even the most fit for the job engineers: - understanding that soft skills and understanding company politics now matter not as much, but more than detailed technical skills. focusing on eliminating weaknesses in this area is that par…
Re: Ask HN: Developers who became engineering managers, how was the experience?
#18Earlier quoted context omitted.
I read MVP as: Minimum Viable Product. Essentially, the first draft of a product that does what it needs to do to show capabilities to others. Similar to a proof of principle EDIT: Thanks for the clarification @kweinber, an MVP is put into production whereas a PoC/PoP is not
Ah, thank you. Couldn't get past the "Most Valuable Player" association; it is called a Proof of Concept in my industry.
Re: Ask HN: Developers who became engineering managers, how was the experience?
#19The new role itself was not challenging, per se, except getting used to approaching unrealistic demands by non-technical people who have a say in the project. (There is a near constant influx of requests that are made without appreciation for the difference between ones that take 60 minutes versus 600 hours, and explaining such things tactfully and in human terms is an important highlight.) That said, the thing I wou…
I'm working as developer, now since approx 8 years. At my first job I had a boss with Engineering background but he worked a long time in Management as well. So this was quite nice and when he asked me implement things that would take a long time or would be risky to build, I'd tell him and he would prefer me doing other things. At other jobs this changed, I had to talk to more people but doing the programming mostly…
Re: Ask HN: Developers who became engineering managers, how was the experience?
#20* The priorities of developers are very different from those of managers and the greater business. Your goal is to serve the business, but neglecting the needs of your developers has obvious long-term consequences.
* Politics, obviously. I didn't expect to spend my entire working week literally arguing with people.
* Technical skills are still super important. It's not like you give up coding and just manage. You have to be able to do both.
* Buy a Bluetooth headset that you love. I have a Plantronics Voyager Edge. If you're going to spend hours on the phone each day, you might as well be able to type and walk around. (Remember to mute the mic when you flush the toilet.)
* Block out time in your calendar for 'getting work done' -- focus time. Make yourself unavailable. One employer had single-person meeting rooms, which I loved -- I could be found if necessary, but was a lot less likely to be interrupted.
Being a manager for a while helped me to understand why my managers behaved the way that they did, and helps me now (as an individual contributor) to direct my managers to where I think I need to be.
I love the 'bigger picture' thinking, and I love designing larger systems with others. Negotiating about subsystem boundaries and "whose job is it" is challenging, but useful.
I'm happy to leave the fiddly details to others. This is possibly the hardest thing to adapt to -- if other people are coding on your project, they're going to do things the way that they want to. It won't be the way that you want it, and it'll frustrate everyone if you try to force them into doing it your way. You just have to take that massive leap of faith that everything will be alright.
You can never overcommunicate. Learn to love PowerPoint. Write a lot of emails. Document everything on your company wiki.