Legibility is Ruining You — Jimmy MillerApril 2026<br>Legibility is Ruining You

I am incredibly grateful that Sean Goedecke published his beautifully written article Seeing like a Software Company. In it, you will find a wonderfully balanced presentation of why companies often choose legible practices over more efficient, illegible ones. Sean very clearly details the kind of (in my words) doublethink that goes on at companies involving these very needed, but often hated, illegible processes. If you are hoping for that sort of balanced, nuanced take, please read his article instead. Sean has freed me from the burden of needing to write that way myself.

The Values You Truly Hold

Deep down on reflection, you don't care about OKRs, you don't care about code review, you don't care about coding standards, you don't care about lint rules, you don't care about style guides, you don't care about deadlines, you don't care about job titles, you don't care about standup, you don't care about code coverage, you don't care about any of these processes.

Your values are complicated. They require context and consideration. They aren't simple mechanical rules that can be captured by any metric, any process, or any methodology. You may believe these practices and tools we've adopted are pragmatically correct decisions to achieve your values. But they aren't the values themselves. And yet, they are the "values" that the "company" holds, or, more accurately, they are the values the company wants you to hold.

The Coercive Force of Legibility

Processes adopted by a company aren't about the end result of the work. Their stated goals and their actual goals are always distinct. An initiative related to applying coding standards isn't about making the quality of the code better. It is about changing the behavior of the engineers writing that code. By making code uniform, it reinforces some of the legibility myths (my word) Sean Goedecke says that companies rely on.

Any engineers with the same job title perform roughly the same.

Engineers can be shuffled and reorganized without substantial loss of productivity.

A team will maintain the same level of productivity over time if it has the same number of engineers.

- Sean Goedecke: Seeing like a Software Company

These are all false. Everyone knows they are false. It is easy to think of these as idealized assumptions, but they aren't. You can't find physicists out in a field trying to shove a cow in an orb to make their equations work out better, but software engineering directors are more than happy to do so to software engineers.

Legible assumptions are not merely assumptions. They are coupled with practices trying to make their assumptions reality. This is first by placing barriers (processes), but it goes much deeper than that. Barriers can be circumvented. Gatekeepers can be ignored. The modern software enterprise has realized that the only true way to make its legible assumptions true is to change the very nature of those creating the software. To transform them from an illegible force to a legible one.

Value Capture

Every software process does the same thing: it converts a rich, multifaceted value into a single metric. "Are our customers happy with our product and support?" is not the same question as "how high is our NPS"? "Is this team performing well?" is not the same as "What is this team's 'velocity'?". "Are we working on the right stuff?" is not the same thing as "Do we have a prioritized backlog?". Yet we constantly mistake these questions for each other. Not only that, we don't even realize that these are conflations. Why? Because we are rewarded for fixing the latter and not the former.

The excuse always given for this disconnect is that the former questions don't work at "scale". But what precisely does that mean? If you have too many people, each divided into small groups (teams), they can't each ask these questions? No, these rich questions are actually quite easy to parallelize. What they don't do well is compose and reduce so that those at the top can understand them. Don't confuse something not working at "scale" with something that doesn't make an executive feel warm and fuzzy.

But the real reason for this conflation is not simply that it makes executives feel good, but that these metrics are an incredibly powerful means of changing behavior and values. In other words, they are a way of making the world fit the assumptions those at the top have already made.

Value capture occurs when an agent's values are rich and subtle; they enter a social<br>environment that presents simplified — typically quantified — versions of those values; and those simplified articulations come to dominate their practical reasoning.

- Value Capture by C. Thi Nguyen

By making these metrics, the company can change how we behave. They can make our behavior properly legible.

Thin Rules, Thin Behavior

The sad fact is, as an industry, we long ago stopped only letting executives...