from Hacker News

Seeing like a software company

by praptak on 10/7/25, 4:49 PM with 122 comments

by zug_zug on 10/8/25, 1:17 PM
Mostly a great piece. The only thing I need to challenge is the default assumption that leadership is automatically correct that "legibility" is worth all the overhead. Imagine if you brain had to be consciously aware of every breath you take, every time you move a finger, etc... you'd get nothing done. Same deal if a CEO has to be aware of and approve accelerating your unit tests with parallelism or whatever.
I think the reality is that a CEO (sort of like a president) only has about 7% control over a company. The rest of it is everybody they've hired -- they are just the brain not whole the body. However they like to believe that they are the most important thing, and quickly disregard everything they don't have the time or specialty to understand (i.e. seeing engineers as interchangeable when one may be a genius who got into MIT and could be advancing whatever field he works in -- while the other is just some random bro who took a bootcamp).
When people talk about something like google succeeding it's easier to give credit to 2 founders or a CEO than it is to track the dozens of brilliant employees who built the best search/mail/maps/ads/etc platforms
by hshdhdhehd on 10/8/25, 8:50 AM
There is truth in what is said here but I dont think it is that extreme. I work at a circa 5k engineers company. So not small but not Amazon.
However I find most rules have a decent enough reason. Let's say you need 2 cose reviewers. This is to avoid mistakes going into prod. Not many reviews are rejected but if you had no code to reviews to prod I bet there would be more outages and cowboy code slings.
So it acts as a forcing function. Now I dont need to break that rule because lots of other things are not degenerate. But maybe I do one day. Maybe 90% of my team get pulled away to some high severity incident and so we left in the team cant get the reviews. Maybe we need to break the rule for a day to get a critical fix out. I think yhat would be OK because balancing the reason for the rule with the reason for the fix and the reason we cant follow the rule.
If there are rules you cant understand and feel like pure bureaucracy then I leave. Worked places like that where someone has a pet process and they'll shout "you holding it wrong". For most it is SCRUM but there are other ones. The people running things care more about process and ego than actual progress. Then leave.
by piker on 10/8/25, 8:32 AM
The temptation since the TDD movement has been that if you can't test it, it isn't "written". I think "legibility" is a great word to describe that desire.
I have hundreds of unit tests for Tritium, but it wasn't until I started writing a blog using it[1] that I started finding qualitative bugs that weren't picked up (and would be really hard to pick up) with unit tests. They were illegible.
I think this is why indy game dev is resilient to market economics where other software verticals become winner-take-all. Game devs are able to make their products qualitatively better because they dogfood so well. They also, as alluded to in the article, have a smaller "enterprise" surface area which requires so much legibility.
Truth is, you need both qualitative and quantitative measures.
[1] https://tritium.legal/blog/eat
by boberoni on 10/8/25, 12:15 AM
The more I work in corporate and learn about office politics, the more I see parallels to geopolitics and diplomacy. If I squint, I can even see the parallels to social and romantic relationships as well.
Maybe it's the mathematician in me who enjoys building models of abstraction.
by monkeydust on 10/8/25, 6:26 AM
Nice post from Sean (again). This applies a lot to product domain as well as engineering.
Example, around a year a bunch of product people and like-minded engineers wanted to develop something that we believed could benefit other teams as well as ours. To fund officially (legible channel) would have been a nightmare for many reasons at the time so it was agreed that we would just do it (what OP would call illeigible channel) this required massive degree of trust and respect which this group had.
It felt like a pure grassroots initiate and not driven by top down, as such this helped the development get traction across the org, surprisingly quick in some cases.
Fast forward to today and senior management now citing this as a success story that fits into the narrative they are presenting...great..but...of course...no good deed goes unpunished!
The team is now having to retrofit the business case and justification through the legible channels, it's painful of course but in same easier as the chance of failure has been massively derisked.
One of the much more fun, satisfying and rewarding projects I have worked on in recent years.
by ArcHound on 10/8/25, 4:15 AM
I work in IT sec, where this is even more pronounced. Specifically, does anyone please know about any effective alternative to back channels when tackling "we need your team to do this thing which doesn't help your metrics"?
Pretty please?
by levity on 10/8/25, 12:13 AM
> 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’m pretty sure the main answer is large enterprise deals.
Anyone willing to comment for whom this is their area of expertise?
by ChrisMarshallNY on 10/8/25, 12:34 AM
This has always been a balancing act.
I was an engineering manager for 25 years, and had to deal with the balance. I worked for a heavily process-driven company. It could be infuriating, but they did manage to consistently produce some of the finest hardware in the world (unfortunately, the same could not be said for the software).
I have found that writing things down, can ossify a project, but you really can't do without. Communication overhead is the single biggest killer. That's why a small team of experienced engineers, that are used to working together, can often do amazing amounts of work, and that "tribal knowledge" -that bugaboo of software process gurus- is actually a very important accelerator.
I wrote a post called "Concrete Galoshes"[0], that talks about the things that add structure and inflexibility to projects.
The single biggest lesson, is that we should be very careful about "One Size Fits All" solutions. Different types of projects need different types of overhead and structure.
[0] https://littlegreenviper.com/various/concrete-galoshes/
by athrowaway3z on 10/8/25, 6:44 AM
Good article, but I do think there is one aspect of the story that we don't talk about enough.
It sticks to the world view that SWE are the leafs in the graph. The assembly workers at the assembly line. Though, the author knows this isn't true, as noted in the "Legible assumptions" section.
Software engineerings are managers extending the organizational graph. With code. There are some peculiarities to it, but they are managers. A lot of problems in one domain have an analogous in the other.
by douglasnaphas on 10/8/25, 8:31 PM
> 4. The VPs and senior managers in the engineering org then negotiate which team will own the work.
> These [tiger] teams are given a loose mandate - like “stop the database from falling over every few days” - and allowed to do basically whatever it takes to get it done.
> The actual way around this problem is *illegible backchannels*.
The post seems to be based on organizations where teams aren't organized, and responsibilities aren't assigned to teams, in such a way as to allow teams to independently deliver value with minimal handoffs.
If you need to pull engineers from multiple teams to fix a problem with the database that the teams all share, that suggests that the teams' applications aren't restricted to communicating with each other over their external interfaces.
If determining which team should work on a project requires negotiating among VPs and senior managers, that suggests that the teams' responsibilities aren't clean, clear, and tied to the business's value streams.
I think a more fundamental way to address the problem of team A being blocked by team B is to organize the teams so as to minimize cross-team dependencies. I don't think the solution of illegible backchannels addresses the root cause of the problems observed by the author.
by indigoabstract on 10/8/25, 12:07 PM
Interesting topic. And legibility is also an interesting word choice for this. I've always thought of the thing he describes as a dichotomy between the formal/official way of doing things (like you would communicate and work with strangers) and the informal way of doing things (like you would with a friend or with yourself). While smaller companies seem to benefit from using the informal process, once it gets past a certain threshold, that no longer seems to work as well, so things get more and more regulated to cope with the scale.
The thing I've noticed is that formal rules and processes, while necessary, over the long term tend to lead to rigidity/petrification and to losing the creative spark and the ability to adapt to changes. People get so used to them that the process becomes more important than the end goal. It seems really hard to keep things fresh, alive and prevent them from falling into routine, it's like fighting entropy.
I guess money is in a way like the blood of a company but I doubt that most people are truly inspired or motivated by it, hence making money is necessary, but not a good reason in itself for a company to exist.
by 0wis on 10/8/25, 2:26 AM
Seems quite true even in a non-software large company. The work about work is often more important, and certainly is for promotion related progress.
by diodoe on 10/8/25, 9:40 AM
I recognized a pattern I’ve often seen in large tech orgs: the way formal processes, while frustratingly inefficient day to day, are what actually make scale and big enterprise deals possible. Framing it through Scott’s legible/illegible lens helped me make sense of why that overhead never really goes away.
by smugglerFlynn on 10/8/25, 12:14 PM
This is an interesting thought model to consider, but whole article is very biased and opinionated. It reads like a "small companies do it better" manifesto without giving any real insights into operations of large companies.
For example, all of the goals quoted below are parametrized and tracked by most of large & mature companies, oftentimes daily, through NPS, cost/profit analysis, and many other "legit but inefficient" tools:
```
  > Note that “shipping high quality software” or “making customers happy” or even “making money” is not on this list. Those are all things tech companies want to do, but they’re not legibility.
```
There is a premise that closing a blind eye on these makes companies "less efficient", but evidently there are large companies that do track achievement of such goals, and there are small companies that don't.
There is also insider information appealing as evidence ("Any practicing engineer knows how ridiculous this is.”), mocking ("Are they stupid? No.”) and survivorship bias (treating most small companies as "more efficient” by default) among multiple other rhetorical tricks and anecdotes. It captures the frustration engineers feel in large orgs, but then inflates that into a universal theory of how all companies operate.
by piltdownman on 10/8/25, 1:32 PM
A fantastic follow-up building on the Gervais Principle Essay with pragmatic actionable advice for any Engineer that I wish I had internalised at the start of my career. His three points as a tl;dr takeaway are sticky-note worthy:
1. Beware of savvy product managers (and others) exploiting illegible channels to chisel work out of naive engineers
2. Competent engineers should work on “side bets” that are outside the normal planning process
3. Getting promoted to Staff and above has very little to do with the formal job ladder
by paulsutter on 10/8/25, 3:17 PM
Superb article and insight. Once you see legibility, it explains so many seeming (and actual) dysfunctions.
Coordination at scale is the reason, not just enterprise deals (although enterprise deals are a sub case of coordination).
Alignment is the single biggest challenge in management, at any size.
by stroebs on 10/8/25, 5:44 AM
> sanctioned efforts like this are almost always temporary. The majority of the illegible work that occurs in large organizations is still unsanctioned.
The title “DevOps Engineer” often fits a permanent role of sanctioned illegibility in large organisations. One cannot explain exactly what a “DevOps Engineer” does, because (a) you cannot _engineer_ a culture, and (b) largely these engineers do urgent and important work that cannot be planned, estimated, put into sprints, etc.
I’ve had this title through several of my roles at orgs over the years and I detest it, but nonetheless understand why it exists.
by lordleft on 10/8/25, 1:22 PM
Fantastic article. I've never heard of the book it references at the beginning, but seems quite profound. The concept of legibility explains a great deal.
by koeng on 10/8/25, 12:32 AM
> 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’m pretty sure the main answer is large enterprise deals
I think the more boring answer may be that in any sufficiently large organization, the only way to maintain control is through legible processes, because the sociopaths do utilize the legible processes to keep things running (and utilize the illegible processes to make deals). Without legible processes, after dunbar's number, your communication falls apart.
by thadk on 10/8/25, 3:46 AM
It seems to me the next opportunity for Sean is to integrate this logic with The Goal (1985) extended universe of works.
by rester324 on 10/8/25, 6:28 AM
I read this blogpost and I simply see it as a shoplist of pathologies. And even bad at that, because it's only focusing on how these pathologies impact the company bottomline and it doesn't even touch on how destructive this late stage pathological capitalist company management detrimental to society. Financially, mentally but also phsyically. And it also doesn't mention that these pathologies only serve one reason, so that the members of the class who are holding power and capital can extort control and exploit the working class. So yes, people can see the company this way, but if people ignore these problems I listed, they are part of the problem of why capitalism fails for so many and it only benefits so few.
by billbrown on 10/9/25, 7:18 AM
I've heard it said that "work is not done until it's reported done."
by sfpotter on 10/8/25, 3:12 PM
For these and many other reasons: small company > large company.
by johndhi on 10/8/25, 12:01 PM
I run a team of about fifteen people and for whatever reason I've never really understood or driven toward legibility. What's the point? For me getting to know and trust each person and to develop an understanding of what they are good at is the key thing I focus on. Good work follows.
Actually knowing minutiae of what they do seems like make work to me.
by for_i_in_range on 10/8/25, 11:40 AM
Next post should be How to Create TPS Reports
by scrubs on 10/8/25, 5:50 AM
Loved this article. Thanks!
by donatj on 10/8/25, 11:31 AM
I worked for a small very well oiled company, not really a "startup" but similar energy. We got gobbled up by a big company a number of years ago. The culture shock has been wild.
We've largely managed to, in the face of corporates wishes, maintain our speed and agility. With recent rounds of layoffs, we'll see if we can keep that up I guess.
I have come out of this experience genuinely wondering how large companies manage to stay in business. I frankly think it's down to resting on laurels.
For instance, if another department needs something fixed in an API we manage, assuming the work is simple, we can usually have it fixed and live within the day. We have had issues with APIs from other teams where an API we depend on has been offline for literal months because "there is no time on the roadmap" and it took six months for, from my understanding, a service to get restarted. This happens all the time.
Every single piece of work needs to be "planned". It needs to be fit into this imaginary schedule. God forbid you turn on the lights without a plan. The number of "planning meetings", sometimes multiple days long, that should have been an async slack thread is absolutely insane.
Almost always we could have everything being "planned" done inside the time of these meetings.
> Increasing legibility thus often actually lowers efficiency - but the other benefits are high enough that organizations are typically willing to do so regardless.
I dispute the second half of this entirely. Planning the unknown has so few real actual benefits in building software as to be nil. Perceived benefits, sure. Actual? Nil. The road before you literally unfolds as you build and sticking strictly to a map drawn by the blind is literally insane.
We give this imaginary "map" of what is supposed to be happening to managers and investors. Does this result in better software? God no. The results take far longer and are far worse in quality because we stuck to a map drawn by someone without impossible knowledge of the full scope of the problem because the only way to get that knowledge is to actually work through it, and if you do that you have the product. It's literally The Halting Problem. You cannot know the scope of a problem without doing the problem.
All it does is provide management and investors warm fuzzies that they think they know what's going on when they don't.
I was drawn to tech as a young man for its logic, reason and provability. As an older man, I find it so full of cults. Cults of process, cults of personality, cargo cults. It's all the junk I wanted to get away from.
by FrankWilhoit on 10/7/25, 5:00 PM
[flagged]