How much influence should senior engineers have on product decisions?
Posted by coushcouch@reddit | ExperiencedDevs | View on Reddit | 37 comments
Senior developers often understand system constraints and long-term technical risks better than others. At the same time, product direction usually comes from product managers or leadership. Where do you think the right balance is between engineering input and product ownership?
sippin-jesus-juice@reddit
I present facts to stakeholders and let them decide. Things such as timelines, requirements, risks, reward, etc.
I’m not a creative, I don’t particularly enjoy the product side and so I prefer letting people who know customers drive the product and I let them choose priority based off facts I present
Leading_Yoghurt_5323@reddit
they should have strong influence, but not final say… product owns the “what”, engineering owns the “how”.
Attila_22@reddit
IMO they should just provide the constraints or tradeoffs and let business/product owner decide.
In my current role as the tech lead they always ask my opinion on features before they put it on the roadmap and for any technical items I am free to suggest and as long as it’s reasonable i’ll get capacity to work on it so I feel there’s a healthy balance.
Gunny2862@reddit
Correct answer.
OkidoShigeru@reddit
Yeah the sort of Qs I normally get are things like “how feasible would this be to compete in this timeframe?”, “how many engineers do you think we need in this thing and who/when can we go wide on this?” or “can you help break down this ask into actual discrete chunks of work?”.
And yeah we are also expected to be self directed at my job, so if there are things we think would be high impact we are of course free to draft technical designs and pitch things for the roadmap, and those things are quite often incorporated sooner or later.
For context I’m a graphics programmer for a large game engine.
chikamakaleyley@reddit
Me to PM: "Just tell me what you need"
Task created, assigned, in review
Me to PM: "Hey it's in review. For the XYZ requirement you listed, it would cause this issue 123, so for right now it will by YZ - we can follow up with X."
PM: "okay thanks for letting me know ill just create the follow up ticket"
everyone is happy
nasanu@reddit
lol that's not my reality. Lets go back a month for me:
Me to PM: This design won't work, it requires users to upload an image 49 times in a row, also requires them to edit 49 images to exact dimensions and also requires them to upload a CSV with specific requirements that we don't not disclose anywhere. Nobody will be able to use this.
PM: Ok.
Me: Meets with UX and another connected PM, redesign everything to be far more UX friendly.
Me to PM: We have this design now, its better here, here and here plus I can code in 2 weeks faster.
PM: Meets with Junior. Junior says its stupid, its faster if we just don't do all of that. She can do it all herself faster.
PM to Me: We are going with the original solution and the Junior is leading it.
Me: Fine, I quit this project.
Currently: The releasee is being pushed back.
The kicker is that I told one of the higher ups all of this. But then only yesterday while talking he mentions that no, the PM could not allow me to do it my way as we don't have time... I said what are you talking about? I would have delivered weeks ago, my solution was well within deadline. Then he is just "Oh, anyway...".
chikamakaleyley@reddit
lol wait... the junior agreed to code Clickgate?
nasanu@reddit
She didn't just agree, she said my solution was bad and not needed. That was what the PM was waiting to hear, a quicker and dirtier way. I happily walked away however there are zero consequences. I can say look, deadlines have been missed and its crap. But nobody cares..
gobluedev@reddit
Not to be “that guy,” but man you sound more like a code monkey than an engineer.
To me an engineer is there to solve a problem in the most general sense. In a stricter sense, he/she is being paid to come up with simple and elegant solutions to difficult problems.
I have guys like you on my team and they drag their feet on every little thing and their output is atrocious while everyone else picks up the work and gets things done.
nasanu@reddit
No, you have nobody like me. I don't drag my feet, I am always near finished before others are started. Like the project I moved to, my bit is done as much as I can, still waiting on APIs and final design.
And did you read? The "solution" decided on was terrible and will cause issues. My design solved issues. Seriously you read 49 image uploads one after the other for a user, and you comment what you did about a solution to do it in a single click that is also faster to implement? FFS...
gobluedev@reddit
Uh huh..
nasanu@reddit
Oh goated reply. Try addressing your arrogance. Please inform us all how you know about my track record and what I have done?
chikamakaleyley@reddit
plot twist:
gobluedev is either your PM or the Junior
gobluedev@reddit
No I just work with enough people that can’t get the mission done.
chikamakaleyley@reddit
ok well, why is it okay that others have to continue to clean up after them
chikamakaleyley@reddit
definitely didn't read it
Dexterus@reddit
Dem ambition and unbeaten down ego. Reminds me of someone. I still do dumb shit but don't sell it before I know it can work.
writeahelloworld@reddit
Wow...thats just some PTSD memory coming back
chikamakaleyley@reddit
"OK here me out... what's better conversion: 1 click or 49 clicks"
chikamakaleyley@reddit
oh man, i have def been here before
now, its just awesome working with a number of folks non-eng/eng that just like... get it, because we all have years n years of finding out what works
and maybe its just the domain i'm working on right now - basically UX a/b testing - which i've actually only worked on since my last job start in Sep 2024. I honestly never thought i'd enjoy this.
chikamakaleyley@reddit
^ this saves a lot of waiting around for answers, or permission to change things
talldean@reddit
I spent the first ten years of my career not knowing what a product manager *was*.
I still believe having the product mangers and engineers as two entirely separate roles with entirely separate management is *also* a disaster.
I've found it useful for leadership to set *goals*, and the eng teams - lead by PM and SWE partnered, or just SWE if you're short on good PMs - to be the right way. The engineers should be in the room for most if not all discussions, and able to have a say, or they'll be less motivated to *do* the damn thing, which is your biggest productivity lever.
If you're in a big enough team/org, say "we have five goals this half", the engineers should often be setting at least one of those as a non-product goal, like "we fix API XYX, until it's less than half of our oncall load, because oncall load is a morale drag, and... motivation is our biggest productivity lever."
EnderWT@reddit
OP is a spam account. Posts links to random websites. Obvious slop posts with links to random websites: https://old.reddit.com/search/?q=author%3Acoushcouch&include_over_18=on&t=all&sort=new
spacemoses@reddit
It's ok now they hid their post history. /s
Nice work Reddit, real race to the bottom. This site sucks.
ternarywat@reddit
The way I like to explain it is that product managers are best when they are focused on understanding the customer and figuring out the problems that are worth solving while engineering is responsible for crafting a solution to those problems. In practice it is very much a partnership. It depends on what the product is at the end of the day. For example if it's a heavy user-facing app, like in the construction industry, then engineers are more responsible for the solution. If it's a product focused on developer tooling, then they'll have more insight into what they need and want from the product itself since they are dogfooding it every single day.
What I will say is that fundamentally it should never be an adversarial relationship. Product engineering is a partnership.
I wrote a post that touches on this topic:
https://www.buildthestage.com/who-owns-your-company-roadmap/
Visa5e@reddit
A lot, but not because of the technical side of things.
Senior engineers, IMO, should be at least as knowledgeable as their business counterparts. You can't build a good platform without a complete understanding of your product.
nasanu@reddit
I'll tell you how it works in my 25 thousand ish employee company. The business unit comes up with some idea, the PM with zero experience in app dev or design puts that into a spec. Then we implement that spec exactly.
When the spec says a user must upload a file with instructions? You just code in a file input. But what format and what instructions? Wasn't in the spec, PM refuses to do "extra" work to explain specs to users. Nobody can use the app, but the devs did the tickets so PM gets promoted. That is how it works.
How it SHOULD work?
Business or whoever comes up with ideas. They get filtered into basic bullet points and goals for actual UX and app devs to turn into actionable specs. Devs to tickets which are managed by some PM.
Isogash@reddit
Engineering extends beyond just being a code monkey, you're also a problem solver and therefore your domain of expertise extends to solving the problem itself. It's not up to you to decide what the problems are or what their priority is, that's up to the product owners.
Good engineering requires getting involved in the discovery phase of a problem, so that you can tease out the details of the actual problem itself and model solutions that will make sense for the product.
Sometimes, your company may have product designers who do some of this problem solving from a non-technical perspective i.e. coming up with UX solutions, but ultimately as an engineer you should be able to understand the product you work on and be willing to be involved in how a feature solves the given problem.
GeneralBacteria@reddit
depends on the engineer, the product, the company and the product team.
this may come as a surprise but engineers are not fungible little cookies cutters.
james__jam@reddit
Let me put it this way, if you have zero influence, they see you as a code monkey
franz_see@reddit
You should be a partner not a service provider.
Requirements roughly flow like this: idea (usually 2-3 words) -> requirements-> tickets
If you just get handed down tickets, you’re a service provider
If you want to be a partner, you need to insert yourself while requirements are being made (not after).
mad_pony@reddit
Product influence comes not from familiarity with the system. It comes from being close to customers and understanding their needs in high level picture, first of all.
DowntownLizard@reddit
The question doesn't make sense to me because it matters what senior. Some people are just senior because they are old. Some are individual skill. Some have taste and social skill.
shrubberino@reddit
Business requirements and financial restrictions will always be more imprortant than technical problems in my experience. As long as you are aware of those and stay within, ideas and suggestions are usually welcome, but the decision itself is with whoever has the responsibility for the product, so consult before decide either way. In a healthy environment good suggestions will be appreciated.
germanheller@reddit
the influence should scale with how close the decision is to implementation reality. "should we build feature X" is a product call. "can we build feature X in 2 weeks" is an engineering call. the dysfunction happens when product makes both calls and engineering just receives tickets.
best setup ive seen: engineers have veto power on timelines and architecture, product has veto power on priorities and scope. neither side gets to override the other unilaterally. in practice this means a senior engineer saying "this will take 3 months not 3 weeks because of Y" should carry the same weight as a PM saying "users dont actually want Z."
worst orgs are the ones where engineering influence is purely informal -- you can push back but only if youre loud enough or politically connected enough. that just selects for the most opinionated engineer, not the most correct one
D-Alembert@reddit
It depends on the product, but I'm my particular field ideally designers design, informed by engineers, and there are no barriers between them sharing information or advice.
There is a danger that engineers will be ignored, but there is also the danger that everyone fancies themselves a designer and that turns out badly too. A good company culture can thread that needle