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.
The most legible metric in the vicinity of responsible, high-quality software engineering practice is unit test coverage. It's practically guaranteed that VPs of Engineering are reporting on test coverage to the CTO, and not implausible that he's reporting on that in aggregate to the CEO.
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.
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 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.
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.
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
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.
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.
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. )
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.
> 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.
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 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.
> 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.
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.
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.
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.
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 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.
Readit News
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
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.
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.
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.
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 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
https://en.wikipedia.org/wiki/Streetlight_effect
The tighter feedback loop that helps to answer that question comes from dogfooding.
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.
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
Maybe it's the mathematician in me who enjoys building models of abstraction.
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.
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.
Although this also happens in office environments, there's more accountability and continuous planning, making requirements changes something that is undesirable.
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
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. )
People are irrational actors way more often than they are rational ones.
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.
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.
Pretty please?
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.
Anyone willing to comment for whom this is their area of expertise?
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.
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.
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.
The worst case is your auditor “fires” you as a customer. For example, https://apnews.com/article/super-micro-computer-stock-audito...
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 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.
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.
Dead Comment