4 ms·

I hear that you want to be empowered, but you want the people around you not to be. Understanding why you think your role should be empowered (ultimately respo

I hear that you want to be empowered, but you want the people around you not to be. Understanding why you think your role should be empowered (ultimately responsible for the product) and the benefits it brings is _exactly_ why the people around you should be empowered as well. It sounds to me like you’ve never been in the software businesses where true creation is happening and you’re in the world of pseudo contractors or explicit contractor arrangements. All I can say is there is a much better world, you should change your attitude and hustle to get there.

bitwize 2y ago
Programmers should not be empowered to perform roles for which they are an ill fit. In general, programmers are detailists who speak the language of the computer; they do not have a big-picture perspective nor do they understand the problem in business terms. Their social skills are very often lacking, and they are prone to arrogance. In a high-functioning information systems organization, the programmer's job is one of simple translation from specifications into code; those specifications will have been produced via stepwise refinement by systems analysts who do understand the business and the people within it. See the late Tim Bryce's Theory P essay: https://www.phmainstreet.com/mba/ss050117.pdf https://www.phmainstreet.com/mba/ss050117.pdf and note that he uses the exact same "artists vs. house painters" analogy. Before his retirement Tim had been managing large software projects since before much of Hackernews was born, and had forgotten more than most internet commenters know about what it takes to manage a successful project. The "software businesses where true creation is happening" are few and far between -- Apple, maybe Google at its peak, and a handful of others. They are run by geniuses, typically from top-tier schools like MIT and Stanford. They are not the typical software organization. The typical software organization produces the software that keeps civilization humming -- and doing that is a proven, teachable, scientific process. Lately we've seen many organizations that should be doing this instead cosplaying as a bunch of genius disruptors, but they have nowhere near the brainpower to actually pull it off, and the world has gone to hell in a handbasket as a result.
- vkou 2y ago
  Blaming enshittification, rent-seeking and blatant conflicts of interest on... SWEs with overly high opinions of their business acumen is certainly a bold claim.
- ryandrake 2y ago
  > Programmers should not be empowered to perform roles for which they are an ill fit. In general, programmers are detailists who speak the language of the computer; they do not have a big-picture perspective nor do they understand the problem in business terms. Their social skills are very often lacking, and they are prone to arrogance. This seems like a problem that can be solved during hiring. These are not necessarily attributes of programmers in general, maybe just the ones you are finding. I've worked at companies where Product and Engineering roles were separate, and information had to pass between the two in the form of docs, conversations, specs, charts and so on. I've also worked at companies where there was no dedicated product role: Engineering was responsible for the implementation, the design, the product-market fit, the customer need, everything. Honestly I think that way works better, because there is no necessary back-and-forth negotiation about priorities, features, and quality (except what goes on in the tech lead's own mind). No need to have some separate person go talk to the customer and deliver requirements to engineering on a platter. It's much more efficient. You just need to hire the engineers who are not just ticket-implementors, but who can also do the product and business work.
  - intelVISA 2y ago
    > Engineering was responsible for the implementation, the design, the product-market fit, the customer need, everything. I generally agree but it's a tough sell hiring talented people as effectively one man startups with no equity. Plus, without UBI it's not fair to remove so much organizational padding: getting paid to decorate JIRA boards may not bring any value but it keeps someone's family fed.
- throw49sjwo1 2y ago
  That's why I don't work with programmers in this capacity, programming is the simple part. I work with software engineers, and the best of them probably didn't even open an IDE this week yet. I don't need them to code, I need them to tell the programmers what and how to code.
honestAbe22 2y ago
[dead]
015a 2y ago
Second, 100%. That's exactly what I'm reading as well, its why POs/PMs get a bad rep, its representative of the worst POs/PMs I've worked with, and frankly it is virally toxic. If you view your product development as a factory floor, your product will be a mass manufactured cookie cutter widget. That's how it works, and it does work for, say, cars. But the software business isn't like the car business. Its startlingly winner takes all. Atlassian builds a better, more efficient widget factory than you do for tasking software, and they eat the tasking software market, and they shoot tendrils out into other markets, and soon your business is dead.
- ungreased0675 2y ago
  Explain the toxic piece a little more for me. Why do you see that? And I think a lot of software IS mass produced cookie cutter widgets. Especially in the SaaS space. The truly special stuff is only a small percentage of the total product.
  - 015a 2y ago
    For starters: The old notion that engineers aren't good with people so don't let them talk to stakeholders [1]; so you end up with PMs/POs/EMs holding a monopoly on information gathering from stakeholders, which is at-best inefficient and more realistically less accurate. It becomes "viral" (it spreads) when it becomes institutionalized; when leaders say "no we want you focused on the code, so go into the basement and we'll talk in our 1-1 about your progress". People skills are a skill; its right there in the name, it needs to be developed and exercised. If you don't let your engineers out of the basement, you get engineers with bad people skills, and the prophecy writes itself. Those engineers with bad people skills prioritize the skills they have in themselves when hiring others, and so on, and so forth. This isn't me arguing that these PM/EM/PO roles shouldn't exist, to be clear; its more-so things that bad individuals in those roles may do. That being said, I do feel that the healthiest, most productive software teams I've been on had a few things in common: Less technical EMs, combination EM+PMs, or sharing a PM across multiple related teams in the same department. [1] https://www.youtube.com/watch?v=hNuu9CpdjIo https://www.youtube.com/watch?v=hNuu9CpdjIo

bitwize 2y ago

Programmers should not be empowered to perform roles for which they are an ill fit. In general, programmers are detailists who speak the language of the computer; they do not have a big-picture perspective nor do they understand the problem in business terms. Their social skills are very often lacking, and they are prone to arrogance. In a high-functioning information systems organization, the programmer's job is one of simple translation from specifications into code; those specifications will have been produced via stepwise refinement by systems analysts who do understand the business and the people within it. See the late Tim Bryce's Theory P essay: https://www.phmainstreet.com/mba/ss050117.pdf https://www.phmainstreet.com/mba/ss050117.pdf and note that he uses the exact same "artists vs. house painters" analogy. Before his retirement Tim had been managing large software projects since before much of Hackernews was born, and had forgotten more than most internet commenters know about what it takes to manage a successful project. The "software businesses where true creation is happening" are few and far between -- Apple, maybe Google at its peak, and a handful of others. They are run by geniuses, typically from top-tier schools like MIT and Stanford. They are not the typical software organization. The typical software organization produces the software that keeps civilization humming -- and doing that is a proven, teachable, scientific process. Lately we've seen many organizations that should be doing this instead cosplaying as a bunch of genius disruptors, but they have nowhere near the brainpower to actually pull it off, and the world has gone to hell in a handbasket as a result.

vkou 2y ago
Blaming enshittification, rent-seeking and blatant conflicts of interest on... SWEs with overly high opinions of their business acumen is certainly a bold claim.
ryandrake 2y ago
> Programmers should not be empowered to perform roles for which they are an ill fit. In general, programmers are detailists who speak the language of the computer; they do not have a big-picture perspective nor do they understand the problem in business terms. Their social skills are very often lacking, and they are prone to arrogance. This seems like a problem that can be solved during hiring. These are not necessarily attributes of programmers in general, maybe just the ones you are finding. I've worked at companies where Product and Engineering roles were separate, and information had to pass between the two in the form of docs, conversations, specs, charts and so on. I've also worked at companies where there was no dedicated product role: Engineering was responsible for the implementation, the design, the product-market fit, the customer need, everything. Honestly I think that way works better, because there is no necessary back-and-forth negotiation about priorities, features, and quality (except what goes on in the tech lead's own mind). No need to have some separate person go talk to the customer and deliver requirements to engineering on a platter. It's much more efficient. You just need to hire the engineers who are not just ticket-implementors, but who can also do the product and business work.
- intelVISA 2y ago
  > Engineering was responsible for the implementation, the design, the product-market fit, the customer need, everything. I generally agree but it's a tough sell hiring talented people as effectively one man startups with no equity. Plus, without UBI it's not fair to remove so much organizational padding: getting paid to decorate JIRA boards may not bring any value but it keeps someone's family fed.
throw49sjwo1 2y ago
That's why I don't work with programmers in this capacity, programming is the simple part. I work with software engineers, and the best of them probably didn't even open an IDE this week yet. I don't need them to code, I need them to tell the programmers what and how to code.

honestAbe22 2y ago

[dead]

015a 2y ago

Second, 100%. That's exactly what I'm reading as well, its why POs/PMs get a bad rep, its representative of the worst POs/PMs I've worked with, and frankly it is virally toxic. If you view your product development as a factory floor, your product will be a mass manufactured cookie cutter widget. That's how it works, and it does work for, say, cars. But the software business isn't like the car business. Its startlingly winner takes all. Atlassian builds a better, more efficient widget factory than you do for tasking software, and they eat the tasking software market, and they shoot tendrils out into other markets, and soon your business is dead.

ungreased0675 2y ago
Explain the toxic piece a little more for me. Why do you see that? And I think a lot of software IS mass produced cookie cutter widgets. Especially in the SaaS space. The truly special stuff is only a small percentage of the total product.
- 015a 2y ago
  For starters: The old notion that engineers aren't good with people so don't let them talk to stakeholders [1]; so you end up with PMs/POs/EMs holding a monopoly on information gathering from stakeholders, which is at-best inefficient and more realistically less accurate. It becomes "viral" (it spreads) when it becomes institutionalized; when leaders say "no we want you focused on the code, so go into the basement and we'll talk in our 1-1 about your progress". People skills are a skill; its right there in the name, it needs to be developed and exercised. If you don't let your engineers out of the basement, you get engineers with bad people skills, and the prophecy writes itself. Those engineers with bad people skills prioritize the skills they have in themselves when hiring others, and so on, and so forth. This isn't me arguing that these PM/EM/PO roles shouldn't exist, to be clear; its more-so things that bad individuals in those roles may do. That being said, I do feel that the healthiest, most productive software teams I've been on had a few things in common: Less technical EMs, combination EM+PMs, or sharing a PM across multiple related teams in the same department. [1] https://www.youtube.com/watch?v=hNuu9CpdjIo https://www.youtube.com/watch?v=hNuu9CpdjIo