The book’s main goal is to describe the steps in the career ladder of a technical manager and I believe it fully lives up to this promise. It starts with discussing mentoring and finishes describing roles of CTOs and VP Engineering.
The main value proposition of the book is a complete description of a “manager’s path”, this book can almost be used as a journal guiding you through out each stage of your career in software.
“Feedback works best when you, as a manager, pair that feedback with coaching.”
One of the most important things you do as a manager is give feedback to your team. It helps them improve, fixes problems, and sets a clear standard of the work you want to see. Fournier writes: “When they believe that their manger sees the good things they do, they’ll be more open to hearing about the areas where they might improve.”
When you are an individual contributor, you can largely focus on just yourself. When you become a leader, you have to start thinking about others. Providing great feedback and praise is one of the most important things you can do.
“One-on-one meetings with your manager are an essential feature of a good working relationship.”
From very early on in the book, Fournier starts preaching about the essential value of one on ones.
She writes that there are two key purposes:
- Create a human connection between you and your manager. (Aka – Build rapport)
- Provide a regular opportunity for you to speak privately with your manager about whatever needs discussing.
Throughout the book she reinforces both of those concepts as key to effective leadership. If you don’t have your one on ones, it’s unlikely you’ll have time to coach, give feedback, have tough conversations, and maintain strong communication with your team.
Fournier also shares a great piece of wisdom:
“Skipping 1-1s because you’re too busy with other things is a great way to miss the warning signs of an employee who is going to quit.”
“It’s unrealistic to think you can or should shield your team from everything.”
A common piece of advice for manager’s is to shield their team. To some extent, this is very good advice. Letting everything pass you and dump on your team creates a lot of unneeded stress and distraction for your team.
But Fournier argues:
“Sometimes it’s appropriate to let some of the stress through to the team. The goal is not to stress them out but to help them get context into what they’re dealing with.
“…humans usually need some sort of context into why these goals have been set, and thereby into what problems they’re working to solve.”
However, helping them understand key situations can be a time when you should not shield them. They are likely to be more motivated when they have context, and can be more helpful in fixing problems.
We’re reminded, “you are not their parent.” Treat your team like adults and include them in key decisions and challenges, and you’ll strike a much better balance for when to shield them.
“Starting new reporting relationships off right”
Fournier outlines the concept of a 30/60/90 day plan. She goes on to say:
“This can include basic goals, like getting up to speed on the code, committing a bug fix, or a performing a release. The more senior the hire, the more they should participate in creating this plan. You want them to have clear goals that will show whether they’ll learning the right things as the get up to speed”
Having a 90 plan of achievable goals will also help you catch mis-hires quickly, and make it clear to you and them that you need to correct the situation.
The key with this plan is to create a set of realistic milestones based on your prior hires, the current state of your tech and projects and the level of the person coming in.
In summary, I believe the book is a great read for everyone who is thinking about getting on the engineering manager’s path or is already there but didn’t get to CTO or VP Engineering role yet and hasn’t spent years in it.