4 ms·

I think management as we know it is dying. In the fifties management studies (Drucker etc) was focused on the manager as a systems creator - who would bestride

I think management as we know it is dying. 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. Edit: imagine Bezos' two pizza teams - each can be viewed as a independent contract supplying a business-micro-service - at a doctrinal level style guides and devleads / linting rule, and at an operational level it's which micro-services, how to combine their output, etc etc (i need to expand this but Amazon might not be a great company to work for but the organisational design seems to point i the right direction )

marcinzm 4y ago
>Today Google's eight rules for managers is basically a cross between HR and a life coach. 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.
- celdon25 4y ago
  > Is Google something to aspire to? They'll still have better insight on the subject than your average joe blow startup.
- lummm 4y ago
  What about GCP?
WastingMyTime89 4y ago
You do realise that a lot of things happening at most companies have absolutely nothing to do with code?
- lifeisstillgood 4y ago
  But why not? 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.
  - majormajor 4y ago
    This is how you get a "why do I have to ask on HN to get lucky to have someone at Google who knows how System X works see my post to get support on this stupid product?" reality. Inflexible machines that run on rules are not even a unique feature of software, but they are good at slowly making your customers stop liking you. 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.
    - andrewflnr 4y ago
      IMO this is truer than you may realize. The future of human work is customer service and empathy, understanding people and what they want in detail. Everything else can be automated.
    - lifeisstillgood 4y ago
      Yes. And it's not like human management does this "design a system" so well at the moment that replacing them with coders focused on explicit expressions of a process is going to be much worse. 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.
analog31 4y ago
>>>> Systems are now run by software - and the inevitable conclusion is that coders are the new managers. 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.
- PicassoCTs 4y ago
  Its freedom to manage yourself, if you can hack the system sufficiently enough, that it avoids interacting with you. So as strange as it sounds, if you are clever and already managing your manager, nothing changes.
- waste_monk 4y ago
  Reminds me of the short story Manna [1]. It gets a bit weird towards the end, but the first few chapters at least seem like a reasonable prediction of the hellscape that would result if you put a fully automated management system in charge of people. [1] https://marshallbrain.com/manna1 https://marshallbrain.com/manna1
  - lifeisstillgood 4y ago
    Love that story - thank you
skeeter2020 4y ago
>> 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. 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

marcinzm 4y ago

>Today Google's eight rules for managers is basically a cross between HR and a life coach. 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.

celdon25 4y ago
> Is Google something to aspire to? They'll still have better insight on the subject than your average joe blow startup.
lummm 4y ago
What about GCP?

WastingMyTime89 4y ago

You do realise that a lot of things happening at most companies have absolutely nothing to do with code?

lifeisstillgood 4y ago
But why not? 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.
- majormajor 4y ago
  This is how you get a "why do I have to ask on HN to get lucky to have someone at Google who knows how System X works see my post to get support on this stupid product?" reality. Inflexible machines that run on rules are not even a unique feature of software, but they are good at slowly making your customers stop liking you. 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.
  - andrewflnr 4y ago
    IMO this is truer than you may realize. The future of human work is customer service and empathy, understanding people and what they want in detail. Everything else can be automated.
  - lifeisstillgood 4y ago
    Yes. And it's not like human management does this "design a system" so well at the moment that replacing them with coders focused on explicit expressions of a process is going to be much worse. 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.

analog31 4y ago

>>>> Systems are now run by software - and the inevitable conclusion is that coders are the new managers. 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.

PicassoCTs 4y ago
Its freedom to manage yourself, if you can hack the system sufficiently enough, that it avoids interacting with you. So as strange as it sounds, if you are clever and already managing your manager, nothing changes.
waste_monk 4y ago
Reminds me of the short story Manna [1]. It gets a bit weird towards the end, but the first few chapters at least seem like a reasonable prediction of the hellscape that would result if you put a fully automated management system in charge of people. [1] https://marshallbrain.com/manna1 https://marshallbrain.com/manna1
- lifeisstillgood 4y ago
  Love that story - thank you

skeeter2020 4y ago

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