Hacker News Reader

This is exactly correct. We have seen “market maturity” which basically means “tech companies are now run on modern management theory” and that theory, frankly, is wrong.

Open doors, frank discussions, flat hierarchy, hacking culture, planning at the edge, and personal relationships all took a dive. Performance plans, recruiters, mid-level managers, central planning and product management overuse exploded.

Somewhere around 2014-2017 working in a tech company started to be indistinguishable from working in any other Enterprise.

Now a lot of that seems to be the result of all the pioneers leaving the industry and the settlers arriving. There was a point around 2012-13 where Ivy League grads stopped going to McKinsey and started going to the valley, and they brought all their management theory with them.

> Somewhere around 2014-2017 working in a tech company started to be indistinguishable from working in any other Enterprise.

That's because the definition changed. Silicon Valley used to be tech companies, that meant companies whose product was tech.

That's no longer the case. The so-called tech companies do not sell technology anymore. Sure they use tech internally, but that's every enterprise ever. So working at them is indeed just a boring non-tech enterprise job.

I have said similar things to a few replies but i really think it’s less simple and there being one way that works.

I’m sure the agree to disagree works sometimes but my experience is we need to trust people to do their job, and if we cannot, we need to move on without them.

This isn’t to say we will disagree and not find a way to live with it. I more mean, the ideal outcome is that the mind of developers and product staff are tightly aligned. If they’re not, that’s going to be a constant source of friction that’ll slow down everything about product development.

I personally believe (and maybe bias is showing now) that a lot of the best ideas come out of the people closest to the code. It’s often easy to spot opportunity as a developer, but we need to not discount the work good product people out into user research and market research.

Neither alone is sufficient, but the teams have to work together to get the idealized outcomes.

> One of the biggest dysfunctions in tech over the last decade has been the rise of the product role and re-subjugation of engineers.

This is absolutely correct. Although your timeline is a bit off.

In the 80s and 90s there was no such thing as a product manager. At least, I never met or heard of one. If any existed, they were rare as hens teeth.

Engineering was driven by engineering. Thus craftsmanship mattered and it was a very fulfilling job. Engineers were expected to define the product and had the authority and responsibility to do it.

The PMs started to appear in the 00s and spread like wildfire in the 2010s. Now they almost outnumber engineering. Engineers own nothing and are expected to like it.

>> youre not here to decide what problems to solve, youre here to solve the problems the product team wants solved they get all upset and moody

> Please be very up front that you hold this view when recruiting, it will be better for everyone. This may need to be an "agree to disagree" situation, but my experience goes completely the opposite direction of what you're suggesting here.

Also, there are both types of companies out there! There are places where "engineering" means "implement what the Product Manager dreams up" and other places where it means "you define the product and implementation." Find the company that works best for your expectations. Some people like having a PM do all the ideation and just sit back and program what's in the requirements doc. Others feel put in a box in that environment. Both types of companies exist.

I beg to differ, well, at least i beg to add a 3rd option. I like to subscribe to the thinking that the PM owns the decision but the best outcomes are made when they work closely with, and often take a lot of input from, the developers.

At the end of the day the reason i say i like this model is because i want ownership from a product group, and likewise no development team wants PMs prescribing to them how to structured the database or what language to choose. So ultimately, this division of responsibility is kind of a logical divide, to ensure we see where each other operates and let the developers have input but also their own area of ownership without taking away the ownership the product people bring to the table.