Struggling to be a great tech manager? This book has answers for you
Lessons from “The Manager’s Path” that every "engineer-turned-manager" should know
Before I talk about “The Manager’s Path”, I have a mini-story to tell you. I promise to be brief.
In 2022, I was given the opportunity to build a Data Science marketing team from scratch, which was no small ask. Data Science hadn’t had a team working under the marketing umbrella before. One moment, I was a successful individual contributor; the next, I was faced with defining a role that hadn’t existed. In fact, I wasn’t told why they had chosen me for the role, so it was really confusing to understand what was expected from me. Camille’s chapter on “Becoming a Tech Lead” helped me answer these questions and calm my nerves. It reminded me to focus on the strengths that had earned me the opportunity. The end of story is that, not only I built the team but also scaled it to 8 data scientists (check my post below)
Of course, my experience wasn’t shaped by this 1 chapter in the book. But, it’s not easy to recall specifics from a 200-page guide. Whilst the book has 9 sections, 6 were very relevant to me. I want to capture key phrases and lessons that stuck with me, so you can benefit from them as I have. The 6 sections will be:
Mentorship - A great first step to demonstrate leadership.
Being a tech lead - leading without formal authority
Managing People - from leading projects to managing individuals.
Managing a team - it’s not simply about having more 1-1s
Managing multiple teams - delegation is your new super power
Managing managers - helping others lead
I strongly recommend those of you just stepping into management or looking to refine your leadership skills, to read this book. In the meantime, I hope these takeaways will help you on your journey - the same way they helped (and keep helping me) in mine.
Mentorship is a great first step of leading.
“The first act of people management for many engineers is often unofficial” [page 11]
Mentoring someone should bring you out of the comfort zone. Its probably first time you have “the feeling of being responsible for another person” [page 12]. There are probably 3 types of mentorships:
Mentoring a new hire. Prepare good documentation on technical setups. Spend time with them updating these documents if they encounter surprises. Introduce this person to, not only your team, but those you work closely with. Make sure they are comfortable meeting with leadership. Your small time investment can mean the world for a new person in the team.
Mentoring a colleague on career progressions. Your success as a mentor depends on your ability to listen. Don’t provide straight answers. Try to understand why your mentee is asking certain questions. In addition, make sure you establish the mentoring rules between both of you: “Tell your mentee what you expect from him. If you want him to come prepared for your meetings with questions he has sent you in advance, ask for that. Be explicit about your time commitment.” [page 19]
Mentoring on technical expertise. “Senior engineers can develop bad habits, and one of the worst is the tendency to lecture and debate with anyone who does not understand them or who disagrees with what they are saying.” [page 25] Make an effort to listen and speak your mentee’s language: “you must be able to listen and communicate in a way that person can understand, even if you have to try several times to get it right” [page 25]. You are an experience engineer, and those seeking for your technical expertise will probably take your words as gospel. Make sure you are not communicating personal hard-beliefs and be open to explore with them their ideas too.
Ask your manager for an opportunity to mentor new hires, or if you see someone struggling, bring up the possibility of having a few 1-1 sessions with them. Mentoring doesn’t have to begin with a formal sit down. But mentoring is a first taste of what it means helping someone altruistically.
Being a tech lead - leading without formal authority
“All great tech leads know this one weird trick: the willingness to step away from the code” [page 31]
I really like this phrase and I have highlighted “willingness” on purpose. A tech lead will probably write code, but she knows when not coding is the right thing to do. So, how do you define what a great tech lead does?
A tech lead should not have management responsibilities. They might have 1-1s with their peers, but probably to cover project details.
A tech lead should be senior enough to be provided the toughest problems you are facing as a team. A tech lead who always does the same work, is not a tech lead that can lead your team through change.
A tech lead needs to go beyond the tech. I am talking about breaking down a problem into phases, assigning those phases an order, estimating how long would each phase take, knowing who can run these phases and making sure they are delivered.
Knowing this, “the idea that the tech lead role should automatically be given to the most experienced engineer […] is a common misconception that even experienced managers fall for” [page 27]. I can only echo this. Points (1) and (2) could perfectly describe the more senior members in your team, but… could these senior engineers plan, communicate and run a cohesive set of people? A good tech lead is a multiplier, making everyone on the team more effective.
One issue that tech leads face
Tech leads are in a position to act as strong technical project leaders. But, they have no formal authority. They are not the team manager, nor the product owner. Tech leads don’t tend to be in management meetings, so they might miss headcount discussions. Tech leads also don’t tend to be in product long term discussions, so they might also miss if their current projects are still high priority.
Therefore, if as a tech lead, you are able to influence your manager and your current product owner counterparts, this is an indication of great leadership skills.
Managing People - from leading projects to managing individuals.
“It’s hard to accept that “new manager” is an entry-level job with no seniority on any front, but that’s the best mindset with which to start leading.” [page 49]
Managing people is a whole new game compared to a tech lead. This is the very first time where you feel that your coding time decreases at an alarming rate, and it is replaced with other tasks that you didn’t feel should take that much time. Managing people is a topic that could cover a whole book. From “The Manager Path”, I would like to highlight 3 areas that can help new managers get started.
Build trust and rapport
Regardless if you are a people person or not, there are a set of actions which can bring you closer to your direct reports. Make sure you have periodic 1-1s (these can be a simple catchup, a meeting to provide feedback or a project progress report). Prioritise psychological safety - for example, if someone in your team is quiet during meetings, help them participate and feel like they are part of the discussion. Or, if someone is not accustomed to dealing with new responsibilities, make sure you are there with them in their first few meetings or providing much more regular feedback. People perform best when they feel safe.
2 styles to avoid
Micromanagement. “Micromanagement creeps up on you. […] if micromanagement is your habit, if it’s your default approach toward leading your team, you’ll end up accidentally undermining the very people you need to be growing and rewarding. Trust and control are the main issues around micromanagement.” [page 58]
Extreme delegation. “Delegation is not the same thing as abdication. When you’re delegating responsibility, you’re still expected to be involved as much as is necessary to help the project succeed.” [page 58]
Performance reviews are not a simple admin task
Some managers don’t understand how important performance reviews are once they get to managers. As an IC, you expect a detailed performance summary from your manager. Now as a manager, you have to provide this detailed view to all your direct reports. And it is draining. Therefore, some managers consider that drain equals admin.
It can’t be less true. Here are some guidelines offered in the book:
Give yourself enough time, and start early. “This process isn’t something you can knock out in an hour and do well” [page 64] Start collecting feedback throughout the year. I keep a document where I copy paste things that I have seen and messages I receive. At point of performance review this helps remind me of things that I wouldn’t have remembered.
Try to account for the whole year, not just the past couple of months. “The goal for viewing the whole year is to recognise not just early accomplishments but also the growth and change you’ve seen since then.” [page 65]. It’s very easy to suffer from recency bias. Whether this means good or bad performance.
Concrete examples are key. “If you can’t use a concrete example to support a point, ask yourself if the point is something you should be communicating in the review.” [page 65]. More importantly, you can anchor a comment which your direct report could feel is qualitative or subjective, with a specific situation.
Avoid big surprises. “If someone is under performing across the board, the review should not be his first time getting that feedback.” [page 66] It is not fair for someone to be told their bonus is 50% instead of 100% because they underperformed in delivery, when it is the first time they hear about this. You don’t know if this person could have turned the situation around had they been told about not meeting expectations.
Managing a team - it’s not simply about having more 1-1s
“Managing a team is more than just doing the job of managing the individuals.” [page 75]
I really like the distinction Camille makes about managing people and managing teams. I have worked in companies where your first role as a manager is having just 1 or 2 direct reports, and where the team is pretty small. The dynamics are easy to control and you can master all the skills to help individuals. But, when a team increases headcount, dynamics become increasingly complex. This means that you can’t cover all possible issues just through 1-1s. There are 3 topics that resonated with me when managing my first big team of 8 data scientists.
Staying technical.
“If you truly wish to command the respect of an engineering team, they must see you as technically credible.” [page 77] It doesn’t mean you have to be the best engineer of them all. You don’t have become the “alpha” coder. But, who wants to explain technical concepts to their manager? How can you trust your manager to help you if you believe they don’t truly understand the problems you are facing? In addition, how are you going to guide technical decisions or understand priority vs effort if you don’t truly follow the tech?
Just to be clear, you don’t have the team to be super technical. But, you shouldn’t suddenly stop coding at all. Why not help in peer reviews? Why not pick some smaller “boring” or “business-as-usual” tickets to keep on top of what your team builds?
Be prepared, because conflict exists and it’s your responsibility.
When conflict happens, do not go for voting. You are the manager. You should have all the required information to take action. Don’t make people vote against each other. If someone is underperforming to the eyes of their peers, figure out how they and yourself can help this individual. And if they can’t be helped, you will need to make hard decisions. If someone in the team is rude in their communications, cut it from the beginning, even if the person who you are cutting is hurt (I can guarantee you will gain the respects of the rest of the team).
You might look directly in the eyes of conflict and deal with it, but also believe, you should be the team’s shield against external conflict. To an extent, this is true: “teams who are unnecessarily exposed to toxic drama that doesn’t concern them tend to get distracted and stressed out.” [page 83] But, shielding everything could be detrimental. If you dont’ provide the team with context on why we are changing priorities mid-quarter, they might see this as an attack on their work and moan about all the effort that has been wasted. But, if they understand how important this new priority is, they might close ranks and all rally to help on the new project.
Team cohesion - the brilliant jerk
Camille provides a few stereotypes of engineers who can break team cohesion. I highlight only the “brilliant jerk”, as this is the type I have seen more often. The brilliant jerk is an amazing engineer, but ego-driven and only respects equal intelligence. They could inadvertently use strong language against contradicting views or ideas from their peers. It takes a strong manager to steer the brilliant jerk, even if you go through dozens of feedback sessions, they might not want to change their ways (hey, they deliver so much value).
Best thing you can do is to openly not tolerate bad behaviour “This may be one of the few instances where ‘praise in public, criticise in private’ is upended.” [page 91]
Managing multiple teams - delegation is your new super power
“It’s time—now—for you to figure out how to manage your time.” [page 103]
“Welcome to the world of multiple-team management!” starts Camille in her 6th chapter. It seems like a fun welcoming world right? Well… it is not (at least in the beginning). If you thought you had it figured out managing 1 team (you know, your effective delegation but being the details, helping your junior colleagues promote)… bad news. Multiple teams management is a complete new job.
“The manager’s path” book offers 2 great simple tables to frame how to spend your time. The book doesn’t get into time management techniques - this is very personal. It focuses on describing if certain tasks / projects should be worth your time or not.
Which tasks really require your attention?
“Managing your time comes down to one important thing: understanding the difference between importance and urgency.” [page 103]. Use this 2 by 2 prioritisation matrix to help guide you.
Below you can see some examples of tasks which would land in any of these 4 quadrants:
Which tasks really need you for them to be completed?
“Delegation is the primary way you claw yourself out of the feeling of having too many plates spinning at once.” [page 108]. Again, use this 2 by 2 prioritisation matrix to help guide you.
Below you can see some examples of tasks which would land in any of these 4 quadrants:
I would summarise this section as:
Your job is to create a framework where good decisions happen without you.
Managing managers - helping others lead
“Whether you have experienced managers or first-timers reporting to you, there is one universal goal for these relationships: they should make your life easier”. [page 131]
You might have gotten to the role of managing managers through managing multiple teams. These teams tend to be the ones who have been closely related to your growth trajectory either as an engineer or as a manager. You might be familiar with managing a few tech leads with different projects. But still, you are close to the problems and can quickly switch context and detect problems. However, at this point, your job tends to have a wider scope. You might be even managing teams you haven’t worked before or even areas where you have little expertise in.
“People who are good at managing a single team, or even a couple of related teams, fall apart when asked to manage managers, or teams that are outside of their skill set. They’re unable to balance the ambiguities inherent in their new role, and fall back into things that they find easy.” [page 126]
I found this chapter really useful, because this is the situation I was going through and there wasn’t too many resources out there to help with me with some tips which could make me more effective in my job. Here I have captured the ones that I wasn’t fully implementing and have helped me in my leadership journey.
Skip level meetings
Prior to reading “The Manager Path”, I hadn’t experienced a skip-level meeting before (ie, my manager’s manager hadn’t set up these chats with me). This is why I didn’t have skip-level meetings in my “playbook”.
Camille talks about skip-level meetings as a way to understand team health. She says that “if you want to build a strong management team, understanding the people who report to those managers and maintaining a relationship with them is hard to avoid.” [page 128] I interpreted this as having a layer between the team and myself where information gets lost. And it’s not because the manager is hiding information (which could actually happen), but because subtle details are lost along the way.
Again, you can’t just flood your calendar with skip-level meetings (you would basically be doing your manager’s job...), but having chats with the team can be super useful. I have gone for having quarterly team skip-level meetings with some occasional ad-hoc in-person chat with some individuals. Here is a list of questions from the book that I found most useful:
What do you like best/worst about the project you are working on?
What’s keeping you from doing your best work right now?
Are there any opportunities you think we might be missing?
Are there any areas of the business strategy you don’t understand?
What could we do to make working at the company more fun?
What can I provide for you and the team?
Manager accountability
As the section starts: managers should make your life easier. Even in tough scenarios, your manager should be held responsible. Managers can complain but also have good reasons for it, but again, they should be responsible. For example, the product roadmap constantly changing but the team is killing themselves with work. Or, the tech lead has gone down a rabbit hole but she insists its the most important things to do. Even that productivity in the team has gone down just because there are way too many urgent requests!
The answer to all these situations is still that the manager is accountable to solve these problems. Of course this doesn’t mean you can’t help them, you actually need to but up to a certain extent. For example, “show the person that he’s exhibiting the behavior, and highlight the downsides. Sometimes all it takes is awareness that his habit of saying yes is a problem for the team” [page 136], or “Sometimes they don’t have the clout to push back against product and need your support. They may need your help finding other senior people to partner with their tech lead” [page 132]. Even “You’ll probably have to approve any requests for more people to fight fires, or support them in shifting the support burden to other teams. They’ve done the hard work of identifying the problems that are slowing down their teams, but you need to then help find the solutions or support the path forward. This is what making your job easier looks like.” [page 132]
Managing new managers is different to managing experienced managers
Helping new managers has a clearer playbook than managing experienced managers. Reading the book or if you are already a senior manager, you can relate with the first struggles of management. It is your duty to:
Help new managers make sure they are not overworked, ensuring they hand-off old responsibilities.
They might not know how to run effective 1-1s, how to provide feedback or effective ways to track takeaways.
Even more, they might have completely forgotten about stakeholder communications!
“it’s no surprise that first-time managers need a lot of coaching.” [page 136]
Helping experienced managers is less tangible. They probably make your life easy, but be weary of the sub-culture they might introduce in the team. For example, hiring an experienced manager from a corporate into a startup environment (or viceversa). Another important aspect to take into account is that “Experienced managers will have different ideas about management than you do, and you’ll have to work out the differences. Working out these differences, however, is different than letting the manager do whatever he thinks is best.” [page 139]
So, how can you help these experienced managers?
Think about how can they have a larger impact on strategy
Do they have a long term plan for their area?
Can they be an important advisor?
Do they need help expanding their network within the company?
Hiring managers
When you are hiring for ICs, there are specific technical concepts that you like to interview for. However, when it comes to management… “Management is...well, what even is it? How do we interview for it?” [page 141]
Camille proposes a couple of ideas to try in your interviews for new managers.
First of all, be weary at scoring only communication. “The skills of a manager, as we have discussed at length, are pretty much entirely based around communication. But […] someone who communicates well in a management interview, who talks a good game, can still come in and get nothing done.” [page 141]
One of most important tools for a manager are 1-1s… why not interview for them? Consider the idea that one of your ICs joins in one of the hiring rounds. If this is not possible, then you should play the IC part. The idea is to have a mock 1-1 situation, maybe even with a current problem that an IC has to see how their possible new manager approach the situation. “a good manager—even without a full understanding of the people or projects involved— should have good instincts for questions to ask and suggested next steps that might improve matters.” [page 141]
A manager must also debug projects. “Ask the manager to describe a time when she ran a project that was behind schedule, and what she did in that scenario.” [page 141] However, careful with what is mentioned in point (1), managers can play the words.
Interview for management philosophy. This might take some people by surprise as it is not a typical question. However, “If she doesn’t have one at all, that might be a red flag.” [page 141] If the interviewee is stuck, nudge them with questions such as how does she stay hands-on vs how does she delegate? How does she understand that something is important vs urgent? What does she think her role as a manager is?
Do not forget about technical skills. You read through the book that technical skills fade from the day-to-day when you become a manager. However, they don’t completely disappear. Some companies go for a technical coding interview. Camille proposes another approach. “How about mediating between 2 opposing views from a technical implementation?” [page 142] The idea here is to present a mock-case scenario where the manager must be able to hold their ground in a team of technical engineers and reach to an action plan to solve this technical situation.
Finally, cultural fit. This is key (and it is even mentioned in the managing experienced managers section). But it is also the most complicated thing to interview for. It is true that the previous points provide you with a sense of how would the manager fit within the team. Camille also proposes a controversial point where you reach out for references. “Ask the references to describe the ways that the person succeeds as well as the ways she fails. Ask them if they would work with or for this person again. Ask them what they love about the person, and what drives them crazy.” [page 143]
Summary
“This book is for engineering managers. It’s not a generic management book.” [page 77]
In the ever-evolving journey of leadership, "The Manager’s Path" offers a guide for engineers navigating the transition from mentoring to managing teams and beyond.
From taking your first steps as a mentor to leading multiple teams, Camille Fournier reminds us that leadership is not about having all the answers—it's about empowering others, making hard decisions, and continuously refining our craft. Her insights are not abstract. She always provides tangible examples to refer to.
Whether you're stepping into management for the first time or guiding others on their leadership path, the knowledge in these pages is timeless. Let it inspire you to lead not only with skill but with heart, as it has done for me.
Now, I want to hear from you!
📢 Have you ever struggled with the transition from engineer to manager?
What was the biggest surprise or challenge, you faced?
If you are already a tech lead or manager, what is 1 lesson you wish you had learnt earlier?
Have you read The Manager’s Path? What was your biggest takeaway? Do you have another book that shaped your leadership approach?
Drop your thoughts in the comments! I would love to hear your perspective and learn from your experiences. Let’s make this a conversation.👇
Further reading
If you are interested in more content, here is an article capturing all my written blogs!
Great article, Jose. The Manager's Path is probably the first book I recommend for new Engineering Managers, Team Leaders, or those aspiring to these positions.
This is a great book, highly recommend for everyone in software engineering.
Very important the part of leading without authority. When you get there, you are a true leader.
Thanks for sharing Jose!