The Manager's Path

Fournier organises the book by role rather than by topic, and the structure carries a thesis: each step is a different job requiring different skills, not more of the previous one.

Her insistence on this is the book's most valuable feature. The common failure mode she describes is someone performing the previous role competently in the new one and not understanding why it is going badly.

Each step is a different job, not more of the last one. Doing the previous role well in the new one is the failure.

Devmark’s reading — not a quotation from the book

She opens with what a report should expect, which is unusual and deliberate: knowing what good management looks like is the prerequisite for providing it.

Her account of one-on-ones, feedback and career conversations from the receiving end gives new managers a standard, and gives everyone else a way to ask for what they need.

Her treatment of tech lead is the clearest available, and she is firm that it is a role rather than a rank: a senior engineer who takes responsibility for a project's technical direction and the team's execution.

Her four archetypes — systems architect, project planner, team leader, and the one who mostly writes code — are useful because they let a person name which version of the job they are actually doing.

Her practical material on the transition covers the mechanics: running one-on-ones that are not status meetings, giving feedback continuously rather than annually, delegating without abdicating, and managing your own manager.

Her warning about continuing to write critical-path code is the one most new engineering managers need, and she is unsentimental about why it fails.

The step she treats as most discontinuous, because the feedback loop lengthens dramatically and you can no longer directly observe the work.

Her guidance on skip-level meetings, on identifying a struggling manager before their team disintegrates, and on holding managers accountable for outcomes rather than activity, is the most practically useful material in the second half.

At this level you cannot see the work. Everything depends on noticing a struggling manager before their team does.

Devmark’s reading — not a quotation from the book

Her willingness to address the unpleasant parts distinguishes the book: managing someone out, handling a toxic high performer, responding to a reorganisation, and dealing with your own manager being the problem.

Her position on the brilliant difficult engineer — that the cost to the team almost always exceeds the individual contribution — is stated plainly and is correct more often than organisations act as though it is.

Her chapters on director and executive roles cover setting technical strategy, managing across functions, and the shift from optimising your own organisation to optimising the company.

This material is thinner, which she acknowledges — the roles are more variable and less generalisable, and her own experience is the primary source.

Like Larson's book, it is written for engineering organisations in technology companies with clear career ladders and reasonable resourcing.

It also assumes a functioning organisation around the manager. For someone in a dysfunctional company, several prescriptions depend on organisational support that does not exist, and the book has less to say about that case.

Fournier is better on the human mechanics and the career progression; Larson is better on organisational systems and structural design.

They are complements rather than substitutes. Fournier is the better first book for someone entering management; Larson is the better second one for someone designing an organisation.

The role-progression framing, which lets you name which job you are actually in and check whether you are still performing the previous one.

And her standard for one-on-ones — that they belong to the report and are not a status update — which is simple, widely violated, and the highest- return change most new managers can make.