Skip to content
back to the episode
Episode summary2024CTO

Herding Cats: Delegate, Don't Write More Code

The third Code of Leadership episode takes on the book Herding Cats, picked by the guest — Evgeny Kuzovlev, CTO of Tinkoff. He and Alexander walk through all ten chapters: from typing people by cat breeds and looking in the mirror to empires, working with your boss, and loneliness as the price of the role.

Code of Leadership · episode #39 min read

This summary is shorter than the full episode; examples and assessments reflect the participants’ experience and views.

The main thread of the material
01

Cat breeds and the road to team lead

The guest introduces himself: Evgeny Kuzovlev, CTO of Tinkoff, who spent years building international fintech companies and several IT teams. He picked the book because he sees team leads as the key element of any team's success: their teams do the bulk of the work, while the leads themselves, at the moment of growth, are left alone with their fears and uncertainty. The book is over twenty years old, written before agile methods were much discussed, yet it already answers fears that feel contemporary. Alexander walks through the contents — ten chapters, an afterword and a couple of appendices — and calls the advice to write your own project management system obsolete, now that the market is full of them. The most common route into the role, in his experience, is this: a strong engineer asks for more money or a new challenge and gets a team instead. Some cope, but the company loses a specialist on the spot — outside big tech there is no other career track.

Evgeny adds that a new lead often takes the promotion literally — I will write twice as much code — when the role is not about code but about understanding the team and delegating. He defends the idea of typing people by cat breeds: a team is not a set of interchangeable bricks but people with unique skills and temperaments. His own example is a brilliant engineer who was toxic in equal measure: after his review comments people came in to resign, and the only working arrangement for him turned out to be isolation, because inside a team he would have destroyed it. Evgeny's own turning point came when, after developers, he took over operations, sysadmins and network engineers and stopped being the strongest specialist: a manager is not obliged to be one. Hence the rules — praise publicly, give negative feedback privately. Alexander recalls Tuckman's group dynamics but finds the typology incomplete: the author collected vivid characters, and the third type, the mongrels, sounds dismissive.

02

The mirror, two axioms, a control table

The second chapter is about managing yourself, under a look-in-the-mirror metaphor, and Evgeny reduces it to reflection — the foundation of any manager's growth, even though, as he remembers it, the word itself never appears in the text. The first mistake of a new lead is to assume that he does everything right and the results fail because of his people, neighbouring teams and circumstances. He then singles out the two pains he sees most often. Tasks must be delegated rather than carried alone: not only coding but organising the team's work, because there is one lead, requests from adjacent departments and management are many, and the lead's strength is his team. The second pain is the fear that there is nothing left to pay you for: you no longer write code, test or analyse, only attend meetings. Alexander recalls the saying that the team wins and the coach loses, and advises keeping a log of decisions — architectural ones and engineering practices — or later you cannot unwind why everything changed.

Evgeny criticises the chapter on leading the pack: the title promises leadership qualities while the content is about process — how to stop the cats scattering into their boxes. Its leitmotif is two axioms: the first run of any process always takes longer than planned, because something you never anticipated is bound to happen, from Taleb's black swan to a blocked access badge that keeps an employee out of the building. Alexander, a certified project manager himself, recalls that in the early 2000s software was run as projects — scope, deadline, team — and that project management is still needed wherever autonomous product teams have to converge: everyone finishes the design of a mobile app at the same time, and the Sochi Olympics cannot be assembled from independent projects. The second half of the chapter is about growing your own replacement: you will take a holiday or fall ill, and with a deputy the system is more fault-tolerant. Evgeny adds that in several large companies preparing a successor is a manager's task number one in a new position.

03

Meetings, empires and a leader's loneliness

In the chapter on organising success Evgeny highlights one idea: the leader has to remember where the team is heading, while everything gets in the way — a manager's question about regulatory requirements, neighbouring teams, a spoiled mood. In the product paradigm this is harder than in the project one: turns come at 90, 180 and even 360 degrees, so it is worth fixing where you are taking the team and the product for at least a year and agreeing it with your manager. Evgeny wants to show the project managers he and Alexander share the table of what can and cannot be controlled: the right-hand half is not worth the effort. On meetings Alexander goes down the list — a weekly team meeting, the project meeting the original calls, he thinks, a design meeting, one-to-ones, the retrospective — and notes that the ritual set depends on your process: Alexey Pimenov's book on the Kanban method arranges cadences differently. The shared conclusion: interrupt meetings without an agenda.

The sixth chapter, on technical leadership, is one Alexander finds dated: it would need today's practices — tests, delivery pipelines, design. Both remember a time with no separate testers or analysts, when an engineer specified, built and checked the task himself; then domain complexity outgrew one head, and now platform tools hide it away again and responsibility returns to engineers. A leader's decline means micromanagement on one side and flying off in a helicopter, abandoning the team, on the other, plus the unrecognised geniuses who hire technical stars and the office politicians: an empire is shaky because a self-absorbed emperor has favourites and punishes mistakes instantly. The rise condenses into five foundations — understanding, communication, delegation, control and involvement. The chapter on the boss brings six expectations from above and a ban on Potemkin villages; Alexander notes that the boss there is a woman, which is unexpected for 2002. The closing chapter covers remote work, economic crises and technology revolutions, which the participants map onto today's AI boom, plus loneliness as the price of leadership, and the next episode is promised in about a week, on a book about leadership in the navy.

Takeaways

What to take away

  1. 01The most common route into the lead role is promoting a strong engineer who got bored or underpaid; the company loses a specialist, and the new lead assumes the job means writing twice as much code.
  2. 02Both skill and temperament count: a brilliant but toxic engineer drove people out with his review comments, and the only workable arrangement for him was working in isolation.
  3. 03The two axioms of the process chapter: the first run always takes longer than planned, because something you did not anticipate will happen — from a black swan to a blocked access badge.
  4. 04Evgeny recommends the book to anyone one or two years into the role who lives with the fears of not being the best engineer, of mistakes and of loneliness; those past that level get a snapshot of twenty-year-old expertise.

Sources