[deltasixeight]

This type of philosophy is good but not scalable or efficient.

Scalability and efficiency requires well defined specialized roles. Additionally the more specialized and "stupid" each compartmentalized role is... the more efficient and scalable the organization becomes. Heavy Specialization is in fact the root reason for the complexity of civilization in the modern world. Therefore, if the objective is growth and efficiency, management of every organization must seek to organize the hierarchy in a way where each role becomes small and extremely well defined.

See McDonald or similar for the huge scalability and efficiency that is brought on by the opposite philosophy of Rickover.

Rickovers' philosophy optimizes for flexibility and creativity at the huge cost of basically zero scalability. This type of philosophy is good for labs and R&D work.

In terms of software I currently work at a company that affords this level of flexibility, freedom and ownership. Software Engineers at my company "own" their product and are given full autonomy. But they have to deal with all the politics from other stakeholders and generally spend less time doing actual software.

A software engineer allowed to deep dive on a stream of tickets/tasks while being defended from non-software related issues by a manager is by far more efficient than one given the responsibility of "ownership."

Literally software engineers at my company are expected to push products to production and cat herd all the required people to make it a reality.

What in your mind is a better setup? One where a manager does the cat-herding and the software engineer is given the very small task of just coding? Or One where the software engineer has ownership and responsibility of the entire product and has to manage it all the way to production?

[hitekker]

Admiral Rickover managed nuclear submarines and aircraft carriers. Moreover, he was responsible for introducing these incredibly complex and dangerous technologies to the Navy.

Claiming that his approach was “not scalable” and that yours is “flexible” sounds naive and conceited to me.

[deltasixeight]

>Claiming that his approach was “not scalable” and that yours is “flexible” sounds naive and conceited to me.

Insulting people for a differing opinion that is introduced neutrally is not a conductive way to communicate... it is way of communication that is both against the rules on this site and one that Admiral Rickover himself will condemn.

One thing that is for sure is that insults, rude behavior is not scalable or acceptable in any organization.

>Claiming that his approach was “not scalable” and that yours is “flexible” sounds naive and conceited to me.

Why don't you read what I wrote again. I said Rickovers' approach was "flexible" while my approach was "scalable." Another thing I should mention that I'm sure Admiral Rickover will agree with me on is that insulting people based off of a cursory reading and complete misinterpretation of a post is not productive for any organization. It's very careless

> Admiral Rickover managed nuclear submarines and aircraft carriers. Moreover, he was responsible for introducing these incredibly complex and dangerous technologies to the Navy.

It's debatable how efficient and productive these technologies are. The Defense industry is famous for inefficiencies and incompetence. While the feat you describe is impressive there is nuance that needs to be examined here. Objectivity is warranted. Learn to be able see things not in terms of black and white but in sets of pros and cons which is likely the reality here.

[dctoedt]

> I'm sure Admiral Rickover will agree with me on ...

FYI, Admiral Rickover (born 1900) died in 1986.

[deltasixeight]

*would've agreed

[dasil003]

This is well-stated, except one nuance: software is itself scalable, so small software teams can out perform large software teams if they can keep the requirements under control.

> A software engineer allowed to deep dive on a stream of tickets/tasks while being defended from non-software related issues by a manager is by far more efficient than one given the responsibility of "ownership."

This works if ownership boundaries are clear and unambiguous, however defining these boundaries involves many tradeoffs which may be judged incorrectly or shift over time. If so you may hear management start talking about "breaking down silos" and ICs enter a kafkaesque knightmare as the structure chokes on the communication overflow as no one is able to get the support from colleagues to get their own issues done because they are all assigned ownership of different issues.

Overall I think we need to be careful about naively optimizing for scalability and efficiency without first identifying the goal. Just as you probably wouldn't want Rickover designing enterprise software, you also don't want an OKR-toting MBA to be responsible for designing a nuclear submarine.

[deltasixeight]

You're thinking along the lines of the dimension of distribution. Yes in terms of distribution, software scales because it can be copied.

However there are many other dimensions of scalability to consider. Examine the complexity of the software system itself where thousands of people have to work on it. Eventually there will be no choice but to go this route due to rising complexity of the software. You need specialists with narrow assignments because those narrow assignments are already so complex that it takes a team to comprehend it. Engineers on these projects have to give up ownership of certain things and trust that others can handle it if they ever want to get any work done.

I stated it above as a tradeoff. Efficiency and scalability vs. flexibility. I completely agree with you on being careful about optimizing for scalability but eventually a bigger org HAS to make this tradeoff because they have no choice.

If a few bespoke nuclear submarines don't necessitate the trade off that's fine, but putting a new ever complexifying smart phone in the hands of the ENTIRE population year after year requires immense sacrifices to flexibility in the name of scalability.

[dasil003]

Yes I understand all this, hence my comment about enterprise software.

My key point is that people fetishize scalability, IMHO because of individual incentives towards wealth and power. However in practice making something scalable often means making it horrible. "Leaders" who get paid by scope and headcount are incentivized to build big frankenstein projects that are fundamentally disjointed. This makes it very hard to fix problems that come up once the practitioners dig in, because the structure imposed from above already precludes a solution.

This isn't universal, certainly there are problems where it can be broken down cleanly by specialization, but it really depends on the interfaces and communication bandwidth/abstraction leakiness between the working groups.

[deltasixeight]

Agreed. I'm not fetishizing scalability. I am saying that it is an inevitability.

If you can avoid it great, but if you continue growing. You must face it.

[closeparen]

A dedicated ticket-churner might be the most efficient way to churn tickets. But why are you so sure that the ticket stream amounts to the best long-term future for the software and its customers?

An owner can see around corners. Identify patterns in customer requests and make platform-level changes to get ahead of the customer needs not yet fully articulated. If he does it right, they never will be. He has his thumb on the pulse of production. Knows, cares, and investigates when something merely seems a little weird, before it becomes a bug report or an outage. Sees the real need behind the “requirement” and negotiates a different way to satisfy the business that doesn’t tie the architecture up in knots.

Without the understanding of the codebase that comes from having written or worked on large parts of it, one cannot hope to do this well.

I get to be an owner at my current company and it is one of the reasons I’m very hesitant to ever leave.

[deltasixeight]

> A dedicated ticket-churner might be the most efficient way to churn tickets. But why are you so sure that the ticket stream amounts to the best long-term future for the software and its customers?

Because a ticket churner worried about ownership of the entire product has his mind divided between the tickets and the product. A human spending all his effort on one task does a better job on that task than if he divided his effort on multiple tasks.

>An owner can see around corners. Identify patterns in customer requests and make platform-level changes to get ahead of the customer needs not yet fully articulated. If he does it right, they never will be. He has his thumb on the pulse of production. Knows, cares, and investigates when something merely seems a little weird, before it becomes a bug report or an outage. Sees the real need behind the “requirement” and negotiates a different way to satisfy the business that doesn’t tie the architecture up in knots.

Then there should be a dedicated person for this type of role. This dedicated person is called, the product manager. The product manager working closely with the software engineer is from a processing standpoint better than the software engineer owning the entire product. The software engineer no longer needs to context switch and you have two parallel brains working together.

However their is an inefficiency that exists in the communication between the product manager and the software developer. The software developer knows more about the code than the product manager and the product manager knows more about the interface between the product and the customer. Cross communication and lack of understanding between the engineer and the product manager is the source of many complaints.

If the software developer was the owner of the entire product than this communication efficiency is eliminated at the cost of the software developer having to have to divide his effort between multiple domains.

At a certain scale autonomy and complete ownership becomes impossible due to the complexity of the product. At this stage the company must embrace scalability at the cost of flexibility and ownership.

[snth]

I understand the desire, but there's a reason "product ownership" has become a trend. Similar to what's mentioned in the article, development and deployment and working with customers aren't independent. I would rather "own" my software than attempt to work on a stream of "isolated" tickets. And I think the real task of delivering value to stakeholders is more efficient without over-specialization.

[deltasixeight]

Consider the fact that when complexity of the system rises to a point where no human can comprehend it, the project must lean more and more on specialization rather than a bunch of jack of all trades ownership type organization.

Ideally, personally and professionally we prefer autonomy but there hits a point where logistically it becomes fundamentally impossible due to complexity. Society itself must segment itself into specialists due to immense complexities it has to deal with. Eventually organizations within these societies must do the same as they grow bigger and begin to assimilate and represent a bigger portion of the society itself.