3 ms·

Coders are the new Managers. Because CPUs are the new workers. (kind of obvious if we are knowledge workers now. At some point we had to invent the knowledge

Coders are the new Managers. Because CPUs are the new workers. (kind of obvious if we are knowledge workers now. At some point we had to invent the knowledge equivalent of a JCB or a steam engine) Now this has lots of implications. Managers are there mostly to organise and supervise workers. If one tech bro can organise a thousand CPUs globally, what is his manager organising? How we treated managers was qualitatively different to how we treated workers (see Unions for example). So do we pay the tech bro what we used to pay his manager? Do we give the tech bro a key to the executive washroom? Should we pair him up with a "politician type" who can go to the meetings? Sort of like how YC funds 2 founders cos that is shown to work better? Work theatre is still a thing, and becomes more performative the less impact your work has on any outcomes. Twitter and Musk has been an inflection point. If firing basically anyone who did not commit code, if that works (for some definition of works) then we are in a new world. "How do you manage a company through code?" - asking the same questions that were asked 500 years ago when we asked "how do you manage a company / state through written words?"

MikeTheRocker 3y ago
This makes no sense unless you're going to redefine what management means. > If one tech bro can organise a thousand CPUs globally, what is his manager organising? A programmer leveraging distributed compute is nothing like coordinating an organization.
- p_j_w 3y ago
  > A programmer leveraging distributed compute is nothing like coordinating an organization. It seems some of us have taken the analogy of the CPU to a brain a little bit too literally and reducing human interaction to computing flows. It might be true in a very strict sense if you wanna go hardcore materialist (which is fine philosophically), but it seems like a shitty mental model, doesn’t it?
- MengerSponge 3y ago
  I'd argue you just need the right flavor of abstraction. I can't wait until you can just type from bschool import mba
- potatolicious 3y ago
  Precisely. The only way to make this analogy work is we contort the notion of management/coordination so far outside of any common meaning as to render the word meaningless. When I drive a car, am I "managing" the pistons in the engine? When I'm taking a picture, am I "managing" the photosites on the sensor? The only way to make this contorted analogy work is to fully enter the mind palace and depart any semblance of the world everyone lives in.
  - lifeisstillgood 3y ago
    (a long reply) 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.
- lifeisstillgood 3y ago
  My take: designing and implementing systems that are the systems by which an organisation performs its day to day tasks. There are varying levels of abstraction etc - please see below long comment)
groby_b 3y ago
There'd be much to say about your points, but... you're missing the entire point of the article and rhapsodize on the title instead. Because the article isn't, at all, using the word "theatre" in a derogatory sense. It's specifically talking about "performing" work is important, how to avoid it from sliding into bs-ing instead, and how consulting work is related to improv theatre.
werds 3y ago
read back what you have written here in a couple of days with a clear head, you are talking total nonsense man
csours 3y ago
I have some thoughts on a parallel line. My big question is: What is the base unit of work of software development. After all, 'You can only manage what you can measure' I'm curious what other people think, so please try to come up with an answer before you read the next line. I think the base unit is 'learn and try'. Learn something and try something.
oxfordmale 3y ago
Twitter and Musk is not an inflection point. It "success story" has been kept alive by Muskovites and companies needing to justify their lay offs after overhiring Advertising revenue at Twitter has halved. Year on year traffic is down by 12% down. By all metrics Twitter is not doing well, and I am not even discussing the high debts that are crippling Twitter. See links below. https://www.bbc.com/news/business-66217641 https://www.bbc.com/news/business-66217641 https://www.cnbc.com/2023/07/10/twitter-traffic-is-nosediving-as-metas-threads-hits-100-million-users.html https://www.cnbc.com/2023/07/10/twitter-traffic-is-nosedivin...
_jal 3y ago
> Twitter and Musk has been an inflection point. Is the claim, "everyone else who accidentally buys an 11 digit social media operation will choose to run it in to the ground, too"?
aprdm 3y ago
What a crazy thing to read, makes absolute no sense in any level
ebiester 3y ago
Peter Drucker said this in 1967, in The Effective Executive. He went further in Management Challenges for the 21st Century: > [F]ewer and fewer people are "subordinates"--even in fairly low-level jobs. Increasingly they are "knowledge workers." And knowledge workers are not subordinates; they are "associates." For, once beyond the apprentice stage, knowledge workers must know more about their job than their boss does--or else they are no good at all. In fact, that they know more about their job than anybody else in the organization is part of the definition of knowledge workers... > To be sure, these associates are "subordinates" in that they depend on the "boss" when it comes to being hired or fired, promoted, appraised and so on. But in his or her own job the superior can perform only if these so-called subordinates take responsibility for educating him or her... In turn, these "subordinates" depend on the superior for direction. They depend on the superior to tell them what the "score" is. > Their relationship, in other words, is far more like that between the conductor of an orchestra and the instrumentalist than it is like the traditional superior/subordinate relationship... We are already living as though this world were true. I don't remember the last time I saw a manager fully specifying each ticket for a developer, for example. Managers are paid what managers used to be paid. The average developer is paid like a manager; their managers are paid like a manager of managers. The average manager I have worked with spend a fraction of their time in actively telling people what to do; most of their time is managing the complexity of the coordination of work and only incidentally the people.
- lifeisstillgood 3y ago
  When you say "manager" I am hearing the job description of a tech lead. And yet I look around and see many non-jobs outside of direct hierarchies but still part of this "co-ordination" blob. I wonder if it's time to ask just how many people are needed for co-ordination. My understanding is that a 1:1 ratio of "commits code" to "something co-ordination" is common (that is in ostensibly technical areas only 50% of workers code). But great quote thank you
  - ebiester 3y ago
    Tech leads and managers can have an overlap. Tech leads code, but only have one team. Managers often have 2-5 teams and pick up project management tasks. Tech leads are not expected to work with the product manager to flesh out a business case for expanding the scope of a project to retire technical debt or sit in front of the VP of Engineering (director/senior director in a large org; small orgs have entirely different roles than this anyway) and explain why the project is slated to take three months longer than initial estimates. There are three jobs of the tech EM - support the team (be the shit umbrella - navigate the bureaucracy), get the business a condensed version of what is going on with that part of the system, and all the other rest of the work to support a human organization that no longer has secretaries and administrators to just handle it. In a lot of other non-tech non-knowledge worker jobs, supporting the general organization is abstracted to middle management instead, and a manager gets drawn further into task breakdown and enforcement. That's the difference.

MikeTheRocker 3y ago

This makes no sense unless you're going to redefine what management means. > If one tech bro can organise a thousand CPUs globally, what is his manager organising? A programmer leveraging distributed compute is nothing like coordinating an organization.

p_j_w 3y ago
> A programmer leveraging distributed compute is nothing like coordinating an organization. It seems some of us have taken the analogy of the CPU to a brain a little bit too literally and reducing human interaction to computing flows. It might be true in a very strict sense if you wanna go hardcore materialist (which is fine philosophically), but it seems like a shitty mental model, doesn’t it?
MengerSponge 3y ago
I'd argue you just need the right flavor of abstraction. I can't wait until you can just type from bschool import mba
potatolicious 3y ago
Precisely. The only way to make this analogy work is we contort the notion of management/coordination so far outside of any common meaning as to render the word meaningless. When I drive a car, am I "managing" the pistons in the engine? When I'm taking a picture, am I "managing" the photosites on the sensor? The only way to make this contorted analogy work is to fully enter the mind palace and depart any semblance of the world everyone lives in.
- lifeisstillgood 3y ago
  (a long reply) 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.
lifeisstillgood 3y ago
My take: designing and implementing systems that are the systems by which an organisation performs its day to day tasks. There are varying levels of abstraction etc - please see below long comment)

groby_b 3y ago

There'd be much to say about your points, but... you're missing the entire point of the article and rhapsodize on the title instead. Because the article isn't, at all, using the word "theatre" in a derogatory sense. It's specifically talking about "performing" work is important, how to avoid it from sliding into bs-ing instead, and how consulting work is related to improv theatre.

werds 3y ago

read back what you have written here in a couple of days with a clear head, you are talking total nonsense man

csours 3y ago

I have some thoughts on a parallel line. My big question is: What is the base unit of work of software development. After all, 'You can only manage what you can measure' I'm curious what other people think, so please try to come up with an answer before you read the next line. I think the base unit is 'learn and try'. Learn something and try something.

oxfordmale 3y ago

Twitter and Musk is not an inflection point. It "success story" has been kept alive by Muskovites and companies needing to justify their lay offs after overhiring Advertising revenue at Twitter has halved. Year on year traffic is down by 12% down. By all metrics Twitter is not doing well, and I am not even discussing the high debts that are crippling Twitter. See links below. https://www.bbc.com/news/business-66217641 https://www.bbc.com/news/business-66217641 https://www.cnbc.com/2023/07/10/twitter-traffic-is-nosediving-as-metas-threads-hits-100-million-users.html https://www.cnbc.com/2023/07/10/twitter-traffic-is-nosedivin...

_jal 3y ago

> Twitter and Musk has been an inflection point. Is the claim, "everyone else who accidentally buys an 11 digit social media operation will choose to run it in to the ground, too"?

aprdm 3y ago

What a crazy thing to read, makes absolute no sense in any level

ebiester 3y ago

Peter Drucker said this in 1967, in The Effective Executive. He went further in Management Challenges for the 21st Century: > [F]ewer and fewer people are "subordinates"--even in fairly low-level jobs. Increasingly they are "knowledge workers." And knowledge workers are not subordinates; they are "associates." For, once beyond the apprentice stage, knowledge workers must know more about their job than their boss does--or else they are no good at all. In fact, that they know more about their job than anybody else in the organization is part of the definition of knowledge workers... > To be sure, these associates are "subordinates" in that they depend on the "boss" when it comes to being hired or fired, promoted, appraised and so on. But in his or her own job the superior can perform only if these so-called subordinates take responsibility for educating him or her... In turn, these "subordinates" depend on the superior for direction. They depend on the superior to tell them what the "score" is. > Their relationship, in other words, is far more like that between the conductor of an orchestra and the instrumentalist than it is like the traditional superior/subordinate relationship... We are already living as though this world were true. I don't remember the last time I saw a manager fully specifying each ticket for a developer, for example. Managers are paid what managers used to be paid. The average developer is paid like a manager; their managers are paid like a manager of managers. The average manager I have worked with spend a fraction of their time in actively telling people what to do; most of their time is managing the complexity of the coordination of work and only incidentally the people.

lifeisstillgood 3y ago
When you say "manager" I am hearing the job description of a tech lead. And yet I look around and see many non-jobs outside of direct hierarchies but still part of this "co-ordination" blob. I wonder if it's time to ask just how many people are needed for co-ordination. My understanding is that a 1:1 ratio of "commits code" to "something co-ordination" is common (that is in ostensibly technical areas only 50% of workers code). But great quote thank you
- ebiester 3y ago
  Tech leads and managers can have an overlap. Tech leads code, but only have one team. Managers often have 2-5 teams and pick up project management tasks. Tech leads are not expected to work with the product manager to flesh out a business case for expanding the scope of a project to retire technical debt or sit in front of the VP of Engineering (director/senior director in a large org; small orgs have entirely different roles than this anyway) and explain why the project is slated to take three months longer than initial estimates. There are three jobs of the tech EM - support the team (be the shit umbrella - navigate the bureaucracy), get the business a condensed version of what is going on with that part of the system, and all the other rest of the work to support a human organization that no longer has secretaries and administrators to just handle it. In a lot of other non-tech non-knowledge worker jobs, supporting the general organization is abstracted to middle management instead, and a manager gets drawn further into task breakdown and enforcement. That's the difference.