> 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'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.
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.
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.
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.
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.
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.
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
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.
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.
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.
> 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 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.
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"?
> 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.
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.
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.
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.
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.
The truth that a lot of people don't want to hear is that tests are insufficient to prove your code is bug free
When saying these words aloud (or even on HN) many will reinterpret them as "tests are worthless". It's hard to reorient to "tests are incomplete". I'm not sure why this is such a difficult concept to understand. Unless you're omniscient, how can they be complete?
People need to understand, you cannot measure anything directly. You are always doing so by proxy. If you do not know the limits of your proxy then you're only allowing yourself to be blind to foreseeable problems.
So, tests are hints, not proofs. They prove correctness in narrow areas, but not completely. Worse, you cannot test unknown unknowns. Which, as you suggest, is why dog fooding is such an important part of the development process. You aren't just a developer, you need to be a user and an adversary. You should try to see your programs from as many perspectives as possible. This too won't get you to full coverage, but it'll get you a lot further than just tests and it'll help you find what tests need to be created.
If you're just doing TDD, you're just applying Goodhart's Law
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.
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.
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 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.
You and I are in a similar boat. We have the luxury of avoiding "big organisation" problems that mean people need, or want, legibility. And I will do everything I can in my career to keep it that way!
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 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.
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
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
46 comments
[ 4.1 ms ] story [ 63.0 ms ] threadAnyone willing to comment for whom this is their area of expertise?
The worst case is your auditor “fires” you as a customer. For example, https://apnews.com/article/super-micro-computer-stock-audito...
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.
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.
Maybe it's the mathematician in me who enjoys building models of abstraction.
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
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.
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.
You manage surface area, not volume or area, and the coastline is pretty bumpy.
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/
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.
Pretty please?
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.
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.
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.
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
When saying these words aloud (or even on HN) many will reinterpret them as "tests are worthless". It's hard to reorient to "tests are incomplete". I'm not sure why this is such a difficult concept to understand. Unless you're omniscient, how can they be complete?
People need to understand, you cannot measure anything directly. You are always doing so by proxy. If you do not know the limits of your proxy then you're only allowing yourself to be blind to foreseeable problems.
So, tests are hints, not proofs. They prove correctness in narrow areas, but not completely. Worse, you cannot test unknown unknowns. Which, as you suggest, is why dog fooding is such an important part of the development process. You aren't just a developer, you need to be a user and an adversary. You should try to see your programs from as many perspectives as possible. This too won't get you to full coverage, but it'll get you a lot further than just tests and it'll help you find what tests need to be created.
If you're just doing TDD, you're just applying Goodhart's Law
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.
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.
Actually knowing minutiae of what they do seems like make work to me.
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.
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.
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
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