Office politics are not a character flaw. They are a structural inevitability of any environment where individual contribution is invisible. When no one knows who the good and bad contributors are, there are major incentives toward social manipulation. The entropic preference stack — easy over simple, complex over difficult, accountability over learning — is what this fog selects for. Eventually these manipulations consume more emotional energy than the actual work, and the quality of the latter declines.
Simple Picture
In a village, everyone knows who bakes the best bread. The baker’s reputation is visible, distributed, and earned through direct experience. In a corporation, nobody knows who writes the best code — because all the code is buried inside a monolith that only three people understand. So the question of who is good becomes a political question, answered not by output but by narrative.
Two Models of Development
Small-Program Development
Engineers write programs. Plural. Several. A person might contribute to twenty projects in a year, each producing generally useful tools. Cross-hierarchical collaboration is the lifeblood — people frequently help other teams, building relationships across the organization.
An engineer can be judged by whether they write high-quality software that is useful to other people. This knowledge is redundant throughout the organization because the engineer is continually producing visible value for a wide array of people. The political environment stays lightweight because a person’s clout is a product of visible contribution.
Small-program development follows the engineering algorithm naturally: small blocks can be questioned, deleted, simplified. Even when an initiative fails, useful tools are salvaged. The process of combining code from smaller blocks means useful pieces survive project failure. Large specialized blocks are at the mercy of the large project.
Big-Program Development
Engineers work on one Project. A capital-P project with a cool-sounding codename, a headcount, a timeline. Six months can be spent on-boarding into the complexities of a massive system. In light of average job tenures of two to three years, this is intolerable.
The Big Project tends to turn into a shitty, ad-hoc domain-specific language. Technical debt compounds here fastest: every feature added without reorganization buries whatever understanding existed, until the codebase contains no understanding at all. To understand any of it requires understanding all of it. The incumbent developers become dictators of their domain — nobody can claim better ideas because nobody else can comprehend the project. As Churchill might say: this codebase, by its very size, defends itself against the risk of being read.
Big Projects only deliver value at completion, not continuously. If half the team quits, if the project fails for any reason, everything is lost. This is the opposite of the flow principle — instead of limiting work-in-process and delivering continuously, the Big Project accumulates maximum work-in-process and delivers nothing until the end.
Why Managers Love Big Projects
Managers like Big Projects for three reasons, all of which serve managerial interests at the expense of engineering effectiveness:
1. Impressive names for impressive bosses. A manager can put “led Magneto, 100K lines of code, headcount of 12” on their resume. Nobody writes “enabled an ecosystem of 47 small tools that collectively improved developer velocity by 30%.”
2. Trackability. Mark is on Cinderella (headcount 3). Sally is on Visigoth (headcount 5). The org chart is legible. Legibility serves whoever is reading, and the reader is always management. In small-program development, people are spread across multiple efforts in ways that are impossible to meter — and unmeasurable work is, to the managerial mind, suspicious work.
3. Control. A manager cannot control the organic, as-needed growth of small-program development. Directing a Big Project is straightforward: make it object-oriented, use this toolset, complete 20 of 34 tickets by Friday. The Agile critique lands here too: Scrum’s user stories atomize work into manageable units not for engineering benefit but for managerial legibility.
But trackability kills extra-hierarchical collaboration — the thing that makes good companies good. Cross-hierarchical, unmetered work makes it hard to fire people, because a programmer contributing to multiple projects has too many advocates. peopleware names this directly: a company-wide meritocracy naturally tends toward democratic considerations, which weakens executive power. Managers prefer the Big Project model not despite its inefficiency but because of it — the inefficiency creates the dependency and legibility that management requires.
The Fog
Here is the payoff. If John is producing 5 lines of code per day on Lorax, is that because John is incompetent, because the team failed to onboard him, or because Lorax is a badly structured project?
In a small-program environment, this question answers itself — John’s visible contributions across multiple projects reveal his actual capability. In a Big Project environment, the question is unanswerable. The technical lead gets to make the assessment. Naturally, he will choose the theory that benefits him. He will never admit that Lorax is badly designed or was a mistake in the first place. So under the bus John goes.
It is this fog of war that creates office politics. The Gervais Principle describes what happens next: the Sociopaths navigate the fog by power talk, the Clueless navigate by loyalty to the Big Project abstraction, and the Losers navigate by watercooler solidarity. The Expert Beginner thrives in this environment because their domain expertise is unfalsifiable — nobody else understands the project well enough to challenge them. Goodhart’s Law completes the trap: whatever metric is chosen to evaluate contribution within the fog (lines of code, tickets closed, velocity) becomes a target that diverges from actual value.
The Language Analogy
Programming languages are just tools, but community cultures form around them. Java was designed for embedded systems like coffee pots and cable boxes. It was not designed with an ideological distrust of the programmer. That distrust came later, when the 1990s attempt to commoditize programming talent co-opted the language.
The attempt failed because programming at its core is thinking, and no method of force can force a person to think. Not forced frameworks, not forced test coverage percentages, not management tools. If a testing suite blocks all bugs from production, it will block all code if people do not personally care about quality. The Peopleware principle: a Methodology is an attempt to centralize thinking, and centralized thinking is an oxymoron.
Dimwit / Midwit / Better Take
The dimwit take is “office politics happen because of toxic people — hire better.”
The midwit take is “we need better processes to make contribution visible — implement OKRs, code metrics, peer reviews.”
The better take is that the fog of war is structural, not interpersonal, and the fix is architectural. Small-program development dissolves politics not by improving people but by making contribution visible through redundant, cross-team evidence. The fog that breeds politics is created by project architecture, not by human nature. Change the architecture — smaller projects, cross-team collaboration, continuous delivery of useful tools — and the political incentives change automatically. No amount of cultural intervention fixes a structural problem.
Main Payoff
The deepest insight is that managerial legibility and engineering meritocracy are in direct conflict. Big Projects make headcount trackable, project status reportable, and individual engineers controllable — all things management wants. Small-program development makes contribution visible, collaboration organic, and engineers autonomous — all things engineering needs. The company that optimizes for managerial legibility will produce office politics as inevitably as a factory produces waste. The company that optimizes for engineering visibility will produce meritocracy — and terrify its managers in the process.
References:
- Michael O. Church, Java Shop Politics