Vantage on management: What to read, when, and why ru en

At my last job, I sometimes found it challenging to convey my brilliant management ideas to colleagues. After some reflection, I realized I had drifted into an overly narrow and specific conceptual field, which often forced me to translate concepts from my internal representations into more or less commonly accepted terms on the fly. Not only is this hard, but people don't always see you as a smart person while you're doing it :-D

Thus, I decided to catch up with the latest achievements of human thought and, about a year ago, stocked up on 9 top-rated management books. With the idea of surveying the situation from a bird's-eye view, standardizing my glossary, and gathering arguments for the future.

I spent the whole of last year reading these books, but, against my usual habit, didn't write any reviews:

• At my pace of writing, a review of 9 books would have taken a whole month.
• All the books are top-tier — lots of readers, high ratings, plenty of reviews online — no point in repeating.
• The books are essentially textbooks and/or manifestos. Writing reviews of obviously solid textbooks just doesn't make much sense.

Instead of multiple reviews, I decided to prepare a single overview post with brief descriptions of each book, recommendations on when to read it, and a few notes. You're reading it right now.

So, let's get started.

Notes

I organized my reading in historical order: from more basic and older concepts to newer and more advanced ones. The books in this post are listed roughly in the same sequence. Of course, this sorting is only approximate — the books overlap in ideas, as they were all published within the last 20 years.

I also want to remind you that any named thing — Scrum, Kanban, Teal organization, Humanocracy, etc. — is, de facto, a memeplex [ru] — a set of atomic practices and ideas that have been grouped for convenience. Just because this particular set has worked well for someone doesn't mean it will work well for you.

We should study such named sets of practices, not to mindlessly follow them, but to break them down into atomic practices, understand how they interact with each other, and use this knowledge to assemble our own unique set of practices for our team/organization.

Common Drawbacks

Despite the differences in authors, topics, and time of publication, the books share several common traits — not all of them positive.

First, most of these books are written by managers for managers. Sometimes, even by consultants for top managers. This leaves its mark on both the style of writing and the topics they choose to cover.

The practical problems of frontline workers are touched on only lightly and superficially, as are the issues of their interaction with managers and the described practices. Instead, the focus often shifts to how managers and businesses interact with each other and with teams as a whole — essentially, on how to make things more convenient for the managers themselves. This is especially true of books that conceptually precede the "teal organizations." The gap between managers and frontline employees sometimes shows through quite starkly, and I'm not even sure the authors — or a significant part of their intended audience — notice it. At times, this leads to rather questionable claims from a practical standpoint.

Much of the attention in the books is often given to large companies and large projects. This isn't always a bad thing, but it's something you should always keep in mind. Companies with 10, 100, 1000, or 10000 employees face very different problems and have very different criteria for what counts as a successful solution.

The older the book, the more it is steeped in, let's say, caricatured masculinity. I used to think that all those baseball, sports, cars, and survivalist analogies were just a relic of the 1980s and of pseudo–improvement courses. But apparently not — authors still use those analogies, which means the target audience for management books is responsive to them.

Second, most books are not just textbooks, but also manifestos of specific practices. Thus, most of the space is devoted to positive examples; negative scenarios are discussed less, abstractly, and not as deeply.

At the same time, we remember that "all happy families are alike; while each unhappy family is unhappy in its own way". So, the primary problem of any team is not how to do things "right," but how to identify and work through its own unique wrongness. That's why, when I started reading, I hoped to find deep dives into negative scenarios; instead, I almost did not see them.

All the books that focus on the memeplex — a set of practices — walk a fine line between a list of useful tools and a cargo cult. Accordingly, I have an unprovable suspicion that most people who use these sets don't really understand why they are the way they are or how they actually work.

Third, for some reason, everyone strives to derive modern management practices from the history of management in factories, especially from Japanese ones, and especially from shop floors and assembly lines, rather than, for example, from the work of engineering offices or research/science teams. I fundamentally disagree with and disapprove of this approach, particularly in our time and especially when it comes to software development.

In one of the upcoming posts, I'll focus on how engineering teams are closer in nature to scientific ones than to production units — and what that means for management.

Fourth, the books pay little attention to the peculiarities of software development (except for Scrum/Kanban, of course), described practices should be transferred to the IT sector with caution, taking into account its specifics.

In the end, even though all the books are good, I still found myself swearing out loud and facepalming from time to time while reading them.

Essential Scrum (2013)

A detailed explanation of Scrum with pictures: "from scratch to Scrum Master".

The author — Ken Rubin — a consultant and coach since the 1980s; has a technical background in Smalltalk and OOP; has extensive experience in management positions and entrepreneurship; one of the pioneers of Scrum.

The book is useful when

• You're interested in history.
• Your organization is in a total mess, and you need to quickly roll out something that works, is standardized, and is understandable.
• Things were fine until someone with shining eyes showed up and started pushing the "idiomatic and only true version of Scrum", and you suddenly need to speak the same language to either stop or support the madness.
• You enjoy making people suffer, but you're not allowed to use Waterfall anymore.
• You are an outsourcing vendor, and the client understands nothing but Scrum.

Notes

The concept of Scrum dates back to around 1986 — basically, it's my peer. It's a good thing, but in its pure form it's already outdated.

At the beginning of the book, the author praises the clarity and conciseness of the illustrations. In my opinion, the "pseudo-3D with frills, gradients, and handwritten italics" style is very far from conciseness, but it does hint at the historical context and target audience.

The author points out that a lot of people look at Scrum as a modified Waterfall for the new age, and claims that this is not the case. However, given the focus of the book and manner of presentation, I would say that this is precisely the case — a Waterfall modified for quick feedback. I mean not the entire Scrum concept, but the specific Scrum from the book.

While reading this book, I almost broke my forehead from all the facepalms.

Succeeding with Agile (2010)

The book is about how a manager can live with Scrum or adopt Scrum. Its ideas can be applied to other Agile methodologies, provided you thoughtfully adjust those ideas to your specific circumstances.

The author — Mike Cohn — a consultant and coach since the 1990s; has a background in C and C++; founder of a consulting agency that implements Agile and Scrum in companies. One of the pioneers of Scrum.

The book is useful when

• You already use Scrum or something similar and need to sort out work issues, mostly among managers.
• You already use Scrum or something similar and want to improve processes, but don't know where to start.

Notes

Respect to the author for clearly pointing out that all memplexes from books and courses are not a guide to action, but a template that one should bend to fit their own specific needs.

For a pilot Scrum project, the author suggests taking a project not larger than 5 teams :-D So I dare to assume that if you have fewer than 5 teams in your company, you probably don't need to bother with Scrum at all :-D

The book pushes, in various guises, the idea that you need to "jolt" the team from time to time. Now it's clear which methodology the Belarusian government works by (local humor).

Kanban (2010)

Detailed explanation of Kanban with pictures.

The author — David J. Anderson — a consultant and coach, a manager since 1991, a pioneer of Kanban. I couldn't find references to his experience in frontline positions, but that doesn't mean he has none.

The book is useful when

• You want to understand Kanban or need to explain it to others.
• You often use the words "evolution," "adaptation," "optimization" in your speech or thoughts and want to use them more often.
• You want to practice process engineering without causing suffering to yourself and those around you.
• You want to adopt a commonly recognized, ready-to-use framework for work organization that fits modern realities.

Notes

Essentially, Kanban is the first well-developed, consistent, and accessible set of practices for truly flexible development. Scrum doesn't count, since it's flexible only in words. The historical Agile Manifesto doesn't count either, since it's just a manifesto — not everyone can make use of it.

Kanban was developed between 2002 and 2007, which already makes it significantly more relevant and modern than Scrum.

Kanban is about evolution and changing processes. Accordingly, the author states that there can't be a test/checklist for the level of Kanban adoption. At the same time, on the author's consulting company's website, there's a picture of him next to a large table titled "Kanban Maturity Model" — Kanban or not, you have to sell consultations somehow.

What I like about Kanban is that it shifts the focus from money-related metrics (which are not always reliably measurable) to the processes the team works with. And that's the right approach.

The author insists that the engineering team (and engineering management) should not have much influence on prioritization. I fundamentally disagree with this, as well as with some other claims in the book.

David J. Anderson rightly points out that the importance of task prioritization is greatly exaggerated. In most cases, it's already clear what needs to be done next. I tried to convey this simple idea to some colleagues at Palta for a year, but failed. It's nice to know that some authoritative people agree with you.

At the beginning of the book, the author states that Kanban is about processes and optimizations, not about task boards. But judging by how the topics are distributed throughout the text, the book still ends up being about boards :-D And a bit about processes and optimizations.

The Lean Startup (2011)

How to kick off a feedback loop on the example of startups.

The author — Eric Ries — an experienced startup founder who started on a technical path.

The book is useful when

• Always. We'd better gift The Lean Startup to every 20-year-old to casually clarify some aspects of our interaction with the universe and help young entrepreneurs avoid trivial mistakes.
• You're launching a startup, starting a new product, or just getting involved in some venture.
• Your company/team does not know what to do next, there is no strategy, you don't understand what's going on.
• You need to act in conditions of extreme uncertainty.

Notes

The author built his career on a technical track and rose to the position of CTO, which is evident in both the style of presentation and the focus (unlike in other books).

The book contains many examples of real business cases.

The book itself is about startups, and the author occasionally points out their conceptual differences from more established businesses. In my view, nowadays, everything is a startup to some degree, so the book will be helpful to everyone. The key is to choose abstractions wisely.

The Lean Startup suggests an interesting concept of measuring progress through the number of validated hypotheses rather than the amount of money, tasks, clients, or units delivered. In conditions of high uncertainty, it's not so important how fast you're moving, but where exactly you're heading. Accordingly, the viability of a startup can be measured by how many radical pivots it can still make.

In case you plan to read the book, I suggest looking at its ideas through the lens of bridging science, engineering, and management.

Reinventing Organizations (2014)

How people can work together the right way: effectively, smoothly, without stress and without suffering, when everyone is satisfied with the result. Not the way things are done at your office.

The author — Frederic Laloux — is a consultant and coach; besides that, I couldn't find anything remarkable in his biography except for this cool book.

The book is useful when

• Always. To know that there are other ways to work. I especially recommend it to people in frontline roles, so they can see which direction to push management when a chance arises and consciously choose where to work.
• "You have gained power your father never dreamed of" (c), but you want to use it for the good of the team and the company.
• You have enough authority/influence in the collective to initiate meaningful conversations about how to work better, but you're not sure which direction to take. Or you plan to become such a person ;-)
• You believe in people/colleagues, and it makes you cringe to see how many modern organizations don't.
• Your current place of work is draining your soul, and you want to fix it.
• You are interested in self-organization.
• You are interested in practical cases of non-standard management approaches.
• You want to expand your set of atomic management practices by adding some "non-classical" ones.

Notes

The author conducted research and built a coherent theory on its basis. One cannot claim that this theory is detailed enough or completely correct, but the very fact of such work makes the book stand out from many others.

Frederic Laloux introduces a classification of organizations based on management focus, goals, and level of trust. He then shows how, throughout human history, organizations have evolved from "red" (authoritarian) to "teal" (self-managing). Finally, using real-life cases, he describes how today's frontier organizations — the teal ones — operate, noting that they are only just beginning to emerge.

Since teal organizations are only beginning to emerge, the author points out that the book cannot serve as a textbook — no one really knows how to build teal organizations properly.

And if I'm ever asked to name the most unfortunate labeling in human history, I'd point to the color classification of organizations from this book. For me — and, I suspect, for a lot of others — a "poetic" naming of categories instead of a "qualitative" one is a huge red flag. For this reason, I avoided Reinventing Organizations for years — I mean, what professional in their right mind would classify organizations by colors? Turns out, some do :-D

To avoid misunderstandings, the author explicitly states that:

• It is incorrect to claim that a certain organization has a pure color X — there is always a mix of colors.
• Though the new types of organizations emerge with time, new ones do not entirely replace the old ones. Organizations of all colors always coexist. Some niches require a more "primitive" approach; others do not exert enough pressure to transition to a more complex structure.

In other words, the author speaks more from the position of a motivated researcher than a dogmatic propagandist.

The book explores 11.5 organizations, ranging in size from 90 to 40000 people, and ages from half a century to 5-10 years. The stories of these organizations and the practices described are interesting even without considering their "tealness," so the book will be helpful even if you're not interested in the color-coded pants differentiation.

By the way, none of the organizations studied is owned by its employees. In other words, ownership rights and management style are orthogonal things.

The author claims that both statements: "all employees are lazy, stupid liars and thieves" and "all employees are proactive, smart, and responsible specialists" are self-fulfilling prophecies. How management views people is how they behave. I fully agree with this.

Also, Frederic Laloux often mentions the absence of political intrigue and other negativity in teal organizations. In my view, this may have various explanations: from a sign of the success of the teal concept to the survivor bias or the result of the small spread of the model — in the current state of the world, such organizations may attract more motivated and mature people than the average on the planet.

Humanocracy (2020)

The book is about the harm bureaucracy brings and, partially, about the benefits of meritocracy: how and why to fight the former and implement the latter.

The authors:

• Gary P. Hamel — a consultant and coach, founder of a consulting company, teaches as a visiting professor at London Business School. If you dig around, you can find a list of interesting management experiments he has conducted in companies.
• Michele Zanini — a consultant and coach, founder of a consulting company (together with Gary Hamel), previously worked as an analyst focusing on international politics, the Middle East, and Eastern Europe.

The book is useful when

• You plan to fight bureaucracy in your organization/team.
• You want to delegate more: both work and responsibility.
• You've added up the salaries of the head office managers and can instantly name 10 better ways to spend that money.
• You want to ameliorate the work culture in your organization/team.
• You want to expand your set of atomic management practices by adding some "non-classical" ones.
• You want to laugh at some funny facts and stats from the world of "bureaucracy gone wild".

Notes

As the title suggests, the book offers a concept that stands as an alternative to the classic hierarchical bureaucracy — one that's all about people and for people. Still, I'd say that for now it's more of a marketing label than a fully-formed memeplex. So you can read it as a powerful, well-argued manifesto against bureaucratic cancer, accompanied by a set of SOTA methods for treatment and prevention. And, to some extent, as a collection of amusing stories.

I won't list the arguments and practices against bureaucracy here — that would be a retelling of the book.

Instead, I'll share a couple of fun things I noted:

• At some point, SAP in Germany discovered they had over 50000 KPIs. Being a resident of Germany, I can add that they probably missed another 150000 ones.
• A steel plant with decentralized management has a headquarters of 200 people, while one with centralized management has 1000.
• One scientific study found that correlation between real productivity and self-assessed productivity is on average 0.29, while for managers it's 0.04 (!).

The book ends with a statement that bureaucracy can be restructured from within. At the same time, Reinventing Organizations claims that similar transformations cannot be made without support from the very top. I'm currently leaning towards the opinion from Reinventing Organizations.

Many Voices One Song (2018)

The book is about sociocracy — a set of tools and principles that help distribute power across a collective/community.

The authors:

• Ted J. Rau — a PhD in linguistics (syntax and semantics) and, of course, a consultant and coach; co-founder of Sociocracy For All.
• Jerry Koch-Gonzalez — consultant and coach; co-founder of Sociocracy For All.

The book is useful when

• You sincerely decided to adopt decentralization in your team/organization and need a ready-to-use set of practices to start with.
• You want to increase the level of autonomy of people and teams.
• You have problems with communication and delegation in your team/organization, and want to solve them.

Notes

Unlike Humanocracy, this book presents a complete memeplex, which includes several key concepts:

• Circle — a group of people who work together and decide together how to work. Essentially, an autonomous team, but with nuances. Circles are organized into a kind of hierarchy, also with nuances.
• Decision-making by consent — if somebody puts forward a proposal to the circle, it will be adopted unless someone raises a significant objection.
• The role of the circle leader — helps the circle move in the right direction, something like a manager-through-respect but not actually a manager :-)
• The role of the circle delegate — a representative of the interests of the child circle in the parent circle.
• Double-linking — each circle is connected to the parent one through two representatives: the leader and the delegate. According to the authors, this helps avoid a bunch of problems: from information distortion to manipulation and abuse of power.

The structure described resonates well with my personal views, but I can't say I agree with everything in the book or that I'm 100% sure of its effectiveness. For example:

• Sociocracy, in my opinion, requires a bit more maturity from colleagues than I've seen in real teams. On the other hand, maturity is something that can be developed, so this is not a conceptual problem, but a purely practical one.
• Many of the communications and problem-solving examples in the book seem very Western-centric, so they may not suit all cultures.

Overall, while the book is about sociocracy as a concept, it also serves well as a handbook for work organization practices. Some practices and tools are described in such detail that I skimmed through parts of the text. But if you need to quickly implement one of these practices, such detailed descriptions will help convey the idea to all colleagues.

Team of Teams (2015)

The book tells how a U.S. Army general "refactored" a joint task force to fight Al-Qaeda in Iraq. 50% of military anecdotes, 25% of military showmanship and praise, 25% of management.

The author — Stanley McChrystal — a retired U.S. Army general, not a consultant or coach after retirement, he founded a consulting company. In 2010, he came into conflict with the U.S. President's administration, which led to his resignation.

Co-authors: Tantum Collins, David Silverman, Chris Fussell.

The book is useful when

• Your team/organization slowly responds to changes in the environment, and you need to do something about it.
• You need an advantage over a larger, more organized, and more centralized competitor.
• You are a leader of a large organization/team (or want to become one) and are looking for references to build your own behavior.
• You're tired of reading "theory" and want practical notes.
• You love military anecdotes. The book also includes stories about civilian organizations, but mostly in a military or near-military context. For example, there's a description of how medics work in a civilian hospital under extreme conditions.

Notes

The book is cooler than it seems at first glance.

At first, I was skeptical about Team of Teams. An army general writing about management — given what I know about how armies are organized in the post-Soviet space, I was expecting pure cringe. But after reading it, I concluded that the book is solid not only in content but also in concept: one simple book devoted to one specific idea, grounded in real practical experience. A clear development of the idea, combined with the author's personal experience and impressions — we need more books like this.

One can describe the problem faced by the Task Force as follows.

A highly organized, informed, optimized centralized structure encountered an inefficient, uninformed, disorganized decentralized structure and started losing because it couldn't keep pace. They were winning battles, but not the war. To turn things around, the command decided to flatten hierarchies, remove centralization, and push decision-making down to frontlines.

Retrospectively, the changes took shape in the concept of "team of teams":

• Bring people together into teams with broad decision-making authority.
• Establish horizontal links between teams by every available means — from how the workspace is organized to ongoing long-term team member exchanges. This creates horizontal communication channels through which information goes directly to those who need it, without traveling up and down multiple hierarchies.
• Nurture a culture that encourages initiative, autonomy, and responsibility.

In this way, Team of Teams strongly resonates with Sociocracy.

In short, the book is about stepping back and letting things flow :-)

Here are some more interesting notes:

• This is the only book that uses a scientific organization — NASA — as an example of organizational structure.
• The reforms in the Task Force partly led to one of the largest leaks of secret army data to WikiLeaks. The author takes the position that this is an inevitable risk, and even considering it, the reforms were worth it. I'm not sure it would make sense for the general responsible to claim anything else — but still.
• At some point, the command delegated decision-making on airstrikes to subordinates. If an army general can afford such liberty in a military operation, then a regular manager should definitely be able to do similar things.

Managing Science (2017)

The book is about how large scientific organizations are managed.

The author — Ken Peach — a physicist with deep experience as a top manager — was the "Deputy Head of the Particle Physics Experiments Division" at CERN, headed/organized several institutes.

The book is useful when

• You plan to build a career in science and want to understand how things work there.
• You received a managerial role in the science area and want to quickly get oriented.
• You are interested in the practical aspects of managing large teams, described from a first-person perspective.
• You get hit with shady bureaucratic regulations — say, hiring quotas — and you have to figure out how not to let them wreck everything you've built through hard work.
• You like the scary stories about bureaucracy.

Notes

This book leads the pack in terms of practical examples of handling negative scenarios. That doesn't mean it has a great many of them, though.

Managing Science looks more like a factual description of how science is organized from a management perspective than a collection of best practices or a description of management philosophy. Certainly, practices and philosophy are present there too, but they rather accompany the description of the scientific organization's "building" than form the basis of the book.

So, the book is not about how things should be, but about how they are.

On one hand, this is expected from a work of a physicist; on the other hand, I had hoped for more philosophical and practical insights, as I'm very interested in borrowing management experience from scientific collectives. It's a pity, because this is the only book on management in science that caught my interest. I'll keep looking; if you know any others, please let me know. I'll be grateful.

Despite the book's descriptive nature, the practices and philosophy are well presented: up-to-date, rational, and consistent with other books in this post, so you can also read the book as a textbook. Perhaps for some, this format will even be more convenient.

Overall, the author keeps a critical eye on the edifice of modern scientific bureaucracy. However, he also acknowledges that bureaucracy and regulations are inevitable, especially in a state-funded industry.

The book contains many interesting ideas; I especially like this one:

Under good leadership, it is possible that every member of the team performs excellently and then none are unsatisfactory or in need of significant improvements in performance; forcing quotas on the various grades means inevitably that the grades do not mean what they purport to mean.

I'd really suggest HR and managers think about this idea before kicking off another round of evaluations.

What should an engineer read from the list?

If you want to quickly level up in management, I would recommend reading:

• Kanban — to form a set of practices for operational management that can be customized in an engineering style.
• The Lean Startup — to form a set of strategic management practices that can be applied in an engineering style.
• Reinventing Organizations — to form a set of culture-building practices.

Do I need it, really?

In my opinion, yes, you do.

• Management is not rocket science. Most of the practices are quite simple if formulated clearly enough (which many people just don't do). C++ templates or, say, database transactions are way more complex.
• Everything is moving, one way or another, toward flat structures where every team member knows a bit about management, which makes this knowledge important both for your effectiveness and for your career.
• Pushing flat structures, decentralization, and self-management is more beneficial for employees in frontline positions.

And what about books on psychology and communication?

Currently, I am very skeptical about using professional tools from psychologists/psychiatrists/any other non-technical areas in management. These tools were developed for different contexts and for people with varying levels of education, not for managers.

For example, for use by psychotherapists with PhDs working with married couples in the 1970s. This has nothing to do with teams of professionals in the 2020s :-)

In nearly 20 years of working in IT, I've never seen a successful use of such tools. What I've seen, many times over, is their misuse, which only fuels conflicts, breeds distrust, and sows discord.

I won't wax lyrical here, but briefly, my reasoning is:

• An average manager is not competent enough to use tools that require specialized non-managerial education. And they don't have time to acquire such competence.
• An average frontline employee is smart enough to notice unprofessional attempts to use such tools on them, but not competent enough to understand why and for what purpose they are being used. Often, there's no time to consciously process what's happening, and the reaction is subconscious.
• As a result, conflicts arise instantly out of nowhere: "I'm being manipulated," "HR is lying," "manager is acting foolishly".

As soon as I find something worthwhile, specifically about professional culture, that is close to reality, I'll definitely study it and share my thoughts.