I really wish I'd read this 25 years ago, but probably I wouldn't have believed any of it.
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.
> 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?
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!
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.
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.
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
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".
Thats my thesis anyway