Is Google something to aspire to? They got early into a very lucrative market and have basically been milking it for decades. Good for them but luck isn't reproducible. Their ability to deliver new products is so bad it's literally a joke. I can't even remember any viable new product from them in the last decade (the 10th iteration of chat doesn't count). In terms of productivity they were known as a rest and vest company. Great for engineers but I can't imagine it's great for a company without a near infinite spigot of money.
They'll still have better insight on the subject than your average joe blow startup.
I mean a company is effectively "just" a machine to deliver a service / outcome from inputs. It is a set of processes - which can be codified. why not in software? And if you want to chnage the process, make a release.
The hard part of the "machine to deliver a service / outcome from inputs" is not "formalizing a process in code." It's designing that process, in all its gross real-world complexities, and then (even harder) changing it as the underlying world changes.
If it was easy to actually nail down the requirements in advance, you could ship out the coding to meet a spec to the lowest bidder.
A number of comments are "it will be awful if the code is bad because the code is inflexible". Yes. That's called bad law. What we want is to write good law.
See the Manna story below.
So the interesting question is, in that context is a manager becoming ever less necessary
I shudder at the thought of being managed as badly as most code works. Most sufficiently complex technologies have to be operated in manual override mode most of the time.
This just doesn't match my experiences at all. So much of what we do to build software has nothing to do with the actual code. I've recently worked in both a very micro-services oriented organization and a magnificent monolith and they have very similar, non-code problems; the difference is were they exist in the software and in the organization.
If you're interested to see how your "operational management defines composition" idea can go horribly wrong, google what happened when Dell migrated their hierarchy to align with micro-services
In the fifties management studies (Drucker etc) was focused on the manager as a systems creator - who would bestride the business world fixing, innovating creating smooth clockwork systems.
Today Google's eight rules for managers is basically a cross between HR and a life coach.
Systems are now run by software - and the inevitable conclusion is that coders are the new managers.
As more and more software eats more and more of the world, there is less and less need for anyone who is not coding or talking about the code.
We may see the end of rigid hierarchies at the same time (a similar but related issue), which kind of points to two things
- code is the thing. And discussions around the code matter. And the prime examples of doing this are in FOSS - so expect more open public disagreements leading to better quality code
- Public (internal) discussion of issues means a lot of self-governance and a lot of "politics". This goes on anyway but if it is kept public it is kept honest
- management has always been about resource allocation and it is best to view senior management as financiers not executives - this might be the best split internally - senor management buying from internal self organised resources.
- Incodentslly I think a lot of the problems facing most companies today are that they cannot work out how to measure quality work during rmeote work and cannot get people to communicate if they are not all in the office. Having a big email discussion list is unwieldy - but if that is your organisation then conways law will explain how your software works. if you don't like it, it is waaay easier to adjust your email lists than move offices.