Office politics is what people do when nobody can tell who did the work.
John has been on a project called Lorax for a few months and is producing about five lines of code a day. Is he incompetent? Did the team fail to onboard him? Or is Lorax so badly structured that it would slow anyone down? From outside, the three explanations look the same. Someone still has to decide, and that someone is the technical lead. He is not going to conclude that Lorax, his project, is badly designed or was a mistake in the first place. So under the bus John goes.
Most people would file this under office politics and blame the lead for being political. Michael O. Church’s essay “Java Shop Politics” makes a more uncomfortable claim: the lead may be an ordinary person, and the politics came from the fact that nobody, including him, could see what John was actually contributing. When no one knows who the good and bad contributors are, there are major incentives toward social manipulation.
How a big project hides people
Lorax is what Church calls a Big Project: one capital-P effort with a codename, a headcount and a timeline. Onboarding can take six months, against average job tenures of two to three years. As features pile up without reorganization, the codebase tends to turn into a shitty, ad-hoc domain-specific language in which understanding any part requires understanding all of it. The incumbent developers become dictators of their domain, because nobody else understands the system well enough to propose a better idea. To adapt Churchill’s line about a long report: this codebase, by its very size, defends itself against the risk of being read.
That unreadability is what turns John’s slow output into a political question. When nobody can see the work, nobody can see whose work is good, so the verdict goes to whoever controls the story about it. It is this fog of war that creates office politics. Managing the story then becomes rational, until the manipulation consumes more emotional energy than the work and the work declines.
Compare small-program development, where engineers write many programs instead of one. A person might contribute to twenty projects in a year, each producing a tool that other teams use, and helping other teams is routine. In that shop John’s slow month on one project would settle nothing, because his capability would show up wherever people had used what he built. Knowledge of who is good becomes redundant throughout the organization, and a person’s clout follows visible contribution.
Why managers choose the fog
If small programs work better, why are Big Projects everywhere? Church’s answer is that they serve the people who approve them. A manager can put “led Magneto, 100K lines of code, headcount of 12” on a résumé, and nobody writes “enabled 47 small tools”. The org chart reads cleanly: Mark is on Cinderella, Sally is on Visigoth. And a Big Project is easy to direct, down to “complete 20 of 34 tickets by Friday”, while small-program work cannot be metered, and to the managerial mind unmeasurable work is suspicious work. The fog that hides John from his colleagues looks, from above, like a tidy and legible chart.
The tempting fix is to measure contribution inside the fog with lines of code, tickets closed or velocity. But any such number becomes a target, and as Goodhart’s Law predicts, it drifts away from actual value; John would learn to close easy tickets. That is why the fog of war is structural, not interpersonal, and the fix is architectural. Smaller projects, cross-team work and continuous delivery of useful tools change the incentives, because they let many people see contribution at once.
The argument has limits. Some systems are irreducibly large, and a flight-control system cannot be split into forty independent tools. The claim is about the default: whether a company chooses the Big Project because the problem demands it or because it fits neatly on an org chart.
In a small-program shop nobody needs to adjudicate John at all, because a dozen colleagues already know what he can do. So when a team’s politics turn ugly, the useful question is less who the bad actors are than whether anyone could have known who was doing good work. If the honest answer is no, replacing the lead only gives John a new person to be judged by.
References:
- Michael O. Church, Java Shop Politics