Saturday, February 21, 2026

Yes, Minister: Ten Management Lessons for the Modern Technical Leader

Last year, I re-read Graham McCann's A Very Courageous Decision: The Inside Story of Yes Minister and followed it up with Antony Jay's Management & Machiavelli. I had written about both books in my 2023 book list. But this time, rather than reading them as a fan of the show or a student of Machiavelli, I was reading them as someone who has spent over two decades managing engineers and products at scale. I was struck by how much the dynamics of Whitehall resemble the dynamics of any large technical organization. The satirical genius of Jonathan Lynn and Antony Jay is that they didn't just write political comedy — they wrote the most honest organizational behavior textbook that no business school has ever assigned.

For those unfamiliar: Yes Minister (1980–1984) and its sequel Yes, Prime Minister follow Jim Hacker, an idealistic but inexperienced cabinet minister, as he tries to reform his department and is thwarted at every turn by Sir Humphrey Appleby, his Permanent Secretary — a brilliant, articulate bureaucrat whose primary mission is to preserve the status quo. Bernard Woolley, Hacker's private secretary, is caught between the two, loyal to his minister but with a career controlled by the civil service. Jonathan Lynn, one of the co-creators, once described the British system as having "the engine of a lawn mower and the brakes of a Rolls Royce." The observation applies well beyond Westminster. I have seen the same pattern in every large organization I have worked in.

What follows are ten lessons I have distilled from the show and the books behind it, reframed for the modern technical leader. I wrote these not as abstract principles, but as things I have either experienced firsthand, coached others through, or wish I had understood earlier. The job of every technical manager is to ensure that they are serving the needs of the customer, period. But there are things that get in the way and it is also their job to remove obstacles.

1. Declared vs. Real Motivations

Lynn and Jay made an important observation in a 2009 Daily Telegraph article about what they called the "classic actors' studio question" behind the show: what's my motivation? They noted that there are always two answers — the expressed, publicly acceptable motivation, and the real motivation. The minister's declared motivation is to serve voters. His real motivation is to get promoted and re-elected. The civil servant's declared motivation is to implement policy. His real motivation is to raise personal status, expand the department, avoid blame, resist change, and minimize work.

This maps directly to what I have seen in large engineering organizations. When a VP pitches a reorg as "improving velocity," it is worth asking who benefits from the new reporting lines. When an engineer resists a platform migration, the objection may be genuinely technical — or it may be about ownership and career capital. Daniel Kahneman's work on framing and cognitive bias (which I discussed in my Continuing Education post) is directly relevant here. The best leaders I have worked with and for don't treat this with cynicism. Instead, they make it safe for people to surface what they actually care about — because once real motivations are on the table, you can design solutions that address them.

2. Creative Inertia

Sir Humphrey's most powerful weapon is what a previous minister called "creative inertia" — a portfolio of tactics to delay and block proposals without ever saying no outright. He forms interdepartmental committees that never converge. He buries critical documents at the bottom of thick briefing folders. He requests additional studies before any action can be taken. He strategically appoints allies to supposedly impartial review boards. The beauty of these tactics is that they look like process, due diligence, and collaboration. They are, in fact, the opposite.

In tech organizations, the modern equivalents are easy to spot if you know what to look for: API bar raising processes with no decision deadline, the request for "just one more benchmark" before approving an architecture change, or escalating a decision to a committee that meets quarterly. The antidote is to set explicit decision deadlines, assign a single decision-maker (a DRI, or directly responsible individual), and — this is the important part — treat inaction as a choice with consequences. Ram Charan's Execution, which has been one of my foundational management books, makes a similar point: execution discipline means decisions have owners and timelines, not just discussion threads.

3. Headcount Without Output

In one of the most famous episodes, "The Compassionate Society," a newly completed hospital has 500 administrative employees but zero patients. Sir Humphrey gives an eloquent explanation of why every single employee is absolutely necessary. The hospital is up for a Florence Nightingale Award. It is a triumph of process over purpose — perfectly staffed, perfectly managed, and perfectly useless.

I have seen versions of this in every large tech company. The platform team or the internal tools team that grows to serve its own ecosystem rather than the product. The internal dashboard with more maintainers than users. The question I ask (and recommend others ask periodically) is simple: if we deleted this team tomorrow, what customer-facing capability would degrade? If the answer takes more than thirty seconds to articulate, that is a signal.

There is a deeper structural reason why this happens. In organizations that aren't directly measured by business output metrics — typically revenue or profits — the only visible mark of success becomes organization size. To paraphrase Sir Humphrey: the leader with the larger organization is thought to be more successful than the one with the smaller organization. Headcount becomes the scoreboard. This is why it is essential that an organization's output metrics are tied to something directly connected to business outcomes, not to something that is actually the cost of doing business. Infrastructure size, internal tool adoption rates, number of services managed — these are costs, not outputs. When costs become the metric, you get hospitals with five hundred staff and no patients.

4. Language as a Power Tool

The show codified the civil service's coded language. "I think we have to be very careful" means we are not going to do this. "Have you thought through all the implications?" means you are not going to do this. "It is a slightly puzzling decision" means idiotic. "Not entirely straightforward" means criminal. "With the greatest possible respect, Minister" means you are an idiot.

Every organization develops its own version. In tech, "let's align on this offline" often means I disagree but don't want to fight publicly. "That's an interesting approach" means I think this is wrong. "Non-trivial" means this will take months. The proliferation of euphemisms is not just a communication problem — it is a diagnostic signal. When people stop saying what they mean, it usually indicates that psychological safety has eroded. Amy Edmondson's The Fearless Organization, which I read in 2023 and used as a book club read with my leadership team, makes the rigorous case for why this matters for team performance and innovation. Sir Humphrey's coded language is funny on television. In a real organization, it is a symptom of dysfunction.

5. The Information Asymmetry Problem

Sir Humphrey's greatest structural advantage is that he controls what the minister sees and when. Critical facts are concealed within innocuously titled reports buried underneath mammoth piles of papers. The minister, overwhelmed with volume, rarely reaches the important material. And when he does, he only has time for a skim-read. The civil service can legitimately claim they made the information available — while making it nearly impossible to discover.

This maps directly to how information flows in engineering organizations. Dashboards that show green while customers are complaining. Weekly status reports that bury risks in appendices. Architecture review boards where the real constraints are understood by only one team. I came across Didier Sornette's Don't Tell the Boss! in my 2023 reading, and it reinforced what I had observed empirically: the catastrophic failures in organizations — from the Challenger disaster to the financial crisis — often trace back to information that existed somewhere in the system but never reached the people making decisions. The counter-measures are not complicated, but they require deliberate effort: skip-level 1:1s, blameless post-mortems, and a culture where surfacing bad news early is rewarded rather than punished.

6. The "House-Trained" Manager

The show introduces the concept of a minister becoming "house-trained" — gradually adopting the civil service's worldview and defending the very status quo they were hired to challenge. Within months, the reformer starts speaking in the language of the institution. They begin seeing obstacles where they once saw opportunities. They develop empathy for the bureaucracy's constraints that crosses the line from understanding into capitulation.

This is also a familiar pattern: the new VP of Engineering who arrives with a mandate to "increase velocity" and within six months is defending the exact processes they were supposed to reform. The engineer who joins a legacy team, initially frustrated by the tech debt, but within a quarter is explaining why the migration is "more complex than it looks." There is a fine line between gaining necessary context and losing your original perspective. My advice: revisit your original assessment of what needed to change at regular intervals. Maintain external perspective through advisors or a peer network outside your organization. And if you find yourself defending things you originally intended to fix, ask yourself whether you have new information — or whether you have been house-trained.

7. The Five Universal Excuses

The show catalogues the civil service's standard excuses for failure. The Anthony Blunt excuse: there is a perfectly satisfactory explanation, but security prevents its disclosure. The Comprehensive Schools excuse: it only failed because of budget cuts. The Concorde excuse: it was a worthwhile experiment that provided valuable data. The Munich Agreement excuse: it occurred before important facts were known. The Charge of the Light Brigade excuse: it was an unfortunate lapse by an individual, now dealt with under internal procedures. Sir Humphrey claims these have covered everything so far — even wars (small wars, anyway).

You will recognize every one of these in post-mortems, quarterly business reviews, and performance discussions. Healthy engineering cultures replace excuses with systems thinking: what process allowed this failure? What guardrail was missing? The goal is not blame-free culture — accountability matters — but shame-free root cause analysis. This connects to what David Marquet writes about in Turn the Ship Around!, which I read in 2024: when you shift from a "leader-follower" to a "leader-leader" model, people take ownership of failures because they also own the outcomes.

8. The Gap Between Vision and Execution

Hacker repeatedly arrives with ambitious ideas — cutting bureaucracy, increasing transparency, reforming local government — only to discover that execution requires navigating a system that is optimized for its own preservation. His ambition is genuine; his leverage is limited. The system absorbs his energy and outputs committee reports.

This is the gap between strategy and delivery. A CTO can declare "we're going microservices" or "AI-first across the board," but if incentive structures, team topologies, and hiring pipelines aren't aligned, the strategy will be absorbed and neutralized by the existing system. Clayton Christensen's Innovator's Dilemma, which has been an early influence on my strategic thinking, describes a similar phenomenon at the company level: incumbent organizations develop antibodies against disruptive change. Effective technical leaders don't just set direction — they redesign the organizational machinery that determines whether direction is followed. In Machiavelli's language (from the Discourses): "he who proposes to change an old-established form of government in a free city should retain at least the shadow of its ancient customs." Even in reform, you need to work with the existing structure.

9. The Power of the Permanent Class

Ministers come and go — the average tenure in the show is about eleven months. Sir Humphrey and the civil service are permanent. This asymmetry means the permanent staff always has more institutional knowledge, deeper relationships, and more patience. They can simply wait out any reformer they don't like.

In most tech companies, the "permanent class" is the senior individual contributors and the middle managers who have survived multiple reorgs. They know why systems were built the way they were, where the bodies are buried, and which stated priorities are real versus performative. I recall writing in my review of Will Larson's Staff Engineer that operating at the staff level means "working on what matters" and that "title-chasing is less effective than doing the work at scope." The senior ICs who have been around longest are the ones who understand scope and leverage. New leaders who ignore this group fail. Those who genuinely listen, respect their knowledge, and find alignment between the permanent class's interests and the new direction — those leaders succeed.

10. Aligning Incentives Is the Only Durable Solution

The rare episodes where Hacker wins are those where he finds alignment between his political goals and Sir Humphrey's bureaucratic interests. When both parties benefit, cooperation emerges naturally and smoothly. No amount of authority alone can substitute for aligned incentives.

This is perhaps the deepest lesson, and it connects to a principle I have returned to throughout my career. You cannot mandate cultural change, force adoption of new tools, or decree that teams collaborate — unless the people involved see how it serves their own goals. Career growth, reduced toil, increased autonomy, more interesting work — these are the currencies. The most effective technical leaders I have known spend less time issuing directives and more time designing incentive structures: promotion criteria, team charters, OKR frameworks that make the desired behavior the path of least resistance. As Antony Jay wrote in Management & Machiavelli: the secret is not in commanding people to do what you want, but in making what you want become what they want. Machiavelli, I suspect, would have enjoyed Yes Minister.


If you haven't watched Yes Minister and Yes Prime Minister, I strongly recommend it. Both the complete DVD set and the book adaptation (The Complete Yes Minister) are available. And if, like me, you are a student of both Machiavelli and modern management, Antony Jay's Management & Machiavelli is the bridge text that connects the two traditions. I remain convinced that to understand the human impulses driving a modern corporation, studying medieval history is a better alternative than just the last 70 years of modern management. Yes Minister proves that studying 1980s British political satire works just as well.

No comments: