So the "managing pistons" comment is relevant I think. At a certain level of abstraction you are right - you don't care if the engine is poweeed by pistons and spark plugs or swans tied by ribbons. you press the pedal you go faster. Let's measure those levels of abstraction somehow - I am going to guess that you need to be 2 orders of magnitude (of some thing or other) removed before the abstraction is relevant - so if you have 1 client you really need to care bout everything about them. With 100 clients it does not matter too much and with 10,000 clients your abstraction level is enough who cares what any one client thinks. (ignoring every customer motto poster for 30 years).

Now this abstraction model of management is useful I think in explaining the difference in middle management and upper management - middle are still inside the abstraction level as the people they are managing - so for 100 people there are say 10'middle managers and one upper manager. The middle managers have to care about the 9 people they manage but the one upper manager probably does not have to worry about the behaviours of those 9.

Maybe it's 3 orders of magnitude - who knows. But there is something.

Now the upper manager (100) will have some mental model of how the work is arranged below him. And then the upper uppper manager (10,000) will have a similar mental model. But it will probably be much more "pour in money, get an expected output".

The problem is how effective the mental model is. Somewhere between the foppiest of aristocratic imbeciles and, I dunno, Steve Jobs, most upper management have mental models that are misaligned with reality.

So back to software.

When we release software we are making a chnage to, yes, an organisation. How that organisation behaves and performs. We are then managing that org. Coders manage because they are the ones making the small but consequential design decisions (see "the code is the design"). They are organising the code, which organises the compmay. They are making management decisions (at low level, less the 2 orders magnitude). But it is still managing by any sensible definition (no true scotsman would disagree)

Software offers another interesting idea - that for each release there is an expected outcome - we will see a reduction in spam by this much or a increase in revenue from left handed mechanics in Ohio or increase is latency for these queries or whatever.

The point is for a company that wants to it can build models of how it's codebase works and how chnaging some parts of it affects other parts. And test that model on every release.

in short you can build a battle tested "mental model" of your own organisation. So when upper management (4 orders of magnitude) want to make a chnage they can make expected predictions about the model and its change. Be transparent about it.

They can find that software makes implicit explicit - that if you have a company that behaves day to day via code, if it is driven by software (for example deliver these parcels to these locations) then you are a programmable company - and what you do day to day is programmable. And also modellable.

If you want to make large scale changes, you can. just look for the right piece of code. If you want to check if those changes are right ones you have a daily tested model of likely affects. That is waaay better than "CEOs gut feel" or "an excel we mocked up in two days with Bain and co"

And importantly that model can be brought up in court when you get sued for the terrible M&A decision you made that got you your second yacht.

So that's a long post and I may have lost my thread but, when the workers are ridiculously leveraged (as coders can be) the idea of managing them as previously seems foolish.

Maybe the coders building the apps that tell Amazon workers where to drive and when - are they the new managers of the drivers? Are the people deciding if those drivers should work 20'hournshidts or just 19 hours the real managers?

Somewhere along the line we have lost the need for a huge slub of "people who organise workers" and if we lose them, there is another set of "people who communicate and co-ordinate so an org with so many people are all aligned". once we get rid of those sets of people, and most other people just do what the software tells them, there is far less managing of people needed.

So that's a programmable company and coders as managers in a nutshell.

I may be crazy or above or "just don't know how the world works". But I don't think so.