An Elegant Puzzle, Part 2: Reorganize Only as a Last Resort

The second half opens with the chapter on refactoring an organization as it grows. Larson's first advice is that if a reorg can be avoided, it should be: Evgeny has often watched a project moved, people and all, into a stronger part of the org in the hope that they will cope there. Start instead from the problem and from how you will know it is solved.

Then a basic checklist: how many people per team, how many managers are needed, what the headcount limits are, how teams will communicate. A change easily makes things worse: intermediary teams appear and the value delivery chain grows longer.

Alexander stresses the need for a clear, well-communicated goal and warns against building the structure around specific people. He is unsure which chapter contains Larson’s advice on that last point.

Evgeny adds a practice from his company: just as architecture decision records are kept for architecture, they started an organization decision record for organizational changes, holding the context, the options considered and the next steps. The document is shared across the organization, and later you can judge in retrospect how well the decision was made; he recalls the lead-through-context approach from the book about Netflix.

For Alexander the same thing looks like long documents on major reorgs, with comments and a summing-up: he goes back to them when preparing conference talks, and inside the company such texts work almost like case law.

Half of such decisions, Evgeny reckons, may fall away while you write them down: he heard in a podcast how an Amazon vice president of technology said about forty of his ideas died as he tried to fit them into a document — they sounded good in his head and bad on paper.

Next comes centralisation versus decentralisation. Larson offers a product approach: a change announced as a one-sprint experiment that can be rolled back meets far less resistance than the same change declared permanent.

Autonomy is balanced by communities and committees entitled to say that a technology does not fit the common frame. Evgeny's committee is open to teams: a team brings context or an RFC, but the decision stays with the team because the team owns the outcome, while the constraints live in a tech radar — a plugin of the internal developer portal, revisited once a year.

Alexander's guardrails come from a focus on platform solutions: there is no single company-wide tech radar, but there are platforms with dedicated teams, and when asked why you need some technology such as Tarantool, "it has been here for a while" is enough to keep it but not to get it supported: the total cost of ownership lands on your team.

On time management, the participants note that even experienced colleagues may struggle to offer advice because they are overloaded themselves. Work needs a place in the calendar, or it will expand to fill the available time; Larson suggests looking at where a month and a quarter go, blocking out focus time, and doing the meeting arithmetic: how many direct and skip reports there are, who needs a one-to-one, what can be delegated.

Evgeny recalls an experiment: a team reserved two morning hours for meetings and protected the rest as focus time. Other invitations were declined, but the organiser could return and explain why attendance was necessary. Around 70% of invitations were only to keep people informed; notes replaced those meetings, and Evgeny observed an improvement in the team’s performance.

Meetings need an agenda and notes. If participants resolve their differences in document comments, a separate discussion may be unnecessary.

On learning communities Evgeny recalls an internal reading club started with the Team Topologies workbook and an exercise describing each Team API, and Alexander a facilitator he brought in when splitting his unit into four parts.

Policies should work on the main scenario, while exceptions have to be collected and fed back into the rules, otherwise they drift from reality, like pandemic-era office regulations once everyone had moved to remote work.

Saying no is a separate skill: in English-speaking culture a refusal sounds like "yes, but", yet it has to rest on data, because priorities and velocity are what a manager genuinely controls. Alexander adds that a manager who says yes to everything becomes a transparent abstraction over the team: work flies straight in, nothing gets finished, and later you cut away the inessential like a surgeon.

The mirror mistake is seeing only problems: Evgeny describes a monthly engineering town hall with an Art of Possible slot where teams show what they built, and Alexander the image of a juggler too busy with flying objects to notice the applause.

Hero culture signals imbalance: constant overtime can mean that the team is not limiting incoming work. The manager should make results predictable and work sustainable; personal heroics cannot compensate for process problems indefinitely.

On Larson's chart compensation is tied to experience and runs into the ceiling of a band, which every company has even when the vacancy does not publish it; the participants qualify that what is really priced in is the expectation of how you will perform.

Someone hired near the top of a band will probably need a promotion to receive the next raise, and the manager must be ready to explain why; Alexander adds that hiring managers often dodge that conversation, so a year later the profession leaders have it instead.

Then the funnel: organic inflow, referrals and sourcing, which Larson counts as the manager's work and supplies with an outreach template; the participants note that a letter from a CTO or a VP gets opened more readily than a recruiter's.

Larson extends the metrics past the offer — onboarding, time to impact, promotions and departures: only that way, in Alexander's words, can market hires be compared with internal education programme graduates instead of taken on faith.

A competency matrix should inform interview criteria so that hiring and later promotion use the same expectations. Detailed matrices deserve priority for roles hired in large numbers; a simple scale without many levels may be enough for rarely hired roles.

Calibration needs a separate caveat: a distribution across a large workforce cannot be mechanically imposed on a small team. Evgeny recounts stories he has heard about managers hiring weaker people to meet future dismissal quotas; Alexander treats this as an example of rigid rules inviting gaming.