The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change

This is my list for this Summer (Southern hemisphere here):

* [reading] Atomic Habits (https://www.amazon.com/gp/product/1847941834)

* [reading] So Good They Can't Ignore You (https://www.amazon.com.br/gp/product/1455509124)

* 97 Things Every Engineering Manager Should Know (https://www.amazon.com/gp/product/1492050903)

* The Manager`s Path (https://www.amazon.com/gp/product/1491973897)

* The Five Dysfunctions of a Team (https://www.amazon.com/gp/product/0787960756)

* Overcoming the Five Dysfunctions of a Team (https://www.amazon.com/gp/product/0787976377)

* Who: The A Method for Hiring (https://www.amazon.com/gp/product/0345504194)

* Power Score: Your Formula for Leadership Success (https://www.amazon.com/gp/product/0345547357)

I'm not sure I'll get to all of them but I spent quite some time researching them and think this is a good list.

I usually read 2 books simultaneously because I like to read them and let certain things sink in. It provides a nice way to link some insights.

Do good work. Impress the right people. Be noisy, but above that know your shit.

Produce work that is:

• Timely
• Reliable
• Easy for stakeholders to understand

Read actual software development management books. Managing Humans and The Manager's Path are my top 2. An Elegant Puzzle is a good 50/50 blend of "managing ICs" and "managing managers" with sprinklings of TPM related topics.

Management is not your only option. You can continue to work as a developer. If you feel you've reached your maximum potential at your current company ( no new problems to solve or no incentive to learn ) you may need to find a new role with room to grow. I say this with the hopefully obvious caveat that there will be competition at every level and you don't just get to keep growing your salary without being valuable to an employer.

​

You might be right about being a Tech Lead. I can't speak to your higher ups motivations, but Tech Lead is not necessarily a management position. It can definitely be more responsibility without more compensation. Check out the chapter on being or managing a Tech Lead in Camille Fouriner's book The Manager's Path. It describes the exact thing you're bringing up, and I would recommend it whether or not you want to be a manager. https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897

​

Moving into management should not reduce your capacity to keep up to date with tech. You should learn at an exponential rate because the people on your team are all striving to improve too. If you read about an upcoming browser feature that would be useful on future projects, you can assign someone on the team to learn it and teach it to everyone else.

Read some books on the topic. I'm fond of these two as they're relatively concise and low-level:

The Manager's Path

Managing Humans

You claim you're noticing trends, take some common management concepts and apply them to those trends to form narratives. Look for patterns in those narratives, and you'll likely see some questions you could bring to interviews start to shake out. Or at the very least, case studies you can provide to the manager to see how they would handle it.

Only the sociopaths like it. It's more about seizing control of your own destiny. You've got the right attitude to succeed. Best advice is to treat your staff like you wish your own managers had treated you at their stage in their career. I know you've already got a ton of book recommendations but if I can make one more, I found it extremely helpful: https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897

https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897

I would question if this was a promotion or a role change though :) Make sure you understand the expectations and success criteria for your new role

https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897

https://www.amazon.com/Managing-Humans-Humorous-Software-Engineering/dp/1430243147

Read The Manager’s Path. It will answer your question more thoroughly, and is a great resource in general on career development for a junior engineer, even if you don’t want to be a manager.

You've done something amazing here. Don't doubt yourself. Don't compare yourself to somebody else. We don't all have the same experience and education. Own your expertise and learn to be comfortable admitting that there are other things you don't know. That's how you grow and learn.

Regarding what to do next...it depends. I usually advise people that there are 3 paths you can take as you grow in your career and these routes are more team (people) vs technology focused.

1. Management. Management is more team focused. How to help your team be effective. It's helpful to be technical, but you don't have to be the most technical person on your team because that's not your job anymore. Heck, I don't want to be the most technical person on the team if I can avoid it. This path usually leads through director to VP of engineering roles at places where those are more focused on team rather than technology.
2. Technical leader. This usually starts as some form of technical lead or principal engineering role, and rather than leading to a manager role, it leads to more of an architecture role. Sometimes the CTO is often the chief architect of the company, so that (and in my ideal, his is what it is) you have CTO and VP of Engineering as parter roles, one focused on the technology, one focused on the team.
3. Individual contributor. It's okay to stay as an individual contributor if that's what you are good and and that's what makes you happy. Not everybody has to aspire to a formal leadership role.

Depending on the size of the company, most of us have to do a little bit of all of these. At my last job, I started out as an individual contributor and then became a pure manager. Right now I'm a CTO who does a bit of everything because my team is small and fairly junior.

All this to say, if what you really are enjoying is the leadership, product, and team-based side of things you should absolutely not despair that you met this other very technical VP.

If you haven't read it, check out Camille Fournier's The Manager's Path.

Also, it's okay to go back and forth between being in leadership and being an individual contributor. Moving back to front-line development is not going to lock you in forever.

My top 2:

The Manager's Path

Accelerate

I have found The Manager's Path useful about this. She goes into good detail about what it means to be a manager vs a tech lead, for example.

https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...

I knew that the trend for Manager READMEs bothered me, but this really helped me to nail down why. When I'm wearing a manager hat, I see it as my job to serve the people who work for me. But READMEs are a one-way communication medium. They send the message, "It's your job to pay attention to me, the manager. You must learn and conform to my quirks." I think that's exactly the wrong message for a new employee.

This post is written by the author of The Manager's Path, which I also recommend: https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...

- Read this (and even if it's just for a peace of mind to feel prepared): https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...

- make sure this is something you want

For management: Manager's Path by Camille Fournier: https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...

Chapter 9: Boostrapping Culture of The Manager's Path [0] discusses this directly. You might also be interested in the earlier chapters on building and leading teams.

[0] https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...

Camille Fournier's The Manager's Path: https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...

yes do it, setup 30mins per person every 2 weeks, in the meeting invite describe this is a time for discussion, feedback (for you to them and them to you), for things like career progression and also for them to ask questions they might not feel comfortable asking in a more public setting including things about product, company etc. Try to keep the time as consistent as possible and show that these are a priority for you (so don't forget, cancel them etc).

They can be tough conversations, but rewarding on both sides.

If you are leading a team of devs at the very least read these 2 books:-

https://www.amazon.ca/Managing-Humans-Humorous-Software-Engi...

https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...

Managing engineers is a new career, that is separate from being an Engineer. Many engineering skills don't transfer to management, even when you think they do.

As a manager, one of the most important things you can do is schedule regular 1 on 1's with the people who report to you. Both "The Manager's Path"[1] and "Behind Closed Doors"[2] stresses this.

In about 4 months, it'll be helpful to review PG's essay, Maker's Schedule, Manager's Schedule[3] Right now, you'll be coding most of your time, but you'll soon have more and more meetings. MSMS names the feeling of frustration around meetings, and describes how to handle so many meetings.

[1] https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...

[2] https://www.amazon.com/Behind-Closed-Doors-Management-Progra...

[3] http://www.paulgraham.com/makersschedule.html

Maybe read "The Manager's Path" by Camille Fournier[0]. It focuses a lot on the transition from being an engineer to going into management.

[0]: https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...