Installing the Operating System: Taking over an engineering team without breaking it (Engineering Leadership, Honestly)

You have been handed a team. On about day 3, something will go wrong in front of you, and you will want to start fixing it.

Maybe you were hired in from outside and have met 4 of them once, for 45 minutes each. Maybe you were promoted, and until Friday you were one of them. Maybe somebody left, and you were the obvious person to catch it. Maybe the team has run without a lead for 7 months, and everybody has quietly worked out how to survive that — a different problem, and a harder one.

Whichever it was, you are now responsible for a system you did not build, staffed by people you do not yet know, running rules nobody wrote down. Accountability moved to you the moment it was announced. Context arrives over months. Trust does not transfer at all.

This is an argument about sequencing

Not whether to change things. You will; that is the job, and a lead who inherits a team and changes nothing has usually decided that being liked is safer than being useful.

It is about the order — because almost every expensive mistake in taking over a team is a right change made at the wrong time, by somebody who had not yet earned the standing to make it. Every gap between how a team runs and how you think it should run exists for a reason. The bad reasons are the easy ones. The expensive ones are the gaps that exist for good reasons you cannot see yet, and that your correction quietly breaks.

What is inside

• The 4 arrivals — hired in, promoted up, catching a departure, inheriting a team that has been leaderless — and why the advice diverges immediately
• The questions to ask while you can still ask them naively, and how to reconstruct the handover you will not get
• Everyone you must meet in week one, including the person who wanted your job
• One decisive move in the first fortnight, and why exactly one
• The listening tour that owes decisions, and its due date — a tour that never produces one teaches the team that you ask questions and do nothing with the answers
• The 4 kinds of debt you inherited, including the one nobody writes down
• The install sequence for days 30 to 90: one-to-ones, feedback, the definitions, the daily rhythm, refinement, planning, review, retro, the quarter, reporting outward — in the order where each part holds up the next
• Day 90, and the honest question: no longer how is it going, but what have I installed, and would it survive me

That order is the most opinionated thing in the book, deliberately. Some parts hold others up, and installing them out of order produces a system that looks installed and is not. A retro run before there is any safety produces silence — and silence produces a retro that cannot be fixed later.

And for the arrivals that are not clean

A closing part on the harder versions: promoted over your peers, a team already in trouble, following somebody the team loved, and arriving into a distributed team. Plus a chapter on what you will get wrong, because you will.

The book ends with a 90-day calendar, the operating system laid out one layer at a time, templates for the first-week questions, the debt register and the change announcement, and the exact sentences for the conversations that are hardest to phrase.

Who it is for

Engineering leads and managers taking over an existing team, first-time or experienced — and managers of managers who want their new leads working from something better than instinct.

29 chapters across 5 parts, by a writer who has taken over teams 8 or 9 times across 3 decades and 3 countries — and who is specific about the 2 occasions he did it badly.

Book 3 in Engineering Leadership, Honestly — for people leading inside constraints they did not choose.