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.
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 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.
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.
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
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.
> 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.
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.
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.
> 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.
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 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.
> 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.
> 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.
"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.
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.
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.
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. )
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
Autocrats don't automatically execute faster.
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.
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.
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.
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.
The worst case is your auditor “fires” you as a customer. For example, https://apnews.com/article/super-micro-computer-stock-audito...
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.
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.
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.
Either mention the company
Or don’t mention the status of the company at all.
Leaving readers wondering or hanging is eyeroll-inducing.
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.
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.
"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
Did you have something more to add? I am definitely curious to understand more of your perspective.
Cheers.
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.