4 ms·

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 i

by 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
  - MarkMarine 2y ago
    Just my two cents, I don’t think that PMs or Product people don’t have a place… I really value them. I want to have collaborative discussions where I can bat the idea of what is best for the product, the long term health of the software, and the customer around… and I don’t want to do it into the mirror by myself. But I’ve got no time, not one single second for the style of PM that ungreased is advocating for. Where the PM thinks I’m some monkey they feed tickets to, pull the lever and get code from. Early in my career I’d just leave for the next better thing, now I’ll actively make sure you’re not in my org killing the culture. PMs are crap at architecture, crap at maintaining code, crap at fighting tech debt, crap at all the meta things that make software last… Honestly expectedly so. Y’all should argue for your side and have us as a counter weight… what ungreased is describing is irreparable. That’s why I said get out, but only if ungreased is actually good. Otherwise stay there. Keep making your shit devs miserable until they leave.
    - 015a 2y ago
      The way I look at it is: Software companies which lean-into rather than fight against an engineer-centric corporate architecture will be better-setup to be more productive and ship higher quality product than any other architecture. They won't always be, every company is different, but its the best starting place because at the end of the day your engineers are your bottleneck. The engineers implement asks from Product Managers, Owners, Designers, Leadership, Marketing, Sales, Customers, Vendors, other Engineers/Themselves, all of these sources of work flow downhill to engineering and need to be triaged and prioritized. So, at least for the roles engineers work most closely with (PM/PO/Designer/etc), it is productive and good that these roles are framed in the perspective that they're a service & asset role for engineering; that when engineering needs designs, they go to a designer, that when engineers need an answer to some product behavior question, they go to the PM, who would reasonably be if not the source of truth at least the authority of that domain, etc. That's only subtly different, but definitely meaningfully, than what the GP poster was saying about running the sprint board and controlling what work gets taken on; PMs/POs shouldn't have that authority, that authority lies with the EM and their discussions with the priorities of leadership. And, by the way: calling back to my previous comment, I've worked in roles where the EMs were less-technical more-product, call these companies "product led companies", and each team had almost a bi-archy of an Engineering Manager + Engineering Lead representing two sides of this coin. This works really well. If you want a product-biased company, hire product-minded managers, but give engineers a 10-20 year title track that doesn't involve management. If you want an engineering-biased company, promote or hire engineers; this can work for more hard-tech infrastructural companies. If you struggle to find great talent, hire dedicated PMs but have them report to your product or engineering-minded EMs. That's it.

by 015a 2y ago

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
- MarkMarine 2y ago
  Just my two cents, I don’t think that PMs or Product people don’t have a place… I really value them. I want to have collaborative discussions where I can bat the idea of what is best for the product, the long term health of the software, and the customer around… and I don’t want to do it into the mirror by myself. But I’ve got no time, not one single second for the style of PM that ungreased is advocating for. Where the PM thinks I’m some monkey they feed tickets to, pull the lever and get code from. Early in my career I’d just leave for the next better thing, now I’ll actively make sure you’re not in my org killing the culture. PMs are crap at architecture, crap at maintaining code, crap at fighting tech debt, crap at all the meta things that make software last… Honestly expectedly so. Y’all should argue for your side and have us as a counter weight… what ungreased is describing is irreparable. That’s why I said get out, but only if ungreased is actually good. Otherwise stay there. Keep making your shit devs miserable until they leave.
  - 015a 2y ago
    The way I look at it is: Software companies which lean-into rather than fight against an engineer-centric corporate architecture will be better-setup to be more productive and ship higher quality product than any other architecture. They won't always be, every company is different, but its the best starting place because at the end of the day your engineers are your bottleneck. The engineers implement asks from Product Managers, Owners, Designers, Leadership, Marketing, Sales, Customers, Vendors, other Engineers/Themselves, all of these sources of work flow downhill to engineering and need to be triaged and prioritized. So, at least for the roles engineers work most closely with (PM/PO/Designer/etc), it is productive and good that these roles are framed in the perspective that they're a service & asset role for engineering; that when engineering needs designs, they go to a designer, that when engineers need an answer to some product behavior question, they go to the PM, who would reasonably be if not the source of truth at least the authority of that domain, etc. That's only subtly different, but definitely meaningfully, than what the GP poster was saying about running the sprint board and controlling what work gets taken on; PMs/POs shouldn't have that authority, that authority lies with the EM and their discussions with the priorities of leadership. And, by the way: calling back to my previous comment, I've worked in roles where the EMs were less-technical more-product, call these companies "product led companies", and each team had almost a bi-archy of an Engineering Manager + Engineering Lead representing two sides of this coin. This works really well. If you want a product-biased company, hire product-minded managers, but give engineers a 10-20 year title track that doesn't involve management. If you want an engineering-biased company, promote or hire engineers; this can work for more hard-tech infrastructural companies. If you struggle to find great talent, hire dedicated PMs but have them report to your product or engineering-minded EMs. That's it.