That's an interesting mental model, and it has some overlap with something that's historically occurred to me about software in large corporate org charts. Scientific management/Taylorism is the basis for the modern corporation's command-and-control, pyramid-shaped org chart.
But Taylor developed this model in the late 1800s to help line managers get more productivity out of factory workers, who his system regarded as sort of a hybrid between humans and beasts of burden. It was the precursor, sorta, to industrial engineering, and a system that worked well for orchestrating brainless labor, like drilling and cutting and whatnot.
But we've retained that model for over 100+ years, and it makes a terrible system for managing knowledge workers. I once compared it to putting on a puppet show by having a marionette puppet that, in turn, operated other puppets. Or, to put it another way, building a complex human org chart to direct complex knowledge work labor of systems construction really makes no sense.
Looping back to what you're saying here, I think my view is aligned with it. Building a software system, even if it's just a single indie developer working independently, is analogous to an 1890s factory line manager's work. So layering all sorts of other, human management on top of that gets pretty weird.
There's also a concept known as Conway's Law, which more or less says that enterprises will build software that's basically an architectural representation of their software engineering org chart. As someone who has consulted on a lot of codebase/architectural assessments over the years, I can tell you there's a lot of truth to that.
Man, that is very interesting. There is a lot more connection than I had thought then. So, how do we convince founders that software engineers are actually management and get paid accordingly?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
That's an interesting mental model, and it has some overlap with something that's historically occurred to me about software in large corporate org charts. Scientific management/Taylorism is the basis for the modern corporation's command-and-control, pyramid-shaped org chart.
But Taylor developed this model in the late 1800s to help line managers get more productivity out of factory workers, who his system regarded as sort of a hybrid between humans and beasts of burden. It was the precursor, sorta, to industrial engineering, and a system that worked well for orchestrating brainless labor, like drilling and cutting and whatnot.
But we've retained that model for over 100+ years, and it makes a terrible system for managing knowledge workers. I once compared it to putting on a puppet show by having a marionette puppet that, in turn, operated other puppets. Or, to put it another way, building a complex human org chart to direct complex knowledge work labor of systems construction really makes no sense.
Looping back to what you're saying here, I think my view is aligned with it. Building a software system, even if it's just a single indie developer working independently, is analogous to an 1890s factory line manager's work. So layering all sorts of other, human management on top of that gets pretty weird.
There's also a concept known as Conway's Law, which more or less says that enterprises will build software that's basically an architectural representation of their software engineering org chart. As someone who has consulted on a lot of codebase/architectural assessments over the years, I can tell you there's a lot of truth to that.
Man, that is very interesting. There is a lot more connection than I had thought then. So, how do we convince founders that software engineers are actually management and get paid accordingly?