james c. scott's book "seeing like a state" has an argument that changed how i think about organizations. the argument is roughly: states need to make the things they govern legible — countable, categorizable, legible to the administrative gaze — and the act of imposing legibility destroys the local complexity that made the original system work. his canonical example is scientific forestry: the german states in the 18th century wanted to maximize timber yield, so they replaced the messy, ecologically complex natural forest with orderly monoculture plantations. the first generation of yield was excellent. then the forest started dying, because the monoculture had eliminated the ecological complexity — the undergrowth, the insects, the nitrogen cycling — that the trees depended on. the legible forest was less of a forest.
software engineering organizations have the same problem. past a certain size, the organization needs to answer "what is the engineering team doing" in a way that a VP can understand in a standup. so you get OKRs and sprint velocities and ticket throughput and story points. the dashboard goes green when tickets are closed. the dashboard goes red when an engineer spends a week reading code without merging a PR.
the week of reading code is often the most important week. consider: you've inherited a large legacy system. before you add a feature, you spend five days tracing execution paths, reading old comments, understanding why certain decisions were made, building a mental model of the thing. you write nothing. no tickets move. from the legibility system's perspective, you did nothing. what you actually did is acquire the understanding that will let you make every subsequent decision correctly, and without which you would have made bad decisions for months before understanding why.
legibility can't capture this. it can capture output — things produced, visible artifacts, closed tickets. it can't capture understanding — the stock of knowledge someone has built up about a system, which determines the quality of all their future decisions. the most valuable engineering work is often invisible to the measurement systems that evaluate it, and this creates exactly the incentive problem you'd expect: people optimize for what's measured. tickets get broken into smaller tickets not because that's better engineering but because more tickets means more throughput on the board. documentation gets written not because anyone will read it but because the act of writing is trackable. the deep reading gets skipped because it doesn't produce artifacts.
i've watched this play out at companies a few times. the engineers who quietly did the most important work — who spent the time understanding the system, who prevented the expensive architectural mistakes, whose fingerprints are on every decision that went right — got average performance reviews. the engineers who moved the most tickets and were loudest in standups got promoted. the legibility system was running a selection process, and it selected for the wrong things. eventually the people who were actually keeping the system running left, because they could see what was being valued, and the remaining engineers were confused about why things kept breaking.
the solution is not to eliminate measurement — organizations need coordination and managers need context. the solution is to be honest about what legibility costs, and then deliberately create spaces that are exempt from it. the best engineering managers i've seen do this instinctively. they tell the legibility machine what it wants to hear ("we made good progress on the Q3 priorities") while shielding their team from having to perform legibility at the expense of doing actual work. it's exhausting. it requires translating between two languages. but it's one of the most valuable things a manager can do, because it preserves the conditions under which good engineering is possible.
every measurement system changes the thing being measured. campbell's law: the more a metric is used for social decision-making, the more it distorts the behavior it was designed to measure. this isn't a flaw in measurement systems. it's a property of them. the question isn't whether to measure. it's whether you're honest about what you're losing when you do.