An Elegant Puzzle, Part 1: Move Domains, Not People

The guest introduces himself: Evgeny, a senior engineering manager, fifteen-odd years in the industry — he started as an engineer, touched infrastructure, worked at a small company and came back to engineering management. He chose it because his first reading was full of aha moments: so that is why this works; I have seen this in my own practice.

Larson started with a blog — he worked through interesting problems, wrote posts, then compiled them into a book. Evgeny notes this is becoming a trend and Alexander explains why: writing a book from scratch is hard, whereas you write an article when you have just caught the moment where the puzzle clicked; enough such pebbles pile up and start to interlock into a book. The chapters end up independent: the book opens like a desk reference, your own context laid over the author's advice.

Evgeny adds that the book is not aimed at first-time managers: it skips how to run one-on-ones, but takes on the problems of an established middle manager and works as a springboard to the level of the organisation, not just your own team.

Seven chapters; the participants mention the introduction, organisations, tools, approaches, culture and careers, then discuss an appendix of papers with QR codes so you need not retype links; Evgeny took several away to read. Little text, many diagrams: a page or so and a picture that shows everything.

The chapter-by-chapter walk starts with forming teams and magic numbers. Larson advises against standing up empty teams or staffing one entirely with newcomers: better to grow one to ten and then split it. Evgeny has made that mistake himself — without a core, team and company culture get diluted, whereas a core speeds up onboarding and gelling. What the book lacks, he says, is why exactly it must be so; you work that out with practice.

Then the rule on direct reports: Larson suggests no more than eight, beyond which the manager turns into a coach who no longer holds context, while he sees a group of fewer than four as too small to provide that abstraction, with its manager effectively acting as tech lead. Evgeny liked the analogy that a team is an abstraction over complexity, and a small team a leaky one. Alexander recalls his talk three years ago on SOLID applied to management: dependency inversion means giving goals and rules, not a task list.

Larson does not cover how teams interact, Evgeny adds — that is where Team Topologies, read by the club earlier, complements him.

Alexander stresses the context behind the advice: Larson was writing from experience of hypergrowth. In slower growth, a new team cannot be hired for every problem; existing teams must maintain services while building new things. The rules need to fit the team's condition and the organisation's resources.

On-call runs into labour law: Larson names a minimum size for a duty rotation, and Evgeny was puzzled by it until he realised his contractual setting limits the hours a person may be on call each month. In his company two people could cover on-call — the service is stable — but, he says, such a rotation could violate the rules that apply to them, so the author's recipe works: raise duty to a unit whose teams share context, even if the neighbours know nothing of each other beyond an API contract.

The maturity chart gives three prescriptions: a lagging team hires, a team treading water introduces work-in-progress limits and learns to say no, and a team that has reached innovation gets slack, idle time, because the best code is the code never written.

Above all, move domains rather than people: Evgeny admits he used to break a well-gelled team by moving its engineers into a lagging one. Alexander offers a gentler variant — give the successful team's manager responsibility for an adjacent, similar domain and pull the weaker side up with shared goals.

The hypergrowth slide shows Uber, Google, Twitter and Facebook: in the participants' account, the company where Larson himself worked had over five thousand people by year four, and headcount went from two hundred to two thousand in two years — nobody is left to pass the culture on, every six months you are in a different company, and new people add entropy and load to infrastructure and developer experience.

Alexander saw the same: he joined in late 2016 as a manager of ten and kept rebuilding the setup, summing it up as growing through pain; later he split a large unit into four departments along business domains, and the next episode interviews the head of the product analytics department left alongside them.

Evgeny's headcount went from thirty engineers to two hundred in a year, and the first thing they designed was the hiring funnel: slots with three or four engineers available for each, because interviewers burn out and regular internal check-ins show them permanently in the red. Alexander recalls how in 2020 hiring was centralised and split into sections — the topic raised by Igor Maslov, the director of core technologies.

The second chapter they cover is tools, fifteen of them. It opens with systems thinking: input, output, a system and a feedback loop. Alexander says he has written a review of that primer and has met people it would have helped enormously, and Evgeny agrees that for engineers systems thinking becomes part of the DNA. Larson uses the same lens for the DORA metrics from Accelerate.

In goal-setting a strategy is a diagnosis, principles and actions; here Larson points to the book Good Strategy, Bad Strategy. The sign the principles are right is that they are uncomfortable: you will have to make trade-offs or say no.

Evgeny picks out the advice to keep two lists — work that cannot happen without you yet but could be delegated, and work you can hand over quickly. Identifying a year-long handover early lets you start preparing instead of losing that time.

Evgeny recommends a vision and mission at team level too: after that exercise his team stopped being the onboarding team and became the survey engine team, an onboarding graph being a special case of a questionnaire.

The heading calling migration the only effective way to pay down tech debt does not resonate with him — tech debt should be hygiene, part of a team's DNA, paid down regularly — and a migration is finished only when the old system is switched off.