{ "archive_path": "archive/1765072719.409867", "base_url": "www.seangoedecke.com/seeing-like-a-software-company", "basename": "", "bookmarked_date": "2025-12-07 01:58", "canonical": { "archive_org_path": "https://web.archive.org/web/www.seangoedecke.com/seeing-like-a-software-company", "dom_path": "output.html", "favicon_path": "favicon.ico", "git_path": "git/", "google_favicon_path": "https://www.google.com/s2/favicons?domain=www.seangoedecke.com", "headers_path": "headers.json", "htmltotext_path": "htmltotext.txt", "index_path": "index.html", "media_path": "media/", "mercury_path": "mercury/content.html", "pdf_path": "output.pdf", "readability_path": "readability/content.html", "screenshot_path": "screenshot.png", "singlefile_path": "singlefile.html", "warc_path": "warc/", "wget_path": null }, "domain": "www.seangoedecke.com", "downloaded_at": "2025-12-07T01:58:44.283530+00:00", "downloaded_datestr": "2025-12-07 01:58", "extension": "", "hash": "1VZ2XKMDD73232TR14CC", "history": { "archive_org": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://web.archive.org/save/https://www.seangoedecke.com/seeing-like-a-software-company/" ], "cmd_version": "8.10.1", "end_ts": "2025-12-07T02:00:19.114093+00:00", "index_texts": null, "output": "TimeoutExpired: Command '['/usr/bin/curl', '--silent', '--location', '--compressed', '--proxy', 'socks5://tor-socks-proxy:9150', '--head', '--max-time', '60', '--user-agent', 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)', 'https://web.archive.org/save/https://www.seangoedecke.com/seeing-like-a-software-company/']' timed out after 60 seconds", "pwd": "/data/archive/1765072719.409867", "schema": "ArchiveResult", "start_ts": "2025-12-07T01:59:19.061627+00:00", "status": "failed" } ], "dom": [ { "cmd": [ "/usr/bin/chromium-browser", "--proxy-server=socks5://tor-socks-proxy:9150", "--disable-features=DarkMode", "--run-all-compositor-stages-before-draw", "--hide-scrollbars", "--autoplay-policy=no-user-gesture-required", "--no-first-run", "--use-fake-ui-for-media-stream", "--use-fake-device-for-media-stream", "--simulate-outdated-no-au='Tue, 31 Dec 2099 23:59:59 GMT'", "--headless=new", "--no-sandbox", "--no-zygote", "--disable-dev-shm-usage", "--disable-software-rasterizer", "--disable-sync", "--window-size=1440,2000", "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "--user-data-dir=/data/personas/Default/chrome_profile", "--profile-directory=Default", "--dump-dom", "https://www.seangoedecke.com/seeing-like-a-software-company/" ], "cmd_version": "131.0.6778", "end_ts": "2025-12-07T01:58:57.643691+00:00", "index_texts": null, "output": "output.html", "pwd": "/data/archive/1765072719.409867", "schema": "ArchiveResult", "start_ts": "2025-12-07T01:58:52.682970+00:00", "status": "succeeded" } ], "favicon": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--output", "favicon.ico", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://www.google.com/s2/favicons?domain=www.seangoedecke.com" ], "cmd_version": "8.10.1", "end_ts": "2025-12-07T01:58:47.576035+00:00", "index_texts": null, "output": "favicon.ico", "pwd": "/data/archive/1765072719.409867", "schema": "ArchiveResult", "start_ts": "2025-12-07T01:58:44.521600+00:00", "status": "succeeded" } ], "git": [], "headers": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://www.seangoedecke.com/seeing-like-a-software-company/" ], "cmd_version": "8.10.1", "end_ts": "2025-12-07T01:58:47.725248+00:00", "index_texts": null, "output": "headers.json", "pwd": "/data/archive/1765072719.409867", "schema": "ArchiveResult", "start_ts": "2025-12-07T01:58:47.625724+00:00", "status": "succeeded" } ], "htmltotext": [ { "cmd": [ "(internal) archivebox.extractors.htmltotext", "./{singlefile,dom}.html" ], "cmd_version": "0.8.5rc51", "end_ts": "2025-12-07T01:59:13.206861+00:00", "index_texts": [ "(/favicon-32x32.png?v=ac7bb3aa286bd21c42741d9c9aa60cb7) (/manifest.webmanifest) (/icons/icon-48x48.png?v=ac7bb3aa286bd21c42741d9c9aa60cb7) (/icons/icon-72x72.png?v=ac7bb3aa286bd21c42741d9c9aa60cb7) (/icons/icon-96x96.png?v=ac7bb3aa286bd21c42741d9c9aa60cb7) (/icons/icon-144x144.png?v=ac7bb3aa286bd21c42741d9c9aa60cb7) (/icons/icon-192x192.png?v=ac7bb3aa286bd21c42741d9c9aa60cb7) (/icons/icon-256x256.png?v=ac7bb3aa286bd21c42741d9c9aa60cb7) (/icons/icon-384x384.png?v=ac7bb3aa286bd21c42741d9c9aa60cb7) (/icons/icon-512x512.png?v=ac7bb3aa286bd21c42741d9c9aa60cb7) Seeing like a software company (seangoedecke.com RSS feed) (/rss.xml) (seangoedecke.com RSS feed) (/feed.xml) (seangoedecke.com RSS feed) (/atom.xml) (/webpack-runtime-8cd3fac48a78d94162cf.js) (/framework-a45383fedbea7a016e3a.js) (/styles-cebf9bedfc7d314ac4fb.js) (/app-7887dc182316466e498e.js) (/commons-728f22ee21186c37c088.js) (/component---src-templates-blog-post-js-f85cbc7039291d572ca7.js) (/page-data/seeing-like-a-software-company/page-data.json) (/page-data/sq/d/1146911855.json) (/page-data/sq/d/3000541721.json) (/page-data/app-data.json) (/) sean goedecke September 3, 2025\u2502(/tags/tech companies/) tech companies Seeing like a software company The big idea of James C. Scott\u2019s (https://files.libcom.org/files/Seeing%20Like%20a%20State%20-%20James%20C.%20Scott.pdf) Seeing Like A State can be expressed in three points: Modern organizations exert control by maximising \u201clegibility\u201d: by altering the system so that all parts of it can be measured, reported on, and so on. However, these organizations are dependent on a huge amount of \u201cillegible\u201d work: work that cannot be tracked or planned for, but is nonetheless essential. Increasing legibility thus often actually lowers efficiency - but the other benefits are high enough that organizations are typically willing to do so regardless. By \u201clegible\u201d, I mean work that is predictable, well-estimated, has a paper trail, and doesn\u2019t depend on any contingent factors (like the availability of specific people). Quarterly planning, OKRs, and Jira all exist to make work legible. Illegible work is everything else: asking for and giving favors, using tacit knowledge that isn\u2019t or can\u2019t be written down, fitting in unscheduled changes, and drawing on interpersonal relationships. As I\u2019ll argue, tech companies need to support both of these kinds of work. Thinking in terms of legibility and illegibility explains so many of the things that are confusing about large software companies. It explains why companies do many things that seem obviously counter-productive, why the (/breaking-rules) rules in practice are so often out of sync with the rules as written, and why companies are surprisingly willing to tolerate rule-breaking in some contexts. Seeing like a state James C. Scott was writing about the \u201chigh modernist\u201d movement in governance that produced (among other things) the (https://en.wikipedia.org/wiki/German_Forest) tidy German forests of the 19th century1 . In order to produce wood at scale, the German state demanded legibility : forests that an inspector could visit to tally up the amount of healthy trees. That means that you must be able to walk through the forest - i.e. the underbrush must be controlled - and the trees ought to be ideally laid out in neat rows of a single type. Proponents of legibility often describe their processes as \u201cefficiency measures\u201d or ways to \u201cavoid waste\u201d. But overall, the new \u201cefficient\u201d forests were in fact far less efficient than the old, illegible forests. They produced less wood per year and required more effort to fight disease, because the underbrush proved surprisingly load-bearing to the health of the soil, and the variety of species turned out to have been an asset. The new homogeneous forests could be wiped out by a single parasite or disease in a way that the older, more varied forests could not. However, the advantages of legibility are enormous. Once you know exactly how many trees you have, you can plan ahead, make large trade deals, avoid graft, and so on. To me, this is the most interesting point Scott makes. Large organizations did genuinely think that more legibility would necessarily increase efficiency2 . But even when it became clear that that was false, those organizations continued pushing for legibility anyway , because the other advantages were too powerful. Seeing like a software company It\u2019s the same way in software companies. It\u2019s almost a truism among software engineers that a single engineer can be more efficient alone than they can by working as part of a team. That\u2019s why there are so many anecdotes about engineers taking leave to finally get some work done, or about productive work being done on nights and weekends. Likewise, it should be obvious to any practicing engineer that engineer-driven work goes far more swiftly than work that is mandated from above. Engineer-driven work doesn\u2019t need to be translated into something that makes sense, doesn\u2019t need to be actively communicated in all directions, and can in general just be done in the most straightforward and efficient way. This is why tiny software companies are often much better than large software companies at delivering software: it doesn\u2019t matter that the large company is throwing ten times the number of engineers at the problem if the small company is twenty times more efficient3 . Why don\u2019t large companies react to this by doing away with all of their processes? (https://knowyourmeme.com/memes/is-he-stupid-is-she-smart-are-they-stupid) Are they stupid? No. The processes that slow engineers down are the same processes that make their work legible to the rest of the company. And that legibility (in dollar terms) is more valuable than being able to produce software more efficiently. Why legibility is valuable to tech companies What does legibility mean to a tech company, in practice? It means: The head of a department knows, to the engineer, all the projects the department is currently working on That head also knows (or can request) a comprehensive list of all the projects the department has shipped in the last quarter That head has the ability to plan work at least one quarter ahead (ideally longer) That head can, in an emergency, direct the entire resources of the department at immediate work Note that \u201cshipping high quality software\u201d or \u201cmaking customers happy\u201d or even \u201cmaking money\u201d is not on this list. Those are all things tech companies want to do, but they\u2019re not legibility . Our small-but-efficient software company meets only one of these criteria: the ability to pivot to some immediate problem that needs solving. The other information is all locked up in various engineers\u2019 heads, who may or may not remember what they did two months ago (and who certainly won\u2019t be willing to commit to work two months from now). That\u2019s not necessarily a problem, so long as everyone\u2019s on the same page about what needs doing and the product is continuing to improve. A typical large software company meets almost all of these criteria - I say almost, because in some companies or departments the ability to direct immediate work has atrophied (more on that later). But aside from that, large companies are usually very good at cataloguing what is being worked on, remembering what\u2019s been shipped in the past, and planning work in the medium-to-long-term. Why are these capabilities so valuable to a large software company, when small software companies can do without them? This is leaving my area of expertise somewhat, but I\u2019m pretty sure the main answer is large enterprise deals . Making deals with large enterprise customers is fantastically profitable. Any sufficiently large SaaS will thus pivot from small customers to enterprise customers, if it can4 . But enterprise deals (a) can take many, many months to set up, and (b) require making long-term feature commitments. An illegible company is not configured to be able to stick with a boring enterprise deal for many months, constantly answering questions and delivering features. Large enterprise customers simply won\u2019t trust a small software company to deliver the things they need over the next year or two. Customers like this typically value legibility very highly, and so demand that their vendors also be legible. In fact, highly legible organizations struggle to communicate at all with organizations that are less legible (and vice versa). They don\u2019t have access to the right bona fides, they don\u2019t talk the same language, and so on. This puts real pressure on growing tech companies to become more legible, even if it hurts their ability to deliver software. Legible assumptions In the pursuit of legibility, large tech companies make simplifying assumptions about the nature of tech work. For instance, they assume: 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. Projects can be estimated ahead of time, albeit with some margin for error. The more time spent estimating a project, the more accurate the estimate will become. Of course, all of these are false. Within the same job title, there is significant variance in engineering ability. Engineers have different skillsets and interests, and will work much more productively on projects that are a good fit for them. Because of this, the productivity of a team has a weak relationship to the number of engineers on the team. Project estimates are largely fantasy. More accurately, they\u2019re performative : the initial estimate determines the kind of engineering work that gets done to deliver by that estimate, not the other way around . For this reason, breaking down a project into parts and estimating each part often delivers a less accurate estimate, because it makes it harder for engineers to align with the overall ship date. However, these assumptions are true enough for their purpose, which is to provide legibility to the executives in charge of the company. Whether the project estimate is accurate or not, it can be used to plan and to communicate with other large organizations (who are themselves typically aware that these estimates ought not to be taken completely seriously). Temporary sanctioned zones of illegibility I mentioned above that large companies sometimes lose the ability to prioritize immediate work. This is because the processes that make work legible also impose a serious delay. Consider the steps that a hypothetical large company might take before beginning to write code on a problem: Somebody has a product idea. They take that idea to the Product org, where it goes into the \u201cplanning\u201d stage. Meetings are had about the idea. Once the Product org formally decide they want to do it, the idea then passes to the Engineering org: into the hands of some council of engineering architects, who are tasked with the initial technical review. They figure out how it fits into the general engineering priorities and give it a very rough time estimate. The VPs and senior managers in the engineering org then negotiate which team will own the work. Often this is a semi-technical, semi-organizational decision (because which service the work should fall into is at least partly a technical question). Finally the work lands on the team. It enters the team planning backlog, where the team technical lead breaks it out into smaller pieces of work. Those smaller pieces of work enter the team ticket backlog, and are estimated in the team\u2019s weekly planning meeting. Finally some of those pieces of work make it into the next sprint, and are picked up by an engineer who can actually do it. I\u2019m leaving out many crucial parts of this process: the updates on each ticket, which then roll up to higher levels of management, legal and design review, which can themselves take weeks, and then the final steps involved in shipping the change to customers. All of this makes the work very legible, but none of this is compatible with work that has to be done right now . What do you do when there\u2019s a sudden, urgent technical problem - maybe you\u2019re about to overflow your int ID column on the users table, or some very large customer is experiencing a show-stopping bug?5 To solve this kind of problem, tech companies often reserve the right to create temporary zones where illegible work is allowed. Sometimes these are called \u201cvirtual teams\u201d, or \u201cstrike teams\u201d (or even the colourful name \u201ctiger teams\u201d). They are composed of hand-picked engineers who are trusted by the organization. Often there is no manager assigned at all, but instead some very senior engineer who\u2019s tasked with running the project. These teams are given a loose mandate - like \u201cstop the database from falling over every few days\u201d - and allowed to do basically whatever it takes to get it done. This is a smart compromise between complete illegibility, which as I discussed above would make the company unable to make deals with its richest customers, and complete legibility, which would force even urgent company-killing issues to go through the entire laborious process of scoping, planning and estimating. Even when siloed to a temporary team, sanctioned illegibility still coexists awkwardly with the rest of the organization. Engineers outside the team don\u2019t like seeing other engineers given the freedom to work without the burden of process: either because they\u2019re jealous, or because they\u2019re believers in process and think that such work is unacceptably dangerous. Managers also don\u2019t like extending that level of trust. That\u2019s why sanctioned efforts like this are almost always temporary. The majority of the illegible work that occurs in large organizations is still unsanctioned . Permanent zones of unsanctioned illegibility If you\u2019re an engineer on team A, and you need team B to do some kind of work for you, the formal way to do this is to create an issue in their \u201cplanning\u201d backlog and wait for it to go through the entire twelve-step process before it finally makes its way into one of their sprints, where hopefully somebody will pick it up and do it. This can take weeks to months. When what you want is a one-line change, it\u2019s incredibly frustrating to watch your requested work item go through all these steps - each one of which takes many times longer than it would take to simply do the work. The official way around this problem is that team A should anticipate in their planning process that team B will need to do this work, so that piece for team B can enter their backlog at the same time as it enters team A\u2019s backlog. That way (in theory) they should be complete at around the same time6 . Any practicing software engineer knows how ridiculous this idea is. You can never anticipate every change that has to be made months before you start writing code. The actual way around this problem is illegible backchannels . An engineer on team A reaches out to an engineer on team B asking \u201chey, can you make this one-line change for me\u201d. That engineer on team B then does it immediately, maybe creating a ticket, maybe not. Then it\u2019s done! This works great, but it\u2019s illegible because the company can\u2019t expect it or plan for it - it relies on the interpersonal relationships between engineers on different teams, which are very difficult to quantify. If you\u2019re a well-liked engineer, your ability to pull on these backchannels is significantly greater than if you\u2019re brand-new or have a bad reputation. But how well-liked you are is not something companies can officially use when they\u2019re planning projects. Backchannels are a constant presence at all levels of the company. As well as engineer-engineer cross-team backchannels, there are backchannels inside teams, between managers, product managers, and so on. Often when a question is asked formally in a public space, it\u2019s already been rehearsed and workshopped privately with the person who\u2019s answering the question. None of this is or can be documented as part of the formal processes of the company, but it\u2019s load-bearing nonetheless. Many formal processes simply cannot function without the consensus mechanisms or safety valves offered by backchannels. Sometimes backchannels can go badly. Earlier this year I wrote (/predators) Protecting your time from predators in large tech companies about how some people use backchannels to benefit themselves at the expense of the naive engineers they\u2019re requesting work from. And it never feels good when you get the sense that everyone in a meeting has privately discussed the topic ahead of time except for you. For these reasons, some people think that backchannels themselves are a bad thing, and that all communication should go via formal, legible channels. Sociopaths, clueless, and losers There\u2019s another text which has been as influential to many as Seeing Like A State . This one isn\u2019t a book, but a blog post: (https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-the-office-according-to-the-office/) The Gervais Principle by Venkatesh Rao. Rao divides organizations into three groups. At the top are the \u201csociopaths\u201d, who cynically use organizational rules for their own benefit. In middle management are the \u201cclueless\u201d, who are bought into the formal rules of the organization and don\u2019t realise that there\u2019s a deeper game being played above their heads. Below them are the \u201closers\u201d, who realise there\u2019s a game being played but don\u2019t want to play it. The name \u201closers\u201d is not a value judgement - I think it\u2019s meant to affectionately pick out people like the leads in Clerks , who are too authentic to get involved in the corporate game. I don\u2019t agree with everything in The Gervais Principle , though I think it\u2019s worth a read (if you\u2019re interested in this stuff, you should also read the excellent (https://www.amazon.com.au/Moral-Mazes-World-Corporate-Managers/dp/0199729883) Moral Mazes ). But the categories here can be very naturally read in terms of legibility . Both sociopaths and losers are engaged with the illegible world of the organization. Sociopaths use this world to climb the ladder, while losers use it to carve out a cosy low-effort niche for themselves. The \u201cclueless\u201d are only engaged with legible processes. They\u2019re the people who, when they want to get promoted, go and look up the formal job ladder and make a plan for how they can exemplify each of the values at the next level. They\u2019re concerned with doing everything by the book. When they\u2019re forced into an encounter with the illegible world, their reaction is to shake their heads and start drafting updates to the legible process that can accommodate some pale approximation of the more-efficient illegible process. I think it\u2019s far too cynical to call these people clueless. Legible process is still very important - after all, it\u2019s the large part of what the organization does. Improving formal processes is still very high-leverage work, even if formal processes can\u2019t ever describe the entirety of how an organization operates. People who are invested in legibility have real value to any tech company. However, thinking about people in Rao\u2019s categories - people who exploit illegibility, people who find it distasteful, and people who use it casually - can be illuminating. Many frequent areas of conflict in software companies stem from the friction between these groups of people. Final thoughts I write a lot about recognizing and using illegibility in tech companies: Breaking the (formal, legible) rules is (/breaking-rules) sometimes the right thing to do Beware of savvy product managers (and others) exploiting illegible channels to (/predators) chisel work out of naive engineers Competent engineers should work on (/side-bets) \u201cside bets\u201d that are outside the normal planning process Getting promoted to Staff and above has (/staff-engineer-promotions) very little to do with the formal job ladder In general, advice about illegible processes is what I call (/dangerous-advice) \u201cdangerous advice\u201d . It\u2019s dangerous because if you make it legible - for instance, if you announce publicly that you\u2019re getting a piece of work done through backchannels instead of the formal process - you will be punished by the organization even if your management chain wanted you to do it . You can\u2019t speak too loudly about it. It has to stay illegible. I get a lot of negative feedback on these posts from people who say that you should never sidestep the formal process. According to them, if it needs changing, you should change the process instead of going around it. In other words, everything that goes on in a tech company should be legible , and illegible processes should be stamped out and converted to legible ones. I think this view is naive. All organizations - tech companies, social clubs, governments - have both a legible and an illegible side. The legible side is important, past a certain size. It lets the organization do things that would otherwise be impossible: long-term planning, coordination with other very large organizations, and so on. But the illegible side is just as important. It allows for high-efficiency work, offers a release valve for processes that don\u2019t fit the current circumstances, and fills the natural human desire for gossip and soft consensus. edit: this got some comments on (https://news.ycombinator.com/item?id=45505539) Hacker News . Some commenters agree with everything except the idea that large enterprise deals are the primary driver for legibility - they think it\u2019s (https://news.ycombinator.com/item?id=45511736) communication at scale , or (https://news.ycombinator.com/item?id=45511977) being able to target market share , or (https://news.ycombinator.com/item?id=45510656) internal control . There\u2019s also some good comments on (https://lobste.rs/s/6uemc8/seeing_like_software_company) lobste.rs . Commenters mostly agree, but some think that legibility-seeking process (https://lobste.rs/c/jwkqja) arrive organically instead of being a deliberate choice, or that legibility (https://lobste.rs/c/jxhazf) doesn\u2019t confer any real benefits to the organization (as opposed to a small set of leaders). Julik Tarkhanov also wrote a good (https://blog.julik.nl/2025/09/illegible-perception) response post arguing that most legibility \u201cimprovements\u201d are not actually increasing legibility, but are only creating the illusion of legibility (in order to make management feel good). I agree with this to a certain extent, but large organizations have the power to make illusions real (by promoting or firing on the basis of them, for instance). I think \u201creal\u201d legibility often starts like this: with the illusion of legibility, which is then made real by brute force. Consider a top-down mandate to use OKRs. At the start, people just make stuff up. But as decisions and promotions are made based on OKRs, people take them more seriously, and after a few years everyone is really trying to align with them (for better or for worse). This is the first example Scott gives, but I promise I did read the whole book. Other examples: the construction of (https://en.wikipedia.org/wiki/Bras%C3%ADlia) Bras\u00edlia , (https://en.wikipedia.org/wiki/Operation_Vijiji) Operation Vijiji in Tanzania, and the Soviet (https://en.wikipedia.org/wiki/Collectivization_in_the_Soviet_Union) attempt to replace individual peasant farms with state-run collectives. \u21a9 This is a very common false belief today among software engineers. \u21a9 I don\u2019t think small companies just work harder; plenty of people at large companies work very hard. I also don\u2019t think that small companies just have better engineers - what advantage they have in enthusiasm is often outweighed by the fact that they can\u2019t afford to pay as well. \u21a9 I was at Zendesk during the height of its pivot. \u21a9 Ironically, the most urgent types of problem typically can be solved via a normal \u201cincident\u201d process - but this itself is usually a zone where the rules are relaxed a bit in order to resolve the incident as quickly as possible. Anyway, here I\u2019m not talking about incidents but about projects that will take a couple of weeks to resolve. \u21a9 The other, healthier official way is to allow teams to make small changes to other teams\u2019 services themselves. But this only goes so far - the other team will always be the gatekeepers for changes like this, and are always in a position to slow down the change by days or weeks. \u21a9 If you liked this post, consider(https://buttondown.com/seangoedecke) subscribing to email updates about my new posts, or(https://news.ycombinator.com/submitlink?u=https://www.seangoedecke.com/seeing-like-a-software-company/&t=Seeing like a software company) sharing it on Hacker News .Here's a preview of a related post that shares tags with this one. Finding the low-hanging fruit Suppose your job is to pick fruit in a giant orchard. The orchard covers several hills and valleys, and is big enough that you\u2019d need a few weeks to walk all the way around the edge. What should you do first? Like a good engineer, you might reduce this to an optimization problem: in order to harvest the most fruit possible, you should maximise the quantity of fruit you get from each individual tree. Just by walking up to a tree, you estimate you can get about thirty percent of the fruit by standing on your tiptoes, but most of the fruit is higher than you can reach. You start by building a tall ladder so you can pick fruit from the highest branches, which ups your yield percentage to ninety percent. But some fruit is out wide as well as high up, on branches too flimsy to lean a ladder against. So you design a picker arm that lets you reach out sideways to pick more fruit. This ups your yield to ninety-five percent, but the arm isn\u2019t perfect - there\u2019s fruit that\u2019s awkward to reach, or that clings to the tree too tightly for the arm to pluck it off. You tweak your picker arm design, incrementally improving your yield. After a lot of work you triumphantly achieve ninety-eight percent.(/low-hanging-fruit/) Continue reading... (https://buttondown.com/seangoedecke) subscribe \u2502 (/about) about \u2502 (/podcasts) podcasts \u2502 (/projects) projects \u2502 (/popular) popular \u2502 (/rss.xml) rss \u2502 (https://autodeck.pro) autodeck Search seangoedecke.com () (Search posts) Search " ], "output": "htmltotext.txt", "pwd": "/data/archive/1765072719.409867", "schema": "ArchiveResult", "start_ts": "2025-12-07T01:59:13.182752+00:00", "status": "succeeded" } ], "media": [ { "cmd": [ "/usr/local/bin/yt-dlp", "--restrict-filenames", "--trim-filenames", "128", "--write-description", "--write-info-json", "--write-annotations", "--write-thumbnail", "--no-call-home", "--write-sub", "--write-auto-subs", "--convert-subs=srt", "--yes-playlist", "--continue", "--no-abort-on-error", "--ignore-errors", "--geo-bypass", "--add-metadata", "--format=(bv*+ba/b)[filesize<=750m][filesize_approx<=?750m]/(bv*+ba/b)", "--skip-download", "--cache-dir=/data/yt-dlp-cache/", "--cookies=/data/yt-dlp-cache/cookies.txt", "--proxy=socks5://tor-socks-proxy:9150", "--no-playlist", "https://www.seangoedecke.com/seeing-like-a-software-company/" ], "cmd_version": "2024.10.7", "end_ts": "2025-12-07T01:59:19.027306+00:00", "index_texts": [], "output": "media/", "pwd": "/data/archive/1765072719.409867", "schema": "ArchiveResult", "start_ts": "2025-12-07T01:59:14.946138+00:00", "status": "succeeded" } ], "mercury": [ { "cmd": [ "/home/archivebox/.npm/bin/postlight-parser", "https://www.seangoedecke.com/seeing-like-a-software-company/" ], "cmd_version": "2.2.3", "end_ts": "2025-12-07T01:59:13.125723+00:00", "index_texts": null, "output": "mercury/", "pwd": "/data/archive/1765072719.409867", "schema": "ArchiveResult", "start_ts": "2025-12-07T01:59:10.553787+00:00", "status": "succeeded" } ], "pdf": [], "readability": [ { "cmd": [ "/home/archivebox/.npm/bin/readability-extractor", "/tmp/tmpczv0qr86", "https://www.seangoedecke.com/seeing-like-a-software-company/" ], "cmd_version": "0.0.11", "end_ts": "2025-12-07T01:59:01.440602+00:00", "index_texts": [ "The big idea of James C. Scott\u2019s Seeing Like A State can be expressed in three points:\n\nModern organizations exert control by maximising \u201clegibility\u201d: by altering the system so that all parts of it can be measured, reported on, and so on.\nHowever, these organizations are dependent on a huge amount of \u201cillegible\u201d work: work that cannot be tracked or planned for, but is nonetheless essential.\nIncreasing legibility thus often actually lowers efficiency - but the other benefits are high enough that organizations are typically willing to do so regardless.\n\nBy \u201clegible\u201d, I mean work that is predictable, well-estimated, has a paper trail, and doesn\u2019t depend on any contingent factors (like the availability of specific people). Quarterly planning, OKRs, and Jira all exist to make work legible. Illegible work is everything else: asking for and giving favors, using tacit knowledge that isn\u2019t or can\u2019t be written down, fitting in unscheduled changes, and drawing on interpersonal relationships. As I\u2019ll argue, tech companies need to support both of these kinds of work.\nThinking in terms of legibility and illegibility explains so many of the things that are confusing about large software companies. It explains why companies do many things that seem obviously counter-productive, why the rules in practice are so often out of sync with the rules as written, and why companies are surprisingly willing to tolerate rule-breaking in some contexts.\nSeeing like a state\nJames C. Scott was writing about the \u201chigh modernist\u201d movement in governance that produced (among other things) the tidy German forests of the 19th century1. In order to produce wood at scale, the German state demanded legibility: forests that an inspector could visit to tally up the amount of healthy trees. That means that you must be able to walk through the forest - i.e. the underbrush must be controlled - and the trees ought to be ideally laid out in neat rows of a single type.\nProponents of legibility often describe their processes as \u201cefficiency measures\u201d or ways to \u201cavoid waste\u201d. But overall, the new \u201cefficient\u201d forests were in fact far less efficient than the old, illegible forests. They produced less wood per year and required more effort to fight disease, because the underbrush proved surprisingly load-bearing to the health of the soil, and the variety of species turned out to have been an asset. The new homogeneous forests could be wiped out by a single parasite or disease in a way that the older, more varied forests could not.\nHowever, the advantages of legibility are enormous. Once you know exactly how many trees you have, you can plan ahead, make large trade deals, avoid graft, and so on. To me, this is the most interesting point Scott makes. Large organizations did genuinely think that more legibility would necessarily increase efficiency2. But even when it became clear that that was false, those organizations continued pushing for legibility anyway, because the other advantages were too powerful.\nSeeing like a software company\nIt\u2019s the same way in software companies. It\u2019s almost a truism among software engineers that a single engineer can be more efficient alone than they can by working as part of a team. That\u2019s why there are so many anecdotes about engineers taking leave to finally get some work done, or about productive work being done on nights and weekends.\nLikewise, it should be obvious to any practicing engineer that engineer-driven work goes far more swiftly than work that is mandated from above. Engineer-driven work doesn\u2019t need to be translated into something that makes sense, doesn\u2019t need to be actively communicated in all directions, and can in general just be done in the most straightforward and efficient way.\nThis is why tiny software companies are often much better than large software companies at delivering software: it doesn\u2019t matter that the large company is throwing ten times the number of engineers at the problem if the small company is twenty times more efficient3.\nWhy don\u2019t large companies react to this by doing away with all of their processes? Are they stupid? No. The processes that slow engineers down are the same processes that make their work legible to the rest of the company. And that legibility (in dollar terms) is more valuable than being able to produce software more efficiently.\nWhy legibility is valuable to tech companies\nWhat does legibility mean to a tech company, in practice? It means:\n\nThe head of a department knows, to the engineer, all the projects the department is currently working on\nThat head also knows (or can request) a comprehensive list of all the projects the department has shipped in the last quarter\nThat head has the ability to plan work at least one quarter ahead (ideally longer)\nThat head can, in an emergency, direct the entire resources of the department at immediate work\n\nNote that \u201cshipping high quality software\u201d or \u201cmaking customers happy\u201d or even \u201cmaking money\u201d is not on this list. Those are all things tech companies want to do, but they\u2019re not legibility.\nOur small-but-efficient software company meets only one of these criteria: the ability to pivot to some immediate problem that needs solving. The other information is all locked up in various engineers\u2019 heads, who may or may not remember what they did two months ago (and who certainly won\u2019t be willing to commit to work two months from now). That\u2019s not necessarily a problem, so long as everyone\u2019s on the same page about what needs doing and the product is continuing to improve.\nA typical large software company meets almost all of these criteria - I say almost, because in some companies or departments the ability to direct immediate work has atrophied (more on that later). But aside from that, large companies are usually very good at cataloguing what is being worked on, remembering what\u2019s been shipped in the past, and planning work in the medium-to-long-term.\nWhy are these capabilities so valuable to a large software company, when small software companies can do without them? This is leaving my area of expertise somewhat, but I\u2019m pretty sure the main answer is large enterprise deals. Making deals with large enterprise customers is fantastically profitable. Any sufficiently large SaaS will thus pivot from small customers to enterprise customers, if it can4. But enterprise deals (a) can take many, many months to set up, and (b) require making long-term feature commitments. An illegible company is not configured to be able to stick with a boring enterprise deal for many months, constantly answering questions and delivering features. Large enterprise customers simply won\u2019t trust a small software company to deliver the things they need over the next year or two.\nCustomers like this typically value legibility very highly, and so demand that their vendors also be legible. In fact, highly legible organizations struggle to communicate at all with organizations that are less legible (and vice versa). They don\u2019t have access to the right bona fides, they don\u2019t talk the same language, and so on. This puts real pressure on growing tech companies to become more legible, even if it hurts their ability to deliver software.\nLegible assumptions\nIn the pursuit of legibility, large tech companies make simplifying assumptions about the nature of tech work. For instance, they assume:\n\nAny engineers with the same job title perform roughly the same.\nEngineers can be shuffled and reorganized without substantial loss of productivity.\nA team will maintain the same level of productivity over time, if it has the same number of engineers.\nProjects can be estimated ahead of time, albeit with some margin for error. The more time spent estimating a project, the more accurate the estimate will become.\n\nOf course, all of these are false. Within the same job title, there is significant variance in engineering ability. Engineers have different skillsets and interests, and will work much more productively on projects that are a good fit for them. Because of this, the productivity of a team has a weak relationship to the number of engineers on the team.\nProject estimates are largely fantasy. More accurately, they\u2019re performative: the initial estimate determines the kind of engineering work that gets done to deliver by that estimate, not the other way around. For this reason, breaking down a project into parts and estimating each part often delivers a less accurate estimate, because it makes it harder for engineers to align with the overall ship date.\nHowever, these assumptions are true enough for their purpose, which is to provide legibility to the executives in charge of the company. Whether the project estimate is accurate or not, it can be used to plan and to communicate with other large organizations (who are themselves typically aware that these estimates ought not to be taken completely seriously).\nTemporary sanctioned zones of illegibility\nI mentioned above that large companies sometimes lose the ability to prioritize immediate work. This is because the processes that make work legible also impose a serious delay. Consider the steps that a hypothetical large company might take before beginning to write code on a problem:\n\nSomebody has a product idea.\nThey take that idea to the Product org, where it goes into the \u201cplanning\u201d stage. Meetings are had about the idea.\nOnce the Product org formally decide they want to do it, the idea then passes to the Engineering org: into the hands of some council of engineering architects, who are tasked with the initial technical review. They figure out how it fits into the general engineering priorities and give it a very rough time estimate.\nThe VPs and senior managers in the engineering org then negotiate which team will own the work. Often this is a semi-technical, semi-organizational decision (because which service the work should fall into is at least partly a technical question).\nFinally the work lands on the team. It enters the team planning backlog, where the team technical lead breaks it out into smaller pieces of work.\nThose smaller pieces of work enter the team ticket backlog, and are estimated in the team\u2019s weekly planning meeting.\nFinally some of those pieces of work make it into the next sprint, and are picked up by an engineer who can actually do it.\n\nI\u2019m leaving out many crucial parts of this process: the updates on each ticket, which then roll up to higher levels of management, legal and design review, which can themselves take weeks, and then the final steps involved in shipping the change to customers. All of this makes the work very legible, but none of this is compatible with work that has to be done right now. What do you do when there\u2019s a sudden, urgent technical problem - maybe you\u2019re about to overflow your int ID column on the users table, or some very large customer is experiencing a show-stopping bug?5\nTo solve this kind of problem, tech companies often reserve the right to create temporary zones where illegible work is allowed. Sometimes these are called \u201cvirtual teams\u201d, or \u201cstrike teams\u201d (or even the colourful name \u201ctiger teams\u201d). They are composed of hand-picked engineers who are trusted by the organization. Often there is no manager assigned at all, but instead some very senior engineer who\u2019s tasked with running the project. These teams are given a loose mandate - like \u201cstop the database from falling over every few days\u201d - and allowed to do basically whatever it takes to get it done.\nThis is a smart compromise between complete illegibility, which as I discussed above would make the company unable to make deals with its richest customers, and complete legibility, which would force even urgent company-killing issues to go through the entire laborious process of scoping, planning and estimating. \nEven when siloed to a temporary team, sanctioned illegibility still coexists awkwardly with the rest of the organization. Engineers outside the team don\u2019t like seeing other engineers given the freedom to work without the burden of process: either because they\u2019re jealous, or because they\u2019re believers in process and think that such work is unacceptably dangerous. Managers also don\u2019t like extending that level of trust. That\u2019s why sanctioned efforts like this are almost always temporary. The majority of the illegible work that occurs in large organizations is still unsanctioned.\nPermanent zones of unsanctioned illegibility\nIf you\u2019re an engineer on team A, and you need team B to do some kind of work for you, the formal way to do this is to create an issue in their \u201cplanning\u201d backlog and wait for it to go through the entire twelve-step process before it finally makes its way into one of their sprints, where hopefully somebody will pick it up and do it. This can take weeks to months. When what you want is a one-line change, it\u2019s incredibly frustrating to watch your requested work item go through all these steps - each one of which takes many times longer than it would take to simply do the work.\nThe official way around this problem is that team A should anticipate in their planning process that team B will need to do this work, so that piece for team B can enter their backlog at the same time as it enters team A\u2019s backlog. That way (in theory) they should be complete at around the same time6. Any practicing software engineer knows how ridiculous this idea is. You can never anticipate every change that has to be made months before you start writing code.\nThe actual way around this problem is illegible backchannels. An engineer on team A reaches out to an engineer on team B asking \u201chey, can you make this one-line change for me\u201d. That engineer on team B then does it immediately, maybe creating a ticket, maybe not. Then it\u2019s done! This works great, but it\u2019s illegible because the company can\u2019t expect it or plan for it - it relies on the interpersonal relationships between engineers on different teams, which are very difficult to quantify. If you\u2019re a well-liked engineer, your ability to pull on these backchannels is significantly greater than if you\u2019re brand-new or have a bad reputation. But how well-liked you are is not something companies can officially use when they\u2019re planning projects.\nBackchannels are a constant presence at all levels of the company. As well as engineer-engineer cross-team backchannels, there are backchannels inside teams, between managers, product managers, and so on. Often when a question is asked formally in a public space, it\u2019s already been rehearsed and workshopped privately with the person who\u2019s answering the question. None of this is or can be documented as part of the formal processes of the company, but it\u2019s load-bearing nonetheless. Many formal processes simply cannot function without the consensus mechanisms or safety valves offered by backchannels.\nSometimes backchannels can go badly. Earlier this year I wrote Protecting your time from predators in large tech companies about how some people use backchannels to benefit themselves at the expense of the naive engineers they\u2019re requesting work from. And it never feels good when you get the sense that everyone in a meeting has privately discussed the topic ahead of time except for you. For these reasons, some people think that backchannels themselves are a bad thing, and that all communication should go via formal, legible channels.\nSociopaths, clueless, and losers\nThere\u2019s another text which has been as influential to many as Seeing Like A State. This one isn\u2019t a book, but a blog post: The Gervais Principle by Venkatesh Rao. Rao divides organizations into three groups. At the top are the \u201csociopaths\u201d, who cynically use organizational rules for their own benefit. In middle management are the \u201cclueless\u201d, who are bought into the formal rules of the organization and don\u2019t realise that there\u2019s a deeper game being played above their heads. Below them are the \u201closers\u201d, who realise there\u2019s a game being played but don\u2019t want to play it. The name \u201closers\u201d is not a value judgement - I think it\u2019s meant to affectionately pick out people like the leads in Clerks, who are too authentic to get involved in the corporate game.\nI don\u2019t agree with everything in The Gervais Principle, though I think it\u2019s worth a read (if you\u2019re interested in this stuff, you should also read the excellent Moral Mazes). But the categories here can be very naturally read in terms of legibility. Both sociopaths and losers are engaged with the illegible world of the organization. Sociopaths use this world to climb the ladder, while losers use it to carve out a cosy low-effort niche for themselves.\nThe \u201cclueless\u201d are only engaged with legible processes. They\u2019re the people who, when they want to get promoted, go and look up the formal job ladder and make a plan for how they can exemplify each of the values at the next level. They\u2019re concerned with doing everything by the book. When they\u2019re forced into an encounter with the illegible world, their reaction is to shake their heads and start drafting updates to the legible process that can accommodate some pale approximation of the more-efficient illegible process.\nI think it\u2019s far too cynical to call these people clueless. Legible process is still very important - after all, it\u2019s the large part of what the organization does. Improving formal processes is still very high-leverage work, even if formal processes can\u2019t ever describe the entirety of how an organization operates. People who are invested in legibility have real value to any tech company.\nHowever, thinking about people in Rao\u2019s categories - people who exploit illegibility, people who find it distasteful, and people who use it casually - can be illuminating. Many frequent areas of conflict in software companies stem from the friction between these groups of people.\nFinal thoughts\nI write a lot about recognizing and using illegibility in tech companies:\n\nBreaking the (formal, legible) rules is sometimes the right thing to do\nBeware of savvy product managers (and others) exploiting illegible channels to chisel work out of naive engineers\nCompetent engineers should work on \u201cside bets\u201d that are outside the normal planning process\nGetting promoted to Staff and above has very little to do with the formal job ladder\n\nIn general, advice about illegible processes is what I call \u201cdangerous advice\u201d. It\u2019s dangerous because if you make it legible - for instance, if you announce publicly that you\u2019re getting a piece of work done through backchannels instead of the formal process - you will be punished by the organization even if your management chain wanted you to do it. You can\u2019t speak too loudly about it. It has to stay illegible.\nI get a lot of negative feedback on these posts from people who say that you should never sidestep the formal process. According to them, if it needs changing, you should change the process instead of going around it. In other words, everything that goes on in a tech company should be legible, and illegible processes should be stamped out and converted to legible ones.\nI think this view is naive. All organizations - tech companies, social clubs, governments - have both a legible and an illegible side. The legible side is important, past a certain size. It lets the organization do things that would otherwise be impossible: long-term planning, coordination with other very large organizations, and so on. But the illegible side is just as important. It allows for high-efficiency work, offers a release valve for processes that don\u2019t fit the current circumstances, and fills the natural human desire for gossip and soft consensus. \nedit: this got some comments on Hacker News. Some commenters agree with everything except the idea that large enterprise deals are the primary driver for legibility - they think it\u2019s communication at scale, or being able to target market share, or internal control.\nThere\u2019s also some good comments on lobste.rs. Commenters mostly agree, but some think that legibility-seeking process arrive organically instead of being a deliberate choice, or that legibility doesn\u2019t confer any real benefits to the organization (as opposed to a small set of leaders).\nJulik Tarkhanov also wrote a good response post arguing that most legibility \u201cimprovements\u201d are not actually increasing legibility, but are only creating the illusion of legibility (in order to make management feel good). I agree with this to a certain extent, but large organizations have the power to make illusions real (by promoting or firing on the basis of them, for instance).\nI think \u201creal\u201d legibility often starts like this: with the illusion of legibility, which is then made real by brute force. Consider a top-down mandate to use OKRs. At the start, people just make stuff up. But as decisions and promotions are made based on OKRs, people take them more seriously, and after a few years everyone is really trying to align with them (for better or for worse).\nIf you liked this post, consider subscribing to email updates about my new posts, or sharing it on Hacker News. Here's a preview of a related post that shares tags with this one.Finding the low-hanging fruitSuppose your job is to pick fruit in a giant orchard. The orchard covers several hills and valleys, and is big enough that you\u2019d need a few weeks to walk all the way around the edge. What should you do first?Like a good engineer, you might reduce this to an optimization problem: in order to harvest the most fruit possible, you should maximise the quantity of fruit you get from each individual tree. Just by walking up to a tree, you estimate you can get about thirty percent of the fruit by standing on your tiptoes, but most of the fruit is higher than you can reach. You start by building a tall ladder so you can pick fruit from the highest branches, which ups your yield percentage to ninety percent. But some fruit is out wide as well as high up, on branches too flimsy to lean a ladder against. So you design a picker arm that lets you reach out sideways to pick more fruit. This ups your yield to ninety-five percent, but the arm isn\u2019t perfect - there\u2019s fruit that\u2019s awkward to reach, or that clings to the tree too tightly for the arm to pluck it off. You tweak your picker arm design, incrementally improving your yield. After a lot of work you triumphantly achieve ninety-eight percent.Continue reading..." ], "output": "readability/", "pwd": "/data/archive/1765072719.409867", "schema": "ArchiveResult", "start_ts": "2025-12-07T01:58:59.039643+00:00", "status": "succeeded" } ], "screenshot": [], "singlefile": [], "title": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://www.seangoedecke.com/seeing-like-a-software-company/" ], "cmd_version": "8.10.1", "end_ts": "2025-12-07T01:58:57.756499+00:00", "index_texts": null, "output": "Seeing like a software company", "pwd": "/data/archive/1765072719.409867", "schema": "ArchiveResult", "start_ts": "2025-12-07T01:58:57.731897+00:00", "status": "succeeded" } ], "wget": [] }, "icons": null, "is_archived": true, "is_static": false, "latest": { "archive_org": "TimeoutExpired: Command '['/usr/bin/curl', '--silent', '--location', '--compressed', '--proxy', 'socks5://tor-socks-proxy:9150', '--head', '--max-time', '60', '--user-agent', 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)', 'https://web.archive.org/save/https://www.seangoedecke.com/seeing-like-a-software-company/']' timed out after 60 seconds", "dom": "output.html", "favicon": "favicon.ico", "git": null, "media": "media/", "pdf": null, "screenshot": null, "singlefile": null, "title": "Seeing like a software company", "warc": null, "wget": null }, "link_dir": "/data/archive/1765072719.409867", "newest_archive_date": "2025-12-07T01:59:19.061627+00:00", "num_failures": 1, "num_outputs": 8, "oldest_archive_date": "2025-12-07T01:58:44.521600+00:00", "path": "/seeing-like-a-software-company/", "schema": "Link", "scheme": "https", "snapshot_abid": "snp_01KBV8GKKSD08341A6010YE8WQ", "snapshot_id": "d9e55bae-e23f-4a6a-9a01-d3b801e72397", "sources": [ "/data/sources/1765072718-import.txt" ], "tags": null, "tags_str": "", "timestamp": "1765072719.409867", "title": "Seeing like a software company", "url": "https://www.seangoedecke.com/seeing-like-a-software-company/" }