[levity]

> 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?

[mandevil]

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.

[dapperdrake]

Quantitatively this seems to be where Price's law comes in:

The square root of the number of people does half the work. (Think of the matrix diagonal.) With three people in a group, 1.5 of them do half the work. With 10,000 in a group about 100 of them do half the work.

Price's law also seems to be recursive. Just like Pareto's 80/20-rule.

Add Conway’s law to this and you are all set.

[dapperdrake]

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.

[yed]

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.

[simianpirate]

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.

[dasil003]

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.

[rawgabbit]

In any large organization, expect to be audited by internal and external several times a year. The auditors want to see process documents. The more the better.

The worst case is your auditor “fires” you as a customer. For example, https://apnews.com/article/super-micro-computer-stock-audito...

[spyckie2]

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.