←back to thread

446 points talboren | 1 comments | | HN request time: 0s | source
Show context
ballenf ◴[] No.45039355[source]
Can someone who's worked in an org this large help me understand how this happens? They surely do testing against major browsers and saw the performance issues before releasing. Is there really someone who gave the green light?
replies(8): >>45039516 #>>45039532 #>>45039542 #>>45040310 #>>45040321 #>>45041040 #>>45041952 #>>45046169 #
whstl ◴[] No.45039516[source]
The way it works in tech today is that there are three groups:

- Project managers putting constant pressure on developers to deliver as fast as possible. It doesn't even matter if velocity will be lost in the future, or if the company might lose customers, or even if it breaks the law.

- Developers pushing back on things that can backfire and burning political capital and causing constant burnout. And when things DO backfire, the developer is to blame for letting it happen and not having pushed it more in the first place.

- Developers who learned that the only way to win is by not giving a single fuck, and just trucking on through the tasks without much thought.

This might sound highly cynical, but unfortunately this is what it has become.

Developers are way too isolated from the end result, and accountability is non-existent for PMs who isolate devs from the result, because "isolating developers" is seem as their only job.

EDIT: This is a cultural problem that can't be solved by individual contributors or by middle management without raising hell and putting a target on their backs. Only cultural change enforced by C-Levels is able to change this, but this is *not* in the interest of most CEOs or CTOs.

replies(3): >>45043290 #>>45043531 #>>45050726 #
veverkap ◴[] No.45043290[source]
This is shockingly accurate - are you a Hubber? :)
replies(2): >>45045195 #>>45049156 #
whstl ◴[] No.45045195[source]
What's that, a Github employee? Not really, I'm in an YC startup.

But I guess the problem is that every single development position has been converging into this.

The only times in my career as a developer where I was 100% happy was when there was no career PM. Sales, customers, end-users, an engineering manager, another manager, a business owner, a random employee, some rando right out the street... All of those were way better product owners than career PMs in my 25 years of experience.

This is not exactly about competence of the category, it's just about what fits and doesn't. Software development ONLY work when there is a balance of power. PMs have leverage that developers rarely have.

I come from Electrical Engineering. Engineering requires responsibility, but responsibility requires the ability to say "no". PMs, when part of a multi-disciplinary team, make this borderline impossible, and make "being an engineer" synonymous with putting a target on your back.

replies(1): >>45048782 #
bigtones ◴[] No.45048782[source]
If the PM was also an ex-developer and has both product management and development skills this happens a lot less. When the PM knows the Engineering and complexity and code debt cost of shipping a feature then they can self-triage with that additional information and choose not to send it to the developers or to consult with dev and scale it back to something more managable.

Its these professional PM's that have done nothing else other than project mangement or PMP that don't have an understanding of the long term dev. cost of features that cause these systemic issues.

replies(2): >>45049214 #>>45050161 #
1. whstl ◴[] No.45049214[source]
Yep, that works 100%.

I'm still a big believer in "separation of powers" a la Scrum.

There should be a "Product Owner" that can be anyone really, and in the other side there is a self-managed development team that doesn't include this participant. This gives the team leverage to do things their way and act as a real engineering team.

The reason scrum was killed is because of PMs trying to get themselves into those teams and hijacking the process. Developers hated "PM-based scrum", which is not really scrum at all.