I don’t know, I’ve mostly followed this approach over my 20 year career, but it really depends on your surroundings, and honestly hasn’t led to great success.
E.g. If you’re surrounded by yes men who will code whatever without question, product people greatly prefer that, and you end up sidelined.
There’s also plenty of companies who don’t want engineers getting involved with decisions, and product and UX people work upfront and in isolation until you’re handed tiny Jira tickets with Figma mockups attached. Discussion at that point is considered “disruptive“.
It honestly seems like this has gotten worse in the past 5 to 10 years.
> E.g. If you’re surrounded by yes men who will code whatever without question, product people greatly prefer that, and you end up sidelined.
I'm amazed at how non-obvious this seems to most engineers and how often this angst gets repeated in online tech communities. I mean, when I was in academia there was a tension between publishing impactful results or cozying up with the right professors into the right conferences vs outputting meaningful work (pressures into p-hacking or having big names author suspicious results is par for the course.) In industry it's the tension between product folks and engineers. Have you ever talked to high-level finance folks who deal with the tension of product folks just wanting to do things and finance folks who remind them how money works?
It turns out that the hardest thing about getting things done with people is... dealing with people. I wish there was a way to remove this weird somewhat-ascetic blockage found in tech communities about this. Many of the more physical engineering occupations have to deal with this in the form of contractors and supervisors. Wait until you have to work on a government contract lol.
When I mentor junior engineers with these feelings, I like to use an adage: "Where there are people there are politics." Look at pretty much any prominent FOSS project and you'll see tons of it (by dint of transparency) and those folks generally focus on the project and not a product!
I can see this in academia, because you're working on reputation as much as anything, if not more so, sorta prone to being like this in a way.
Finance however, not once[0] have I either observed nor heard of someone working in finance being overruled by a product person. If finance says no go its no go, simple as that. People tend to listen to the money folks, even at a high-level.
[0]: I work both in fintech and have lots of professional colleagues that work at other financial firms from big banks to all manner of investment firms and much in-between, as well as several generations of family who have all worked in finance on various levels. Honestly, its high level finance people trying to pressure others into getting things done faster when they want something done, not the other way around.
> Finance however, not once[0] have I either observed nor heard of someone working in finance being overruled by a product person. If finance says no go its no go, simple as that. People tend to listen to the money folks, even at a high-level.
Totally, but finance people want to see the company succeed too, and even if finance says it's a no-go, product people will still keep trying to push around them. I just mean that this tension exists between different stakeholders in every organization. If we knew ways out of this, we'd revolutionize government bureaucracies, vastly increase firm efficiencies, sort out FOSS issues, the world would be our oyster! But human coordination problems are really hard. The hardest problems out there really. That's my general point. Too much airtime is given to tech people who seem to not understand this. It's a bit like complaining that when I jump I fall down. I also can't imagine spending 20 years bemoaning this aspect of human nature.
The real human element that I've observed, having been both in management and as an IC, and more broadly from research I've done as a whole, is that ENG is often the profit driver but has the least amount of say in their own workload.
I think this is where the tension comes from in the lasting, I'm still complaining about 20 years later sorta thing. Once you realize the value you are delivering to the company, naturally, you start to want to have some more say over the value chain, I think this is innante to human behavior, but there is alot of gates between ENG and the rest of the org, most of the time, from what I've observed.
Look at, for example, how "Agile" is implemented at a company. It focuses on ENG having to address stakeholders, without really saying that ENG should be its own stakeholder too. With SCRUM and other systems, the emphasis tends to be on outside stakeholders and what they want, rather than bringing ENG to parity with other stakeholders so everyone has more equal input on the work streams - which ultimately, when this is actually done, prevents more problems than it creates, nearly every time - yet you can feel the resistance in most orgs to giving ENG a full table stake
> note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of developer
> sad but true: learn "yes" then learn blame other grugs when fail, ideal career advice
> but grug must to grug be true, and "no" is magic grug word. Hard say at first, especially if you nice grug and don't like disappoint people (many such grugs!) but easier over time even though shiney rock pile not as high as might otherwise be
> is ok: how many shiney rock grug really need anyway?
It has, because embracing agile as it was laid out in 12 principles put too much power in these "technical" people by giving them a stake at the table, to anyone who doesn't work in an ENG first / ENG focused company.
If you look at how "Agile" is implemented in most organizations - even in technology companies! - there's alot of barrier process put up to sideline / minimize engineering input by focusing on stakeholders where stakeholder is defined by everyone telling engineering what to do as opposed to engineering being seen as a valid and reasonable stakeholder too.
I think its because in part there is a linear pipeline that the non technical business side sees as how things go: you plan X, it gets designed by Y, and then "manufactured" by engineers, if you will.
Engineers - good ones, in my estimation - want more stake in each step, both in planning and design, because often its engineers that work on the system the closest (you'd be shocked how many designers don't use their own products on a daily basis, same goes for alot of business oriented folks) and this is not "the way the world works".
So let others add ideas to the backlog and the product owners triage? I would be worried about ideas getting drowned, leading to a disincentive in participation. I would probably add a layer of voting or something to allow good ideas to surface.
I meant that product still writes the high level user stories, but eng figures out the solution along side UX, product, etc. Not handed broken down tasks and mockups first.
E.g. If you’re surrounded by yes men who will code whatever without question, product people greatly prefer that, and you end up sidelined.
There’s also plenty of companies who don’t want engineers getting involved with decisions, and product and UX people work upfront and in isolation until you’re handed tiny Jira tickets with Figma mockups attached. Discussion at that point is considered “disruptive“.
It honestly seems like this has gotten worse in the past 5 to 10 years.