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
> 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.
This is a strawman. No competent CEO thinks they need to be on top of your unit testing practices. The levels of legibility that companies actually aim for are much more defensible.
> The levels of legibility that companies actually aim for are much more defensible
Many companies run in such a way that there is no bucket for "engineers get to do stuff they know is important x% of the time." So what happens is that things that executives don't understand the significance of all get 0 time allocation. Other teams may be told they aren't allowed to work on something owned by the CI team (again often for legibility reasons).
This is how I work at a "startup" that has just a single test environment that everyone has to share after 10 years of existence.
I worked at a small startup-ish company like this: No bug tracking, no source control, no dedicated build machines (builds were published off of a random engineer's laptop, based on whatever code he had on it currently), no tests, no documentation. None of these were seen as important by the CEO (he was not a software guy). He just wanted engineers cramming features all day. When you started talking to him about development process, toolchains, infrastructure, best practices, his eyes would glaze over and ask how this helps him deal with his 5 screaming customers right now.
The CEO definitely felt he needed to be involved with these practices, to forbid them.
It is not. I once had the misfortune of glancing at the metrics that went into an "executive dashboard" for the CEO/CTO at a startup, and started paying close attention to what they talked about during the weekly all-hands. Other more recent, and widely experienced examples of micro-management by CEOs are forced RTOs and diktats forcing employees to "leverage AI" in some form or fashion, with little care about how this impacts individual teams.
> No competent CEO thinks they need to be on top of your unit testing practices.
You seem to be acknowledging that such CEOs exist, but you built an escape hatch by labeling them as not competent. Your second sentence appears to follow the first, but it doesn't, and is a an unfalsifiable tautology.
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.
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.
Test in general (unit tests paticularly strongly) are prone to the streetlight effect. The more trivial or unimportant something is, the easier it is to test it. This creates the temptation to test the easy part rather than what's important. And this can be made even worse if the organization pushes for "legibility" via the easy "legible" metrics (e.g line coverage) rather than hard "illegible" metrics (i.e. a review of the tests by an experienced engineer).
> The streetlight effect, or the drunkard's search principle, is a type of observational bias that occurs when people only search for something where it is easiest to look.
Game dev in general has a much tighter feedback loop than most software. If you're leaking memory, you're doing that a hundred times a second. If your code is slow you get visual stuttering. If you want performant code you need to think about things like cache coherence, you can't use GC etc.
GC is ok as long as you aren't writing some factorio-like etc. Modern computers are perfectly fine doing shit ton of useless stuff 120 times a second without blinking an eye.
I agree with you for almost all of this, just a small nitpick:
GC isn't really incompatible with games, for the overwhelming majority of games, it's basically a non-factor in performance if you spend even the slightest amount of time on performance.
It's kind of similar to native code - don't allocate too much, reuse resources, don't leak them uncontrollably.
It's only a problem when you need guarantees (i.e. the game should never drop a frame) but basically no game fulfills that nowadays and it isn't a player expectation.
I agree, but that's really true for questions like "does it run fast"? And those kind of arguably fit into the "legible" camp. Whereas "is it fun?" is a question less able to be formally tested and articulated. It's "illegible".
The tighter feedback loop that helps to answer that question comes from dogfooding.
I think this is true. I am a big fan of TDD but it remains important to also do a manual test. Often things just don't work out exactly as one would think. This is especially true with things that relate to user friendliness but also with other things.
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.
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.
One of my favorite subjects is politics. I enjoy reading books about politics, and keeping up on (geo-)politics, subscribe to political magazines and honestly don’t mind navigating office politics.
Because at the heart of it it’s all the same. It’s humans acting like humans. Every person (and organization) has desires and fears. When two parties get together, balancing everyone’s wants is fun. It’s like a complicated engineering problem, except with people requirements instead, and politics is the architecture.
I think people are rad and genuinely enjoy these kinds of problems.
The conflict maps I was exposed to were much simpler - just a bunch of wobbly circles surrounding a centra issue or event. Wobbly circle intersections denoted needs/fears incompatibility implying potential conflict.
My own experience is that it's hard to do predictable engineering in more social environments because requirements can change from one hour to another and there's no reprocurssiom, you just have accept it and move on.
Although this also happens in office environments, there's more accountability and continuous planning, making requirements changes something that is undesirable.
I only recently realized this. I was seeing geopolitics as an intricate, emergent behavior of complex systems made of hundreds of diplomats. I realized it was merely interpersonal relationships between a few country leaders who happen to have power over their respective states, military etc. This is not as different as kindergarten playground drama and squabbles, to some approximation of course.
I think that's the wrong lesson to take. The realist approach to international relations where states are controlled from the top as you describe is more legible. Instead I agree that it's really based on interpersonal relationships, but that those relationships are between CEOs, diplomats, immigrant communities, military officers, and of course also country leaders. This illegible network is what guides actually guides policy.
Is it not natural for that? I think less so between social and romantic but larger businesses and governments have definitely share many of the same problems. Though I think businesses tend to be much more autocratic. Maybe feudal is a better term?
There's definitely a lot of differences but I think the larger a business becomes the more government like it becomes. Or at least it appears that way to me. I mean they're both very bureaucratic
Govts are typically "large enterprise". In most cases the largest enterprise in a country.
In some countries they also have the burden of being legible to outsiders. Between the shareholders (voters) and journalists etc there's a lot of process that has to be transparent.
This transparency is legibility driven to extremes. If an enterprise kills a project (think Windows Phone) its done, and we move on. If a govt kills a project there's a lot of external attention on what went wrong, who's getting fired (or going to jail) and how "our money got wasted".
So yes, as things get bigger they matter to more people. The more people involved the more every single thought and action has to be meticulously detailed.
Which is party why (democratic) govt is soooo bad at actually getting anything done. Feudal govts, and autocratic businesses, get a lot done - much of it quickly. It might not be good. It might be motivated my enrichment not care, but it gets done fast.
A good autocrat moves the needle, and things get a lot better very quickly. A bad autocrat achieves his goals, often at enormous cost to the organization (which may not survive. )
> Which is party why (democratic) govt is soooo bad at actually getting anything done.
I find this and similar claims quite astounding. The last few hundred years seems to have been some of the most productive times for humanity. The great technological leaps forward. In that time we went from an agricultural society where many were malnourished, illiterate, and life expectancy was far lower (not only was the child mortality rate magnitudes higher but expectancy past 60 years old was abysmal) to a society that put a god damn man on the moon and maybe more importantly a toilet in every home.
All that happened under democracy.
So I call BS to claims that democracy means the government is so bad at getting things done. Perhaps you're pointing the finger at the wrong variable.
> A good autocrat moves the needle, and things get a lot better very quickly. A bad autocrat achieves his goals
It's true, a benevolent dictator can do a lot of good. It's also true that we don't have the proof for the counterfactual of what I discussed above.
But if these autocrats were as good as you suggest then it begs the question of why the Industrial Revolution and many of the great leaps forward didn't happen under them? Or why during the rise of democracy in the west did the remaining monarchies and autocrats not also flourish? Post WW2 why did the top down economies of the USSR and China also not see such success? (China didn't succeed until much later, when it opened up) Those countries across that same time that democracies made such advancements did not win out.
You can say that maybe those leaders weren't the best, but we're talking about many generations here. So then what? Benevolent autocrats are rare? That seems like a great flaw.
You also forget the old cliché: the road to hell is paved with good intentions. History has shown that there were many kings and rulers who sought to do good and do good by the people, yet in these efforts caused great disaster. You could take the Four Pest Campaign as a relatively recent example. It was definitely implemented with good intentions but ended up being one of, if not the, greatest environmental disasters of all time. Estimates are that between 1% and 10% of the population at the time starved.
This is not to say that democracies have not also caused great harm. One needs not believe there is a global optimal solution to such a complex problem, but that does not mean certain solutions aren't strictly better than others. A benefit to democracies is that it is difficult to bury the mistakes. They say history is told by the victors but that's not entirely true. History is written by those who write and the writings that can be preserved. In democracies this is available to far more people. It is unlikely that you have an accurate understanding of the daily lives of those who lived more than a few hundred years ago. No one was recording that.
On paper I think the idea of a benevolent autocrat sounds good. But in reality there are so few examples of benevolent autocrats who made their citizens lives better. Sure, many built great monuments but that's not the same thing. It is simply difficult to role effectively over so large of an ecosystem. The world is too complex for one man to make informed decisions. I'm sure if you are honest with yourself you'll find that even far smaller tasks, ones you may be apart of, share this feature. When a single mind cannot handle all the complexities, you must turn to a collective. But a feudal society is not a dictatorship, even if it appears so locally
> The great technological leaps forward ... All that happened under democracy.
I think you're conflating "governments were democratic at a time these things happened" with "the government did these things directly itself via its institutions".
Of those achievements, only the space race was actually executed by the government, and it's not a great counter-example because it was done purely to compete with the achievements of an autocratic government (the USSR).
The rest was private sector efforts. It wasn't a government institution that built toilets.
> it begs the question of why the Industrial Revolution and many of the great leaps forward didn't happen under them?
They did. USSR famously went through forced industrialization.
In addition to what the other's comments have said, I think you're missing two things here:
(1) The comment you're replying to didn't say autocrats were "good", they said they were "fast".
(2) Authoritarian failures are also present in capitalism, because most corporations within capitalism are top-down organisation, "my way or the highway" from whoever your manager is, and most corporations fail quickly. The reason this works anyway is that society benefits because of the out-sized benefit of the few which succeed wildly; on a global scale there's something similar, with ~200 experiments called "nations" rather than "corporations", and right now the world is mainly getting richer and cleaner because of the outsized success from China — because the economic policies of China happen to be the ones which work, not because China's the most free.
The thing is though, when you look at actual autocrats, they aren't really even fast. They are perhaps fast at protecting themselves by enriching their friends and impoverishing their threats (ie anyone that is not their friend), but you can't tell me Idi Amin or Ghadaffi built out the trains to run on time. Not even Mussolini really did that (in fact, they became worse, and also Italy ran out of bread)
> Consider a recent cliché: "Move fast and break things".
It's pretty hard to move fast when you're wading through a pile of garbage.
The "move fast and break things" strategy is a fantastic strategy when you are approaching a problem and trying to figure it out. But if you don't go back and clean things up when you do then you're left with a lot of junk and dead weight. A lot of technical debt builds up this way. It's slow and no singular instance is to blame. Just like how you don't get fat by eating a single cookie. Hell, you don't get fat by eating an entire fucking cake in one sitting. You get fat by doing so repeatedly and by not doing things to mitigate that buildup.
You can't run fast when you're fat. And you don't get fat overnight. It is slow. Maybe you gain a pound a week and lose a second on your mile time every day. You likely won't notice such effects. But by getting fat you have to work so much harder to move fast.
This is true for weight, software, countries, and all sorts of things. Professional athletes spend far more time on maintenance and implementing good habits to ensure nothing slows them down. But often we look at those things as if they provide no progress. Maybe they don't move us literally forward, but they are definitely key to doing so. Let's not make this mistake
> you're missing two things here:
> (1) The comment you're replying said they were "fast".
I actually did address this. It is my opening paragraph
> (2) Authoritarian failures are also present in capitalism
I also addressed this, in my second to last paragraph
> success from China
Interestingly I also brought them up. Read what I said about them carefully. I get it, it's a comment so I brush over 70 years quickly, but I do discuss it.
But when looking at China make sure you consider 2 things
1) China didn't succeed until it opened up and started working with the West. The policies from Deng greatly reshaped China. A man Mao kicked out of the party twice and was called a capitalist. He was the one who created the special economic zones they have today (like Shenzhen). It's something his successor continued and even Xi has. Interpret this how you will, but China's wealth didn't happen until these events and the wealthiest regions are either those zones or incredibly close to them (like Shanghai being sandwiched by two)
2) it's much easier to play catchup than lead. I expect every programmer to recognize that building a flappy bird game is pretty easy, but doing it first isn't. China has been done great on this front and hasn't fallen for the middle income trap like many others but they're not completely out of it yet. It looks like they'll succeed but be careful in counting your chickens before they hatch.
(You should also consider that information is distributed differently. As we've previously discussed and others mentioned. While in the US all our atrocities are out in the open, this is not true for autocracies. 64 (Deng was in power at that time) is a much more taboo topic than say, the Trail of Tears. In America we're quite self aware but even forget that our northern neighbors did something similar, but worse. But Canada isn't even trying that hard to hide those things. Even a much more open country like Japan is not so open about things like their invasion into China and Korea during WW2. You're aware that you should be careful in interpreting history of America as told by America, but such care must also be given when reading about others. Propaganda isn't uniquely American and we're not even that good at it)
But regardless I'm not sure what China matters in this discussion. I said
> there are so *few* examples of benevolent autocrats who made their citizens lives better.
I specifically chose to not write "no examples" because it would be inaccurate. China isn't the only one either. This isn't a binary outcome and there's many nuances. No two countries are the same, nor are two autocrats. There's many variables at play here. But what we, as citizens, care about is the trends, success rates, and stability. Maybe 70/100 democracies are stable and beneficial to citizens and 10/100 autocracies are (these numbers are entirely fictional). If given odds like that, which would you prefer? Neither is a guarantee of success.
And I want to restress something from my first comment. With great power comes great responsibility. In other recent threads we've been talking about government overreach and Flock has been in the news a lot lately. So the concept of Turnkey Tyranny gets discussed. This is still relevant here. One of democracies greatest flaws is that has the power to turn into an autocracy or any other form of government, at the will of the people. So the concept here is that you do not want to give strong powers to benevolent leaders because you cannot guarantee the next won't be. The core idea here still holds true under autocracies. The trouble is, a Turnkey Tyrant is always on the table for those countries and there is no defense. This key can turn even with the same person in power and is frequently turned with a belief that the ends justify the means. It's an all too common occurrence in autocracies, happening with people we've discussed and many of those benevolent autocrats we alluded to.
I also don't think that autocracy is more productive than democracy, but the industrial revolution is absolutely not dependent on democracy.
Imperial Germany was a practically feudal political system and yet it still managed to drive some of the most important inventions of its time and rivaled the UK and US in its economy. France under Napoleon III was by no means democratic, but had no trouble growing its economy.
More recently China has moved from an almost purely agricultural society to a fully industrialized country entirely under the auspices of an authoritarian communist party. Opening up and reform still happened under autocracy, it did not lead to any further political freedoms. The Soviet Union actually did have tremendous growth during the Great Depression but of course also stagnated after WW2 (perhaps due to its very high military spending trying to keep up with the US).
I think in general there is just a correlation between economic growth and democracy, but that they are not causally related (democracy might rather be caused by economic growth, but that is still debatable).
Eh, autocrats get away with looking like they move fast due to their lack of transparency; slow things can be dismissed or not propagandized, fast things will be shouted from the rooftops.
Autocrats also had thousands of years and generations to give their citizens freedom of expression, the freedom to innovate, to eat, have access to clean drinking water, to solve child mortality, to extend life expectancy for those who lived through childhood to be past 60, to put a man on the moon. Yet the progress of civilization was far slower before democracy.
Similar to what you suggest, many say history is written by the victors. But instead history is written by those who can write and survive. There's not much written from the perspective of a commoner for most of history. But where those writings survive, the situations do not appear pleasant.
The UK during the first half of the industrial revolution was about as democratic as some of the ancient Greek city states, and even that was an improvement over the reaches of the British Empire.
What solved all those things you list was industrialisation and (arguably) capitalism*, but capitalism itself is tens of thousands of village-sized autocratcies** where each has the freedom to try things and fail (though even that varies with time, hence debtors' prison), and back then people were still working out what "workers rights" and "health and safety" meant, hence the radium girls, or children being crushed by the power looms they were paid to clean while they were still running.
To illustrate your list with e.g. food, what solved food was the Haber-Bosch process, which is responsible for about half the nitrogen in our bodies today; the British Empire thought famines were nature's way of finding balance.
* the argument against capitalism here is the Soviet Union; the counter-argument is that the Soviets could literally just look at and copy what already existed by that point; the counter-counter-argument is that they also invented some stuff of their own; the counter-counter-counter-argument is that vanishingly few of those examples were actually state-of-the-art, and the only ones I can even think of is the first half of the Space Race.
> We humans love to make patterns out of everything.
Not sure in which vein you meant:
1. Humans exhibit some behavioral patterns.
2. Cognitive bias where the brain thinks that there is a pattern when no such pattern exist.
I think you meant the second one. I used to think I am good at noticing patterns. But then I realized that this perception about myself clouded my vision of looking at a given problem or system because my brain tried to pattern match problems and solutions. While it worked in some cases, it did not in others. And just telling myself that while I think that there's a pattern here, there may or may not be a pattern helped- just being aware of cognitive bias.
Physicists think the strongest force in the universe is the one that holds protons and neutrons together, but the real strongest force in the universe is game theory.
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"?
I think this is good advice, I'm adding it to my bag of tricks, thanks.
I have to ask a follow-up - there are cases, where the teams don't see any value in security at all, so they don't want anything that I'm selling. I think I know the answer to this one (namely, you need to build relationships with and convince the leads). But I am still looking for an alternative as the above is hard in all cases and impossible in some.
Sometimes it works to find a solution which makes the life of teams easier and comes with an additional gain in security. That can potentially be sold more easily to the team then, as you are solving a problem the team actually experiences.
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.
Software Engineers are also expected to be actual managers to climb the IC levels. Just writing code is not good enough. You need to be a project manager, architect, team leader and heavy weight persuader to be considered senior. And then you also need the paper trail to prove it.
> 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?
I don't think it's enterprise deals. I think it's communication at scale, internally. Imagine a company of m employees as a giant m*m matrix of communication slots, with a 1 for regular close communication, a 0 for no communication at all, and a 0.5 for those hallway meetings that we are assured by our CEO's are why RTO is so important (this would be those backchannels if you RTFA).
A small company, (let's say, below Dunbar's Number) has a matrix of almost all 1's just naturally. But as the company grows that matrix gets sparser and sparser- by the time you get to something like Google (180k employees plus roughly that many again contractors) you have almost all 0's with only a few 1's scattered through it. But information still needs to flow through the company, from outside a given two pizza team in, e.g. "build this not that," or from the team out, e.g "this project sucks and needs to die," or from the side, e.g. "Group Digut solved that problem that you are facing, use this package they wrote" or more personal things, e.g. "employee 24601 is awesome and needs more responsibility."
But that information is actually hugely important to the company, in an important sense all of that information is the company. So important that companies formalize the responsibilities of that information flow with managers, and formalize processes for this information to flow, so that they ensure that something is happening for all of those- that's what planning processes and promo packets and the like are all about. They are trying to make the information flow legible- the responsibility of a specific person in a specific way.
Quantitatively this seems to be where Price's law comes in:
The square root of the number of people does half the work. (Think of the matrix diagonal.) With three people in a group, 1.5 of them do half the work. With 10,000 in a group about 100 of them do half the work.
Price's law also seems to be recursive. Just like Pareto's 80/20-rule.
Also:
About every two orders of magnitude, the whole Geometry of the problem changes.
On the order of 100 people is very different from being on the order of 10,000 people.
There seems to have been an article on HN in the last few months that made a similar point related to building bridges of different lengths. About about every two orders of magnitude everything changed. A one inch bridge could be made out of spaghetti. A 2 yard bridge is different, a two mile bridge is different yet again. And a 100 mile bridge has to think about tectonics.
I'm a cofounder of a small software company that specializes in enterprise projects and I don't agree with this line, though the rest of the article rings true. Enterprises do need legibility at the project level, but that doesn't necessarily translate to internal legibility for the contracted company. You can deliver enterprise deals without demanding a particular internal development process, other than committing to and prioritizing certain features. You do need legibility at the customer-facing project management level, but that doesn't need to get so granular that you dictate how exactly developers perform and organize their work. To me the real explanation is pretty simple: large software companies need the legibility of enterprises because they are enterprises, or are trying to become one.
I spent a lot of time in the medical imaging space... most of the owners of the businesses never understood that they were in the IT services / solutions space, and not just in the medical imaging space. The reason we did so well, was not just the diagnosis part, was but the IT services space and the platforms that were created by non-radiologists that also tried to learn what radiologists wanted to be more effective.
In any large organization, expect to be audited by internal and external several times a year. The auditors want to see process documents. The more the better.
That line jumped out at me as well as being weirdly specific and reductive compared to the rest of the article which read as pretty broadly truthy.
My take as a middle manager in medium sized company (but who came from a startup background) is that some structure is necessary as a company scales just for people to know how to do their jobs. You can design it lots of different ways from light to heavy, but once you go beyond Dunbar's number you can't just rely on common sense and informal communication. If you really really hate "process", you can push things pretty far, and I guess Steam would be the canonical example here, but even there you see that it heavily filters for certain personality types and the politics can be brutal if you're not part of the in-crowd.
Not quite my area of expertise but I can venture a guess. It's not large enterprise deals, that's a bit too random and narrow minded. Large software companies care more about their position in market (market share).
At the end of the day businesses build money machines that you put money in and you take money out from various markets. You need legibility if you want to tie all development work to how it affects how much of the market you own. And it's not quite legibility that is needed, it's accurate future market share prediction, which requires a particularly strategic form of legibility. The only way to increase market share without luck is to accurately forecast what your actions will do to your market share. But how can you do that if you have no idea what your devs are building and shipping?
We tend to make fun of incompetent business people but this is what the competent ones are doing - being super accurate in their forecast of future revenue, and forcing devs to build things that will help gain market share.
Devs often don't think about business strategy enough (as evidenced by the original article, no offense). So they aren't usually good at tying everything they do back to gaining market share. Devs who are the market audience for their app can be naturally good at PMF and going from 0 to 1, but as you scale its very hard to find devs that are also the market audience of the product they are building, so they tend to be bad at predicting how their dev roadmap will affect market share gain.
Without legibility, a team of devs can be a slot machine where you pull the lever and hope the features hit the jackpot or at least a modest return and not duds. With small bets, that's a great way to become large, but its no way to run a competitive large business.
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.
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.
> Communication overhead is the single biggest killer.
True. To put a fine point on this I would add that enabling requisite communication is an exponential equation. Specifically, adding team members typically increases intra-team communication requirements exponentially as does adding teams to the organization.
> 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 believe both situations you have identified are derived from the same concepts - trust and understanding.
Trust, in that small experienced teams who have worked together for a nontrivial period of time learn in which areas each excel and where they do not.
Understanding, in that those highly effective teams value the trust established and seek to complement each other's skills.
I believe "tribal knowledge" should be an expected product of the above and is ideally captured via documentation, mentoring, presentations, etc.
Maybe it's implicit, but you didn't mention why process-people hate illegible tribal knowledge. It's because they fear that the people may have better leverage in salary re-negotiation, and if they bail, the knowledge disappears. They want exchangeable engineers as the article writes. And in a way, becoming more standardized and less unique (at least in the minds of managers) is beneficial to oil the machine of the job market and economy. Ineffective companies can be left quickly, highly profitable companies can grow more easily.
More abstractly, explicit rules are a substitute for trust. You can run your family or friend group without coming up with a literal rulebook, but this already fails in a bigger village. So you first get mythical oral religious laws, then city-state laws etc. It's always a trust-substitute. But that's the only way to scale to civilization from distributed tribal lifestyle.
I generally don’t name them, in my posts, in order to reduce the amount of “media noise” they need to search through.
Also, I will occasionally say less-than-complimentary stuff about them (not too bad, I still have massive respect for them). I’d rather not give them agita.
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.
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.
You seem to have misunderstood the point being made in the section you quoted. The items are not on the list because it is a list of benefits that accrue to the company from work being legible. "Making money" is not a direct outcome of legibility, although it is a second or third-order effect.
What I am saying is that “making money” is one factor most of legibility processes directly revolve around in any modern company. Not a second-order side effect, as original article implies.
Sure, and it's often warranted to be cynical about this, but the work about the work is really really important. Often the lower level worker thinks they do everything and the upper levels just chat and politick around. E.g. if you're a truck driver you may think you are the one doing the real work. But if the bosses miscalculate if it's profitable to enter into a relationship with a customer and haul their stuff from A to B, your job won't exist. If the product managers decide to build a product that nobody will need and buy, then you can do your best engineering work and it will be for nothing. If you're a construction worker operating the drill to build a subway line, it may feel like the bosses are just having meetings and fun chats all the time, but it matters where the metro is built, they have to balance lots of interests and talk to lots of people. Real estate prices will be impacted, noise will be impacted, more people will start to show up in some places, convenience will be impacted, all that needs to be balanced with the soil situation, underground waters, etc. etc.
Decide what work should be done is just as important as the actual work, sometimes more.
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.
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
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.
"Socialism is bookkeeping", as Vladimir Lenin used to say. If you think that late-stage megacorp capitalism is pathologically bureaucratic (which it sometimes is), refresh your memory of how the Soviet bloc handled that.
I would say that these pathologies come from the lack of trust, and thus the need to surveil and control. The problem of trust does not usually occur in a small team. It does not usually occur in a commune of like-minded people, too. It's not about the economy and property rights, it's about communication and game theory.
> 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.
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.
> 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.
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.
I've been thinking about this a lot recently, I think it's a mixture of the effects of power laws we see in larger orgs having more revenue and their biggest concern is not having any issues that risks the reputation etc they've built.
Smaller more nimble orgs that are still finding their feet have an uphill climb, but the cost of mistakes is lower
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
"When disagreeing, please reply to the argument instead of calling names. 'That is idiotic; 1 + 1 is 2, not 3' can be shortened to '1 + 1 is 2, not 3."
I appreciate the feedback. I was not rebuking the HN community member who posted, but the author of the article he linked to. Refuting that original article would require a couple of thousand words. The missing perspective was that of the customer, which is essentially opposite from that of the vendor.
The budget is use-or-lose. The contracts with the major suppliers condition large "discounts" on spend increasing every year. The exact targets of the spend are either specified by the auditors or not specified at all. I have been in meetings where between ~50-100 managers and architects were told, we have to spend 15% more with ___ next year, here is their list of software SKUs, what is your Christmas list?
I disagree with your second sentence above. I think it is shallow dismissals that are inappropriate here. Conversely, I have upvoted a number of long explanations of interesting topics.
If you don't have time to write a detailed refutation, that's entirely understandable! But if you do, I would love to read it.
I did appreciate your paragraph length comment on the matter elsewhere in this thread.
My original comment was one of those "if you know, you know" things.
Topics age out very quickly on this site.
I have two lengths: aphorism or six pages. The graf that you so kindly praise raises more questions than it answers and I am not comfortable with that.
I am also not comfortable with spoon-feeding my own views, which are evidently idiosyncratic. At medium length, that is the effect. To marshal citations and evidence in order to re-attain objectivity really does explode the level of effort. It is worthwhile, but this is a quick-hit forum, things roll off the front page usually in about an hour or two.
The flip side of that is that there will be other opportunities.
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
> 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.
This is a strawman. No competent CEO thinks they need to be on top of your unit testing practices. The levels of legibility that companies actually aim for are much more defensible.
> The levels of legibility that companies actually aim for are much more defensible
Many companies run in such a way that there is no bucket for "engineers get to do stuff they know is important x% of the time." So what happens is that things that executives don't understand the significance of all get 0 time allocation. Other teams may be told they aren't allowed to work on something owned by the CI team (again often for legibility reasons).
This is how I work at a "startup" that has just a single test environment that everyone has to share after 10 years of existence.
I worked at a small startup-ish company like this: No bug tracking, no source control, no dedicated build machines (builds were published off of a random engineer's laptop, based on whatever code he had on it currently), no tests, no documentation. None of these were seen as important by the CEO (he was not a software guy). He just wanted engineers cramming features all day. When you started talking to him about development process, toolchains, infrastructure, best practices, his eyes would glaze over and ask how this helps him deal with his 5 screaming customers right now.
The CEO definitely felt he needed to be involved with these practices, to forbid them.
> This is a strawman.
It is not. I once had the misfortune of glancing at the metrics that went into an "executive dashboard" for the CEO/CTO at a startup, and started paying close attention to what they talked about during the weekly all-hands. Other more recent, and widely experienced examples of micro-management by CEOs are forced RTOs and diktats forcing employees to "leverage AI" in some form or fashion, with little care about how this impacts individual teams.
> No competent CEO thinks they need to be on top of your unit testing practices.
You seem to be acknowledging that such CEOs exist, but you built an escape hatch by labeling them as not competent. Your second sentence appears to follow the first, but it doesn't, and is a an unfalsifiable tautology.
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.
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
Test in general (unit tests paticularly strongly) are prone to the streetlight effect. The more trivial or unimportant something is, the easier it is to test it. This creates the temptation to test the easy part rather than what's important. And this can be made even worse if the organization pushes for "legibility" via the easy "legible" metrics (e.g line coverage) rather than hard "illegible" metrics (i.e. a review of the tests by an experienced engineer).
> The streetlight effect, or the drunkard's search principle, is a type of observational bias that occurs when people only search for something where it is easiest to look.
https://en.wikipedia.org/wiki/Streetlight_effect
Game dev in general has a much tighter feedback loop than most software. If you're leaking memory, you're doing that a hundred times a second. If your code is slow you get visual stuttering. If you want performant code you need to think about things like cache coherence, you can't use GC etc.
GC is ok as long as you aren't writing some factorio-like etc. Modern computers are perfectly fine doing shit ton of useless stuff 120 times a second without blinking an eye.
I agree with you for almost all of this, just a small nitpick:
GC isn't really incompatible with games, for the overwhelming majority of games, it's basically a non-factor in performance if you spend even the slightest amount of time on performance.
It's kind of similar to native code - don't allocate too much, reuse resources, don't leak them uncontrollably.
It's only a problem when you need guarantees (i.e. the game should never drop a frame) but basically no game fulfills that nowadays and it isn't a player expectation.
I agree, but that's really true for questions like "does it run fast"? And those kind of arguably fit into the "legible" camp. Whereas "is it fun?" is a question less able to be formally tested and articulated. It's "illegible".
The tighter feedback loop that helps to answer that question comes from dogfooding.
I think this is true. I am a big fan of TDD but it remains important to also do a manual test. Often things just don't work out exactly as one would think. This is especially true with things that relate to user friendliness but also with other things.
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.
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.
One of my favorite subjects is politics. I enjoy reading books about politics, and keeping up on (geo-)politics, subscribe to political magazines and honestly don’t mind navigating office politics.
Because at the heart of it it’s all the same. It’s humans acting like humans. Every person (and organization) has desires and fears. When two parties get together, balancing everyone’s wants is fun. It’s like a complicated engineering problem, except with people requirements instead, and politics is the architecture.
I think people are rad and genuinely enjoy these kinds of problems.
This is great.
A group I used to work with framed it as needs and fears, and would produce a ‘conflict map’ when heading into a situation with multiple stakeholders.
The conflict map set out the needs and fears of each group, and indicated where they were incompatible.
That information was used to proactively resolve, or at least plan around those areas of conflict.
I'd love to hear more about the conflict map. It sounds like a useful strategy.
How was it a map?
https://css.ethz.ch/content/dam/ethz/special-interest/gess/c... has an entry on 'Needs-fears mapping'
That's an awesome resource thank you.
The conflict maps I was exposed to were much simpler - just a bunch of wobbly circles surrounding a centra issue or event. Wobbly circle intersections denoted needs/fears incompatibility implying potential conflict.
Thank you. There is a lot to absorb there.
My own experience is that it's hard to do predictable engineering in more social environments because requirements can change from one hour to another and there's no reprocurssiom, you just have accept it and move on.
Although this also happens in office environments, there's more accountability and continuous planning, making requirements changes something that is undesirable.
I only recently realized this. I was seeing geopolitics as an intricate, emergent behavior of complex systems made of hundreds of diplomats. I realized it was merely interpersonal relationships between a few country leaders who happen to have power over their respective states, military etc. This is not as different as kindergarten playground drama and squabbles, to some approximation of course.
I think that's the wrong lesson to take. The realist approach to international relations where states are controlled from the top as you describe is more legible. Instead I agree that it's really based on interpersonal relationships, but that those relationships are between CEOs, diplomats, immigrant communities, military officers, and of course also country leaders. This illegible network is what guides actually guides policy.
For sure, the decisions and actions of national leaders are deeply intertwined with this illegible network.
Is it not natural for that? I think less so between social and romantic but larger businesses and governments have definitely share many of the same problems. Though I think businesses tend to be much more autocratic. Maybe feudal is a better term?
There's definitely a lot of differences but I think the larger a business becomes the more government like it becomes. Or at least it appears that way to me. I mean they're both very bureaucratic
Govts are typically "large enterprise". In most cases the largest enterprise in a country.
In some countries they also have the burden of being legible to outsiders. Between the shareholders (voters) and journalists etc there's a lot of process that has to be transparent.
This transparency is legibility driven to extremes. If an enterprise kills a project (think Windows Phone) its done, and we move on. If a govt kills a project there's a lot of external attention on what went wrong, who's getting fired (or going to jail) and how "our money got wasted".
So yes, as things get bigger they matter to more people. The more people involved the more every single thought and action has to be meticulously detailed.
Which is party why (democratic) govt is soooo bad at actually getting anything done. Feudal govts, and autocratic businesses, get a lot done - much of it quickly. It might not be good. It might be motivated my enrichment not care, but it gets done fast.
A good autocrat moves the needle, and things get a lot better very quickly. A bad autocrat achieves his goals, often at enormous cost to the organization (which may not survive. )
All that happened under democracy.
So I call BS to claims that democracy means the government is so bad at getting things done. Perhaps you're pointing the finger at the wrong variable.
It's true, a benevolent dictator can do a lot of good. It's also true that we don't have the proof for the counterfactual of what I discussed above.But if these autocrats were as good as you suggest then it begs the question of why the Industrial Revolution and many of the great leaps forward didn't happen under them? Or why during the rise of democracy in the west did the remaining monarchies and autocrats not also flourish? Post WW2 why did the top down economies of the USSR and China also not see such success? (China didn't succeed until much later, when it opened up) Those countries across that same time that democracies made such advancements did not win out.
You can say that maybe those leaders weren't the best, but we're talking about many generations here. So then what? Benevolent autocrats are rare? That seems like a great flaw.
You also forget the old cliché: the road to hell is paved with good intentions. History has shown that there were many kings and rulers who sought to do good and do good by the people, yet in these efforts caused great disaster. You could take the Four Pest Campaign as a relatively recent example. It was definitely implemented with good intentions but ended up being one of, if not the, greatest environmental disasters of all time. Estimates are that between 1% and 10% of the population at the time starved.
This is not to say that democracies have not also caused great harm. One needs not believe there is a global optimal solution to such a complex problem, but that does not mean certain solutions aren't strictly better than others. A benefit to democracies is that it is difficult to bury the mistakes. They say history is told by the victors but that's not entirely true. History is written by those who write and the writings that can be preserved. In democracies this is available to far more people. It is unlikely that you have an accurate understanding of the daily lives of those who lived more than a few hundred years ago. No one was recording that.
On paper I think the idea of a benevolent autocrat sounds good. But in reality there are so few examples of benevolent autocrats who made their citizens lives better. Sure, many built great monuments but that's not the same thing. It is simply difficult to role effectively over so large of an ecosystem. The world is too complex for one man to make informed decisions. I'm sure if you are honest with yourself you'll find that even far smaller tasks, ones you may be apart of, share this feature. When a single mind cannot handle all the complexities, you must turn to a collective. But a feudal society is not a dictatorship, even if it appears so locally
> The great technological leaps forward ... All that happened under democracy.
I think you're conflating "governments were democratic at a time these things happened" with "the government did these things directly itself via its institutions".
Of those achievements, only the space race was actually executed by the government, and it's not a great counter-example because it was done purely to compete with the achievements of an autocratic government (the USSR).
The rest was private sector efforts. It wasn't a government institution that built toilets.
> it begs the question of why the Industrial Revolution and many of the great leaps forward didn't happen under them?
They did. USSR famously went through forced industrialization.
Please read my entire comment
Your point is?In addition to what the other's comments have said, I think you're missing two things here:
(1) The comment you're replying to didn't say autocrats were "good", they said they were "fast".
(2) Authoritarian failures are also present in capitalism, because most corporations within capitalism are top-down organisation, "my way or the highway" from whoever your manager is, and most corporations fail quickly. The reason this works anyway is that society benefits because of the out-sized benefit of the few which succeed wildly; on a global scale there's something similar, with ~200 experiments called "nations" rather than "corporations", and right now the world is mainly getting richer and cleaner because of the outsized success from China — because the economic policies of China happen to be the ones which work, not because China's the most free.
The thing is though, when you look at actual autocrats, they aren't really even fast. They are perhaps fast at protecting themselves by enriching their friends and impoverishing their threats (ie anyone that is not their friend), but you can't tell me Idi Amin or Ghadaffi built out the trains to run on time. Not even Mussolini really did that (in fact, they became worse, and also Italy ran out of bread)
That's evidence of them being "not good" rather than "not fast"; the former isn't in dispute.
Consider a recent cliché: "Move fast and break things".
The "move fast and break things" strategy is a fantastic strategy when you are approaching a problem and trying to figure it out. But if you don't go back and clean things up when you do then you're left with a lot of junk and dead weight. A lot of technical debt builds up this way. It's slow and no singular instance is to blame. Just like how you don't get fat by eating a single cookie. Hell, you don't get fat by eating an entire fucking cake in one sitting. You get fat by doing so repeatedly and by not doing things to mitigate that buildup.
You can't run fast when you're fat. And you don't get fat overnight. It is slow. Maybe you gain a pound a week and lose a second on your mile time every day. You likely won't notice such effects. But by getting fat you have to work so much harder to move fast.
This is true for weight, software, countries, and all sorts of things. Professional athletes spend far more time on maintenance and implementing good habits to ensure nothing slows them down. But often we look at those things as if they provide no progress. Maybe they don't move us literally forward, but they are definitely key to doing so. Let's not make this mistake
But when looking at China make sure you consider 2 things
1) China didn't succeed until it opened up and started working with the West. The policies from Deng greatly reshaped China. A man Mao kicked out of the party twice and was called a capitalist. He was the one who created the special economic zones they have today (like Shenzhen). It's something his successor continued and even Xi has. Interpret this how you will, but China's wealth didn't happen until these events and the wealthiest regions are either those zones or incredibly close to them (like Shanghai being sandwiched by two)
2) it's much easier to play catchup than lead. I expect every programmer to recognize that building a flappy bird game is pretty easy, but doing it first isn't. China has been done great on this front and hasn't fallen for the middle income trap like many others but they're not completely out of it yet. It looks like they'll succeed but be careful in counting your chickens before they hatch.
(You should also consider that information is distributed differently. As we've previously discussed and others mentioned. While in the US all our atrocities are out in the open, this is not true for autocracies. 64 (Deng was in power at that time) is a much more taboo topic than say, the Trail of Tears. In America we're quite self aware but even forget that our northern neighbors did something similar, but worse. But Canada isn't even trying that hard to hide those things. Even a much more open country like Japan is not so open about things like their invasion into China and Korea during WW2. You're aware that you should be careful in interpreting history of America as told by America, but such care must also be given when reading about others. Propaganda isn't uniquely American and we're not even that good at it)
But regardless I'm not sure what China matters in this discussion. I said
I specifically chose to not write "no examples" because it would be inaccurate. China isn't the only one either. This isn't a binary outcome and there's many nuances. No two countries are the same, nor are two autocrats. There's many variables at play here. But what we, as citizens, care about is the trends, success rates, and stability. Maybe 70/100 democracies are stable and beneficial to citizens and 10/100 autocracies are (these numbers are entirely fictional). If given odds like that, which would you prefer? Neither is a guarantee of success.And I want to restress something from my first comment. With great power comes great responsibility. In other recent threads we've been talking about government overreach and Flock has been in the news a lot lately. So the concept of Turnkey Tyranny gets discussed. This is still relevant here. One of democracies greatest flaws is that has the power to turn into an autocracy or any other form of government, at the will of the people. So the concept here is that you do not want to give strong powers to benevolent leaders because you cannot guarantee the next won't be. The core idea here still holds true under autocracies. The trouble is, a Turnkey Tyrant is always on the table for those countries and there is no defense. This key can turn even with the same person in power and is frequently turned with a belief that the ends justify the means. It's an all too common occurrence in autocracies, happening with people we've discussed and many of those benevolent autocrats we alluded to.
I also don't think that autocracy is more productive than democracy, but the industrial revolution is absolutely not dependent on democracy.
Imperial Germany was a practically feudal political system and yet it still managed to drive some of the most important inventions of its time and rivaled the UK and US in its economy. France under Napoleon III was by no means democratic, but had no trouble growing its economy.
More recently China has moved from an almost purely agricultural society to a fully industrialized country entirely under the auspices of an authoritarian communist party. Opening up and reform still happened under autocracy, it did not lead to any further political freedoms. The Soviet Union actually did have tremendous growth during the Great Depression but of course also stagnated after WW2 (perhaps due to its very high military spending trying to keep up with the US).
I think in general there is just a correlation between economic growth and democracy, but that they are not causally related (democracy might rather be caused by economic growth, but that is still debatable).
Eh, autocrats get away with looking like they move fast due to their lack of transparency; slow things can be dismissed or not propagandized, fast things will be shouted from the rooftops.
Autocrats don't automatically execute faster.
Autocrats also had thousands of years and generations to give their citizens freedom of expression, the freedom to innovate, to eat, have access to clean drinking water, to solve child mortality, to extend life expectancy for those who lived through childhood to be past 60, to put a man on the moon. Yet the progress of civilization was far slower before democracy.
Similar to what you suggest, many say history is written by the victors. But instead history is written by those who can write and survive. There's not much written from the perspective of a commoner for most of history. But where those writings survive, the situations do not appear pleasant.
The UK during the first half of the industrial revolution was about as democratic as some of the ancient Greek city states, and even that was an improvement over the reaches of the British Empire.
What solved all those things you list was industrialisation and (arguably) capitalism*, but capitalism itself is tens of thousands of village-sized autocratcies** where each has the freedom to try things and fail (though even that varies with time, hence debtors' prison), and back then people were still working out what "workers rights" and "health and safety" meant, hence the radium girls, or children being crushed by the power looms they were paid to clean while they were still running.
To illustrate your list with e.g. food, what solved food was the Haber-Bosch process, which is responsible for about half the nitrogen in our bodies today; the British Empire thought famines were nature's way of finding balance.
* the argument against capitalism here is the Soviet Union; the counter-argument is that the Soviets could literally just look at and copy what already existed by that point; the counter-counter-argument is that they also invented some stuff of their own; the counter-counter-counter-argument is that vanishingly few of those examples were actually state-of-the-art, and the only ones I can even think of is the first half of the Space Race.
** most corporations are not democracies; the rare ones which are, are "worker co-operatives": https://en.wikipedia.org/wiki/Worker_cooperative
https://en.wikipedia.org/wiki/Game_theory
Considering modern day politicians are more likely than ever to come out from their daily office jobs, this would not be much of a surprise.
The larger the group the more refined qualities are lost. It's terrifying!
We humans love to make patterns out of everything.
> We humans love to make patterns out of everything.
Not sure in which vein you meant: 1. Humans exhibit some behavioral patterns.
2. Cognitive bias where the brain thinks that there is a pattern when no such pattern exist.
I think you meant the second one. I used to think I am good at noticing patterns. But then I realized that this perception about myself clouded my vision of looking at a given problem or system because my brain tried to pattern match problems and solutions. While it worked in some cases, it did not in others. And just telling myself that while I think that there's a pattern here, there may or may not be a pattern helped- just being aware of cognitive bias.
Physicists think the strongest force in the universe is the one that holds protons and neutrons together, but the real strongest force in the universe is game theory.
Game theory has its place. But most game-theory explanations that I see fail to take humanity into account.
People are irrational actors way more often than they are rational ones.
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?
Offer to trade your teams engineers to work on a product/feature/roadmap item of their choice in exchange for them doing your thing.
I think this is good advice, I'm adding it to my bag of tricks, thanks.
I have to ask a follow-up - there are cases, where the teams don't see any value in security at all, so they don't want anything that I'm selling. I think I know the answer to this one (namely, you need to build relationships with and convince the leads). But I am still looking for an alternative as the above is hard in all cases and impossible in some.
Sometimes it works to find a solution which makes the life of teams easier and comes with an additional gain in security. That can potentially be sold more easily to the team then, as you are solving a problem the team actually experiences.
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.
Software Engineers are also expected to be actual managers to climb the IC levels. Just writing code is not good enough. You need to be a project manager, architect, team leader and heavy weight persuader to be considered senior. And then you also need the paper trail to prove it.
> 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?
I don't think it's enterprise deals. I think it's communication at scale, internally. Imagine a company of m employees as a giant m*m matrix of communication slots, with a 1 for regular close communication, a 0 for no communication at all, and a 0.5 for those hallway meetings that we are assured by our CEO's are why RTO is so important (this would be those backchannels if you RTFA).
A small company, (let's say, below Dunbar's Number) has a matrix of almost all 1's just naturally. But as the company grows that matrix gets sparser and sparser- by the time you get to something like Google (180k employees plus roughly that many again contractors) you have almost all 0's with only a few 1's scattered through it. But information still needs to flow through the company, from outside a given two pizza team in, e.g. "build this not that," or from the team out, e.g "this project sucks and needs to die," or from the side, e.g. "Group Digut solved that problem that you are facing, use this package they wrote" or more personal things, e.g. "employee 24601 is awesome and needs more responsibility."
But that information is actually hugely important to the company, in an important sense all of that information is the company. So important that companies formalize the responsibilities of that information flow with managers, and formalize processes for this information to flow, so that they ensure that something is happening for all of those- that's what planning processes and promo packets and the like are all about. They are trying to make the information flow legible- the responsibility of a specific person in a specific way.
Quantitatively this seems to be where Price's law comes in:
The square root of the number of people does half the work. (Think of the matrix diagonal.) With three people in a group, 1.5 of them do half the work. With 10,000 in a group about 100 of them do half the work.
Price's law also seems to be recursive. Just like Pareto's 80/20-rule.
Add Conway’s law to this and you are all set.
Also: About every two orders of magnitude, the whole Geometry of the problem changes.
On the order of 100 people is very different from being on the order of 10,000 people.
There seems to have been an article on HN in the last few months that made a similar point related to building bridges of different lengths. About about every two orders of magnitude everything changed. A one inch bridge could be made out of spaghetti. A 2 yard bridge is different, a two mile bridge is different yet again. And a 100 mile bridge has to think about tectonics.
I'm a cofounder of a small software company that specializes in enterprise projects and I don't agree with this line, though the rest of the article rings true. Enterprises do need legibility at the project level, but that doesn't necessarily translate to internal legibility for the contracted company. You can deliver enterprise deals without demanding a particular internal development process, other than committing to and prioritizing certain features. You do need legibility at the customer-facing project management level, but that doesn't need to get so granular that you dictate how exactly developers perform and organize their work. To me the real explanation is pretty simple: large software companies need the legibility of enterprises because they are enterprises, or are trying to become one.
I spent a lot of time in the medical imaging space... most of the owners of the businesses never understood that they were in the IT services / solutions space, and not just in the medical imaging space. The reason we did so well, was not just the diagnosis part, was but the IT services space and the platforms that were created by non-radiologists that also tried to learn what radiologists wanted to be more effective.
In any large organization, expect to be audited by internal and external several times a year. The auditors want to see process documents. The more the better.
The worst case is your auditor “fires” you as a customer. For example, https://apnews.com/article/super-micro-computer-stock-audito...
That line jumped out at me as well as being weirdly specific and reductive compared to the rest of the article which read as pretty broadly truthy.
My take as a middle manager in medium sized company (but who came from a startup background) is that some structure is necessary as a company scales just for people to know how to do their jobs. You can design it lots of different ways from light to heavy, but once you go beyond Dunbar's number you can't just rely on common sense and informal communication. If you really really hate "process", you can push things pretty far, and I guess Steam would be the canonical example here, but even there you see that it heavily filters for certain personality types and the politics can be brutal if you're not part of the in-crowd.
Not quite my area of expertise but I can venture a guess. It's not large enterprise deals, that's a bit too random and narrow minded. Large software companies care more about their position in market (market share).
At the end of the day businesses build money machines that you put money in and you take money out from various markets. You need legibility if you want to tie all development work to how it affects how much of the market you own. And it's not quite legibility that is needed, it's accurate future market share prediction, which requires a particularly strategic form of legibility. The only way to increase market share without luck is to accurately forecast what your actions will do to your market share. But how can you do that if you have no idea what your devs are building and shipping?
We tend to make fun of incompetent business people but this is what the competent ones are doing - being super accurate in their forecast of future revenue, and forcing devs to build things that will help gain market share.
Devs often don't think about business strategy enough (as evidenced by the original article, no offense). So they aren't usually good at tying everything they do back to gaining market share. Devs who are the market audience for their app can be naturally good at PMF and going from 0 to 1, but as you scale its very hard to find devs that are also the market audience of the product they are building, so they tend to be bad at predicting how their dev roadmap will affect market share gain.
Without legibility, a team of devs can be a slot machine where you pull the lever and hope the features hit the jackpot or at least a modest return and not duds. With small bets, that's a great way to become large, but its no way to run a competitive large business.
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.
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/
> Communication overhead is the single biggest killer.
True. To put a fine point on this I would add that enabling requisite communication is an exponential equation. Specifically, adding team members typically increases intra-team communication requirements exponentially as does adding teams to the organization.
> 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 believe both situations you have identified are derived from the same concepts - trust and understanding.
Trust, in that small experienced teams who have worked together for a nontrivial period of time learn in which areas each excel and where they do not.
Understanding, in that those highly effective teams value the trust established and seek to complement each other's skills.
I believe "tribal knowledge" should be an expected product of the above and is ideally captured via documentation, mentoring, presentations, etc.
Maybe it's implicit, but you didn't mention why process-people hate illegible tribal knowledge. It's because they fear that the people may have better leverage in salary re-negotiation, and if they bail, the knowledge disappears. They want exchangeable engineers as the article writes. And in a way, becoming more standardized and less unique (at least in the minds of managers) is beneficial to oil the machine of the job market and economy. Ineffective companies can be left quickly, highly profitable companies can grow more easily.
More abstractly, explicit rules are a substitute for trust. You can run your family or friend group without coming up with a literal rulebook, but this already fails in a bigger village. So you first get mythical oral religious laws, then city-state laws etc. It's always a trust-substitute. But that's the only way to scale to civilization from distributed tribal lifestyle.
[flagged]
Chris Marshall lists substantial time at Nikon on his LinkedIn. I suspect you've probably heard of them.
I generally don’t name them, in my posts, in order to reduce the amount of “media noise” they need to search through.
Also, I will occasionally say less-than-complimentary stuff about them (not too bad, I still have massive respect for them). I’d rather not give them agita.
It was a very pretentious thing to say.
Either mention the company
Or don’t mention the status of the company at all.
Leaving readers wondering or hanging is eyeroll-inducing.
His name is right there. If you are upset by it then spend 15s on Google.
I did, and this is what I got https://www.joinlavender.com/chris-marshall-ny
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.
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:
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.
You seem to have misunderstood the point being made in the section you quoted. The items are not on the list because it is a list of benefits that accrue to the company from work being legible. "Making money" is not a direct outcome of legibility, although it is a second or third-order effect.
What I am saying is that “making money” is one factor most of legibility processes directly revolve around in any modern company. Not a second-order side effect, as original article implies.
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.
Sure, and it's often warranted to be cynical about this, but the work about the work is really really important. Often the lower level worker thinks they do everything and the upper levels just chat and politick around. E.g. if you're a truck driver you may think you are the one doing the real work. But if the bosses miscalculate if it's profitable to enter into a relationship with a customer and haul their stuff from A to B, your job won't exist. If the product managers decide to build a product that nobody will need and buy, then you can do your best engineering work and it will be for nothing. If you're a construction worker operating the drill to build a subway line, it may feel like the bosses are just having meetings and fun chats all the time, but it matters where the metro is built, they have to balance lots of interests and talk to lots of people. Real estate prices will be impacted, noise will be impacted, more people will start to show up in some places, convenience will be impacted, all that needs to be balanced with the soil situation, underground waters, etc. etc.
Decide what work should be done is just as important as the actual work, sometimes more.
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.
It's a great book, you should def read it
For these and many other reasons: small company > large company.
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
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.
"Socialism is bookkeeping", as Vladimir Lenin used to say. If you think that late-stage megacorp capitalism is pathologically bureaucratic (which it sometimes is), refresh your memory of how the Soviet bloc handled that.
I would say that these pathologies come from the lack of trust, and thus the need to surveil and control. The problem of trust does not usually occur in a small team. It does not usually occur in a commune of like-minded people, too. It's not about the economy and property rights, it's about communication and game theory.
[flagged]
It seems to me the next opportunity for Sean is to integrate this logic with The Goal (1985) extended universe of works.
Next post should be How to Create TPS Reports
> 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.
Dunbar's number and the fractal nature of managing things in the real world.
You manage surface area, not volume or area, and the coastline is pretty bumpy.
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.
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.
> 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.
Loved this article. Thanks!
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.
I've been thinking about this a lot recently, I think it's a mixture of the effects of power laws we see in larger orgs having more revenue and their biggest concern is not having any issues that risks the reputation etc they've built.
Smaller more nimble orgs that are still finding their feet have an uphill climb, but the cost of mistakes is lower
[flagged]
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
"When disagreeing, please reply to the argument instead of calling names. 'That is idiotic; 1 + 1 is 2, not 3' can be shortened to '1 + 1 is 2, not 3."
"Don't be snarky."
https://news.ycombinator.com/newsguidelines.html
I appreciate the feedback. I was not rebuking the HN community member who posted, but the author of the article he linked to. Refuting that original article would require a couple of thousand words. The missing perspective was that of the customer, which is essentially opposite from that of the vendor.
And yet the customers keep buying from the big shops. Perplexing in some ways, and also a cold hard fact of reality.
Did you have something more to add? I am definitely curious to understand more of your perspective.
Cheers.
The budget is use-or-lose. The contracts with the major suppliers condition large "discounts" on spend increasing every year. The exact targets of the spend are either specified by the auditors or not specified at all. I have been in meetings where between ~50-100 managers and architects were told, we have to spend 15% more with ___ next year, here is their list of software SKUs, what is your Christmas list?
A substantial portion of the linked article is about the specific priorities of enterprise software customers.
Speaking as one such customer, it is all false. Again, a detailed refutation would run to such length as to abuse the hospitality of this forum.
I disagree with your second sentence above. I think it is shallow dismissals that are inappropriate here. Conversely, I have upvoted a number of long explanations of interesting topics.
If you don't have time to write a detailed refutation, that's entirely understandable! But if you do, I would love to read it.
I did appreciate your paragraph length comment on the matter elsewhere in this thread.
My original comment was one of those "if you know, you know" things.
Topics age out very quickly on this site.
I have two lengths: aphorism or six pages. The graf that you so kindly praise raises more questions than it answers and I am not comfortable with that.
I am also not comfortable with spoon-feeding my own views, which are evidently idiosyncratic. At medium length, that is the effect. To marshal citations and evidence in order to re-attain objectivity really does explode the level of effort. It is worthwhile, but this is a quick-hit forum, things roll off the front page usually in about an hour or two.
The flip side of that is that there will be other opportunities.
Fair enough! If you ever have the time and inclination to write it up as a blog post or such, I would love to read it.