Found in 12 comments on Hacker News
sethammons · 2019-10-30 · Original thread
Depends on the org. At mine, you go from manager to sr. manager (maybe that means another team under your belt, but still keeping your total reports manageable). From there, the next level up is Director, then VP, then CTO.

I recommend The Manager's Path by Camille Fournier. It takes you all the way from individual contributor to CTO.

yitchelle · 2019-09-18 · Original thread
It takes time to gain the management skills needed to be a really good manager. Just think how much time you took to reached your technical skills.

The book written by Camille Fournier to be quite a guide to understanding the path.

At the end of the day, and if money is not a motivating factor, I would recommend you to go where you are most happy now and in the future.

btown · 2019-06-15 · Original thread
I’ve heard great things about as a general set of advice. The Rands leadership Slack is also a great community.
Camille Fournier literally wrote the book on Engineering Management so when she speaks, I always listen [1]. Every technology leader will reach a point where there are just too many problems to solve and OPP is a great mental model for prioritization.

OPP is also a forcing function for leadership. It forces true leaders to step up and make the hard choices.

If you're faced with OPP, here are a few things I found useful in my career.

## Do Important Work for Important People

The best way to be successful in any organization is to do important work for important people. Important work for unimportant people will get you no where. Same is true for unimportant work for important people.

Take a look at your OPP and ask yourself:

* Is this work for someone important?

* Is this work important to that person?

Both answers should be yes, otherwise it's just OPP.

## Let Fires Burn

Once you decide the work is OPP, then you need the courage to say no. You must let that fire continue to burn without it distracting you. Masters of Scale has a good episode on this topic [2]. Easier said than done of course. I found Stoic practices to be very helpful here [3].

## Customer Obsession & Ownership

OPP should always be evaluated through the lens of the customer. Bottom line, the customer is always the most important person and they trump all. True leaders are obsessed about providing a better customer experience and they're willing to pay the price in order to do so.

If you have OPP that's important work for someone important, but it's not important to the customer, then you may just have to let that one burn too. And once you make that call, you have to own it. Always take responsibility for the decision and defend it on the customer's behalf.

I've found Amazon's leadership principles to be invaluable when making these type of tough decisions [4]. It's no coincidence that Customer Obsession and Ownership are #1 and #2.

[1] (Camille's link not mine)




e-_pusher · 2019-02-18 · Original thread
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.

wpietri · 2018-11-22 · Original thread
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:

anotheryou · 2018-09-02 · Original thread
- Read this (and even if it's just for a peace of mind to feel prepared):

- make sure this is something you want

cottonseed · 2018-02-16 · Original thread
For management: Manager's Path by Camille Fournier:
cottonseed · 2018-01-26 · Original thread
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.


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:-

helper · 2017-08-05 · Original thread
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.


yoloswagins · 2017-06-14 · Original thread
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.




Fresh book recommendations delivered straight to your inbox every Thursday.