Camille Fournier's The Manager's Path (O'Reilly, 2017) is the book most engineers are handed when they start managing, and most of them read the first half and put it down. That is a sensible way to read it. The book is built as a ladder, one chapter per rung: being managed, mentoring, tech lead, managing people, managing a team, managing multiple teams, managing managers, and what she calls the big leagues. Each chapter assumes you have lived the one before it.
For the first year, the chapters that matter are tech lead through managing a team. We think four arguments in them hold up well, and each one turns into a decision you can make this week.
Tech lead is a set of responsibilities
Fournier's position, which Dan Lebrero's reading notes record as "a temporal role" rather than a point on the ladder, is that tech lead is a bundle of work a senior engineer picks up for a project and later hands back. It covers breaking a project into deliverables, keeping the architecture conversation moving, and being the person the product manager asks for a date. It does not have to include people management. Her advice to the tech lead is to keep writing code, and to write less of it than they would like.
The decision for a new manager is to write that bundle down. On each team, name who holds the tech lead responsibilities right now, what they own and what they do not, and when the role rotates. A schema change that three other teams read from is a tech lead decision; the manager's part is to make sure the three teams were consulted and the rollback is written. Leave the design call where it belongs.
Writing it down also stops the role being read as a promotion. If an engineer thinks tech lead is the next rung, they will cling to it, and the next person who could use the practice never gets it.
One-to-ones are maintenance, and skipping them has a cost
Fournier's chapter on managing people lists several styles of 1:1, which Lebrero summarises as the to-do list meeting, the catch-up, the feedback meeting, the progress report (which she reserves for when you manage managers) and the getting-to-know-you conversation. Her advice is to pick deliberately for each person rather than letting every meeting drift into a status update.
The line of hers that Lighthouse's five-lesson summary quotes is the one to pin above your calendar: skipping 1:1s because you are busy "is a great way to miss the warning signs of an employee who is going to quit". She borrows Marc Hedlund's comparison with oil changes. Skip them and plan to be stranded at the worst possible time.
In practice the decision is small. Weekly, same slot, the report brings the agenda, you keep a shared document of what was discussed so patterns show up over months. A pull request that has waited two days for review surfaces in a catch-up 1:1 long before it surfaces in a retrospective, and only if the meeting happened.
Delegate the work and keep the information
New managers either hover or vanish, and Fournier gives a practical middle. Keyvan Akbary's notes on the chapter list her tests for how closely to watch a piece of delegated work. If the team's goals are advancing, the systems are stable and the product manager is content, a glance is enough. Look harder early in a project and less as it matures. Get your information from the systems you already have, the tracker, the deploy log, the monitoring, before you ask a person for it. Set clear standards for code and operations so that surprises are rare. Treat bad news and good news with the same tone, so that people bring you the bad news early.
Take an on-call rota as the worked example. Hand ownership of the rota to the team, with the standard written down (a fair rotation, a maximum shift length, a handover note at each swap). Then read the incident channel and the paging history yourself rather than asking in standup whether on-call is fine. You will know it is not fine before anyone tells you, and the engineer who owns the rota will not feel supervised.
Managing people who were your peers last month
This is the part of the first year the book handles most honestly. Fournier's advice, which several readers' notes report in near-identical words, is to acknowledge the awkwardness out loud, to be a little vulnerable and ask for their help with the new dynamic, and to be very cautious with the authority to override their technical decisions. People who did not want to manage will still be sensitive to the sense that you were rewarded.
She also suggests the trade that makes it work. You do less of your old technical work and take on the management work, which creates room to hand your former peers more technical scope.
What the manager refuses, then, is to re-open technical decisions they would have made differently. Override only when the cost of being wrong is high and hard to reverse. A former peer choosing the test framework for a new service gets to choose. The same person about to drop a column three other services read gets a question, and the question should be about the risk, with the decision left with them if the answer is good.
The thread through all four
Each of these is a decision about what you stop doing. You stop holding the tech lead's design calls, you stop treating 1:1s as moveable, you stop asking for status you could read, and you stop defending your old technical opinions. Fournier said in a Y Combinator interview that engineering management is a technical discipline, and that new managers reach for code because switching between deep focus and the broad focus of running a team is hard. The first year is mostly learning which kind of focus the job needs on a given afternoon.
Where this sits in the standard
All four decisions sit in the People Leadership domain of the EMA Competency Framework. The Body of Knowledge units on delegation, ownership and decision rights and feedback and difficult conversations cover the mechanics in more depth, including how to decide which decisions you keep.
EMA-I is set at exactly this scope, one team with you acting directly. Its scenarios tend to look like the former-peer case above: a decision you doubt, made by someone whose trust you need.