I agree with this as well. Around 50 people (maybe even 40) companies are required to start operating in a more bureaucratic way, and more often than not this means there's a top-down approach where software developers are just doing what they're told rather than influencing what gets built.
I think Paul Graham has an excellent article named Hacker and Painter regarding this. I think the only way is to develop your own products.
So far I habe worked in a few companies as a business analyst and a bi developer but I have never seen one that allows the dev team to have some final say in the products. Products are always dictated by business team, then project manager or business analyst breaks them down to tickets that you guus understand, i. e. the scope. The lead further breaks them dowm into sprints and tickets.
So you can see that sometimes even product managers don't have much a say in the product.
Currently working at PostHog, an engineering-centric product-led startup (20-odd people currently) all our engineering teams fully own an aspect of the product and prioritize themselves. Obviously there's company-wide context and company leadership has crucial input, but since hiring optimizes for maximally self-sufficient people, there's no PMs. I'm a big fan of that as an engineer
Sorry I have never seen one such place. I mean for sure in each place I stayed (custom service center, gaming and one I can't say), the eng team has SOME say in the product, but most od the time it's just small details of the design or something similar that they can argue about. Actually data analysts have a lot more say because they have the data to back them up when they want to make recommendations.
Never that simple at a macro level. Business will claim more knowledge of the “market” and are probably right if they have got feedback from customers. “We need to build X as part of our strategy”
Sure you can choose to use nodejs instead of ruby or embed video instead of streaming it yourself or find a better confit system than admin pages but the entire product ideas are probably decided by the business well in advance of when the developer gets whiff of it.
Imagine you are about to purchase a car and the car dealer weirdly tries to convince you to take up cycling via “what’s the problem”. You’d probably walk to the next dealer as you’ve made up your mind you want a car.
Maybe it's more of a startup thing. Another startup I worked at turned their entire website into an SPA over the course of 12 months. The website was never broken. It wasn't sleek but it worked. I kept my head down and rewrote it.
The email order confirmations, however, took 30 minutes to be delivered to customers. In the end, it was this uncertainty of whether an order went through that killed the customers trust, not the fact that it was not an SPA. I wish I had asked more questions instead of blindly following orders.
Haha. Yes, I do that potentially a bit too much. It always feels like pulling teeth -- like the official process doesn't have room for that kind of back and forth. For example, in scrum, the product owner is meant to have that conversation, not the engineers.
I have worked with 3 types of PMs during my time as an engineer as well as a lead.
1. The one who tries to reinvent the product and you tend to end up questioning their design or product decisions because they seem flaky and makes no sense. Being a newly promoted lead with my own ideas I was often at loggerheads with them. For anyone who reads this and is in the same position, I would suggest to continue building what the PM asks you to do. Any opposition or pushback you create regarding their choices will just lead to chaos for your team and in the end you would have to go with it since their role is the one making such decisions.
2. The one whose requirement are empty shells waiting to be filled with the questions raising by the people they present it to. I would suggest to get away as far as possible since your requirements will never remain fixed as the PM will be open to suggestions and influences from all over the company and you would end up with a rube goldberg machine.
3. PMs who take time to do research, write down solid requirements, convince stakeholders and also have a iteration based release plan in mind. I worked with only 2-3 PMs like this and based on what I saw, they tend to burn out faster than you do and either quit or regress to type 1 or type 2 just to get the release out.
Having said all this, I would rather be happier working with solid requirements rather than making them. I have played the role of a PM temporarily and found that it is generally a thankless job, regardless of the effort you put in.
I do too. There is something about building your own idea that’s magic. Even partially magic is given the “we need an x” but deciding on the technical and visual design. Team work is probably more effective here: graphic designer. UX, product managers etc. at producing the polished results we expect in the 2020s but man … why are we drawn to side projects? The urge to build from the ground up is strong.
Hell yes. After 20 or more years doing this, you build a reasonable bullshit filter. A lot of the time, if the ask doesn’t pass that filter I find it very, very hard to commit. It’s hard enough being useful without that. Life is too short to be wasting it on building something you know is d destined for the bin.
I think the majority (80% I’d guess) prefer to have the requirements come from someone else. To be honest I’ve worked with many people who would always say there isn’t enough ‘design’, as if the classes and methods should be written out for them and do as little thinking as possible.
third option is to go and work somewhere that builds software that helps people make product decisions - think a Dovetail, Figma, Atlassian etc. Your perspective will make you an effective engineering leader!