Your section about the developer org chart reminded me about a half-baked theory of mine, so I might as well share here.
What if software is really a management track? Software development is kind of like building an entire shadow organization of bits and bytes, many times replicating and replacing human organizations. Every decision a developer makes changes this shadow organization.
Actual management also loves to have dozens of positions ranking all managers into a hierarchy, so it fits into my theory.
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.
Your section about the developer org chart reminded me about a half-baked theory of mine, so I might as well share here.
What if software is really a management track? Software development is kind of like building an entire shadow organization of bits and bytes, many times replicating and replacing human organizations. Every decision a developer makes changes this shadow organization.
Actual management also loves to have dozens of positions ranking all managers into a hierarchy, so it fits into my theory.
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?