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.

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.

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

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.

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.

I don’t think I made that argument. I’m advocating for focus from the engineers. Focus on architecture, code quality, tech debt, etc.

Focus on that stuff also means NOT having engineers doing other things, like sitting in a booth at a conference, playing with color schemes in Figma, creating financial projections for a new feature, etc, etc.

Engineers should do what they’re good at, and POs should do what they’re good at. Side quests are fun, but don’t help the business work efficiently.

Maybe, just maybe, you're mixing cause and effect.

If you treat developers like house painters, they will not give you more. They will build the spec that you give them, and hold their tongues when they know it's a bad user experience.

If you treat developers like co-creators, and hire explicitly, and you put them in the same room with customers, you get a group thinking about how to solve a problem that your users have. They may be able to deliver something quicker, or develop a better customer experience, or question assumptions that lead to a better product.

An empowered engineer will be able to ask, "but what about how this user uses the software? Will this work for them?" And they become great at that by getting experience doing this - it's a skill, not an inborn talent.

Precisely, I've worked at a couple of places where software developers were treated like assembly line workers who convert tickets into code, and on one occasion I was even told that it wasn't my job to ask questions designed to improve my big-picture understanding of the problem, use-cases, etc.

I feel like the "programmers only care about code" trope is perpetuated by people who aren't good at sharing knowledge, or who lack intimate understanding of their customers' needs themselves and have to resort to pointing fingers.

Some programmers are like that, certainly, but if most developers one comes across are like that then one might have to look inwards.

Tangent: There's a Star Trek clip I wish I could find online so I'd have it on-hand to show non-technical people. It's from the 90s, in an episode of Deep Space Nine.

Worf (in Security) is having trouble dealing with Engineering, and O'Brien gives him some advice, something along the lines of "Engineers like to solve problems. Instead of telling them what to do, tell them what you need and let them figure it out.". Then later when he tries it out, they come up with a solution he wouldn't have thought of.

> In a high-functioning information systems organization, the programmer's job is one of simple translation from specifications into code;

That's not a job, that's a tool, and it's called a transpiler.

A "high functioning organization" fitting your description wouldn't need to have any salaried programmers after they created that simple specification-to-code compiler.

> Their social skills are very often lacking, and they are prone to arrogance

Unlike your own comment which displays these exact qualities?

> 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

“Programmers” are not, software developers/software engineers, who are more like systems analysts than programmers in scope of job role at the full working level, though generally employed in organizations that do not also employ separate programmers, however, are and should be.

The kind of organization with wide organization/and interaction distance between users and people working on code with large numbers of over-the-wall handoffs in between is obsolete in many areas of software development because of advances in tooling, because of recognition of the quality costs imposed by that structure given the dynamics of many application domains where whiteboard analysis without real active use is not effective in getting accurate requirements, and because of the costs of that organization style which has long cycle times and high coordination overhead.

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.

I think programmer vs software engineer is one of those semantic things that might sound witty but ultimately has little utility or shared agreement. Job listings use them interchangeably. I call myself a programmer in casual conversation because it's easier and I'd feel kind of pompous saying "software engineer", even though I'm firmly on the "software engineer" side at this point.

And it sounds a little incredulous for even a senior architect to go an entire week without opening an IDE. I'd be worried I'm working under someone out of touch, too far removed from the actualization of software. Isn't that how we got the EnterpriseBeanFactoryFactory stereotype? The best team leads and architects I know still spend a lot of their time coding. One famous example is Carmack.

> And it sounds a little incredulous for even a senior architect to go an entire week without opening an IDE.

Not really. I'm at least two levels below that and about a month ago I spent 3 days straight building a document and diagrams to convince an architect that recently joined our team that one of his plans for us was bad. (Part of the reason it took so long because I had to straighten out some thoughts and figure out how to organize years of experience that has just been building in my head over time, plus come up with alternate plans that were a better way of getting to a similar-but-not-quite-the-same end goal)

I don't remember what I was doing before and after that but it wouldn't surprise me if I hadn't touched any code for over a week.

On the flipside since then I've been deep into code, doing some re-architecting of our development stack to make it easier to work with.

Basically there's just no consistency day-to-day.

It was meant to be mostly a joke, I agree it's vague and I do the same as you do. Though the point stands - very senior or principal engineers/developers/architects are not there to write code.

A team lead should be hands on, I agree. But there are also technical people who operate above teams and even above departments - those probably don't code much. Most of their time is probably spent in business/strategy meetings and writing stuff in Jira and Confluence.

A principal engineer can be on the same hierarchy/influence level as a very senior manager or director, leading hundreds of people.

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

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

You’re on hackernews, not an MBA roundtable. Lot of people here have been at Apple (like me), Google (at its peak in your opinion or now) and let me queue you in on something… the leaders at Google, Apple, etc that you’re lionizing spoke about their developers the way I am. Maybe that is the gap between the typical org and the great ones

Blaming enshittification, rent-seeking and blatant conflicts of interest on... SWEs with overly high opinions of their business acumen is certainly a bold claim.