Maybe it's the norm, but it's a dysfunctional company if you have engineering that only cares about "doing things the right way", product that only cares about "get the next feature out as soon as possible", and corporate that just thinks "minimize software development costs". And on top of that, you have arbitrary regular deadlines that dictate the flow of work.
That points to everyone being focused on their own goals rather than working together to deliver the product that will satisfy customers the best.
I can tell from your comment that you are on the engineering side of things. Corporate should focus (among other things) on reducing COGS, product again should focus on delivering customer facing features.
The problem are timelines. We all know what technical debt is. You can cut corners and rush a feature out, however at the expense of future velocity. When engineering and product collide, engineering triangle forms and compromise has to be made. The classic triangle is defined as quality -- speed -- cost, however that is more applicable externally. Internally the compromise triangle looks more like "fixing bugs -- delivering features -- maintaining future level of bugs". The more the triangle is stretched towards "delivering features" the more maintenance suffers.
I have seen this coming from engineering far to often. Oh no, product are idiots, they do not understand importance of bug fixing, cleaning of technical debt and maintaining architecture. Believe me, they are roughly as smart as you, you are in the same broad team anyway. Where product fail is at estimation. They lack domain expertise to correctly gauge the impact of rushing a feature on future velocity. They probably understand this relationship, but they cannot quantify the effects. This is where engineering comes: to provide domain expertise.
As TFA correctly implies, product does not give a shit about architectural decisions. For all they care it can be held by either literal or metaphorical duck tape. It's the job of engineering to quantify the cost of rushed features. If engineering thinks that product are idiots for rushing n features, then either 1) engineering fails at understanding business goals or 2) engineering fails to convey impact of rushed features.
Both are communication problems. Interestingly, the onus is on management to sort internal communication out.
If my job is to prioritize work and understand all the tradeoffs involved in that work, you can be damn sure I'll go understand the tradeoffs. If Product don't understand that technical debt makes things slower, and exactly how much slower it makes them, then they aren't doing their jobs.
My current role is "Director of Product and Technology", so I have to look after both domains. I have deep knowledge in technology, but if I'm not going around the company asking other departments what the impact of the work they want is (and what happens when they don't get it), I'm just plain bad at the product side of my role.
Yeah.. I think the problem is when product dictates what is going to be implemented without asking developers if it's feasible. It happens.
At the other end of the scale there are many programmers who are in the habit of making up bullshit technical reasons why something can't (or shouldn't!) be done when the real reason is they just don't want to have to do it.
Often they'll resist doing a useful feature because it can't be done perfectly. For example we can't report browser tab memory usage because some memory is shared between tabs so the numbers wouldn't make sense. I used to do that until I had a manager that changed my view.
> I think the problem is when product dictates what is going to be implemented
I don't think of that as a problem, that's one of the primary goals of product. Problems (yuuge problems) arise when product also gets to dictate cost/timelines. Sorry, that breaks basic management principles.
> I used to do that until I had a manager that changed my view.
Small, young teams (e.g. startups) can easily do without management, because communication is unhindered and ad-hoc. The more organization expands and matures, the more communication suffers. That's the primary goal of engineering management - facilitate conversations. When I have a request that is tad too technical I always try to backtrack and ask what's the business goal. I am 99% certain "display memory usage per tab" is not the business goal. "Find resource hungry tabs" sounds like a good candidate for a business problem.
"Customers" (e.g. product) tend to be "helpful" and provide technical implementation details, diluting the business problem, while engineering tend to fixate on those implementation hints as if they were technical requirements. Ever noticed how technically inept product managers/owners sometimes tend to be good managers? Well, they are either aware of their technical ineptitude or are inept so much that they can't even express technical details and form their requirements as business questions which leaves implementation details open and allows engineering to implement things "correctly". It's magical how simply communicating on appropriate abstraction level can lead to awesome results as each team can focus on what they are strongest at.
Some of this is what stackoverflow calls an X/Y problem; someone has a problem, got halfway down a route to a solution, and now is talking to you. It can be quite difficult to dig down into what the actual original problem was, then persuade them to back up and pursue what is in your opinion a better solution.
Very briefly, I resisted implemented features that wouldn't work perfectly. The memory use example was a real one (I was working on a profiler of some complex AI hardware). My boss would say things like "can we report how much memory this operation uses", and I would say "no because some of it is shared with other operations or only live for part of the program run etc.".
He didn't really say anything to change my mind, he just kept asking for things that would be useful to customers and eventually I realised that even if we can't give an answer that makes perfect sense or doesn't work all the time, we can still do better than nothing. Very often something that is roughly right and can be shown some of the time is better than something that doesn't exist at all.
It kind of sounds obvious when I put it like this, but you'd be surprised how often you see "we can't do this very useful thing because <minor flaw that means it won't always work perfectly>".
The issue is that most people are not cross-functional thinkers. Those who are not generally fall prey to the “if you have a hammer, every problem is a nail” fallacy. Engineers want to engineer, PMs want to add features, managers want to “manage”, etc.
You don't need everyone on every team to be a cross-functional thinker, but you need the people who are working cross-functionally to actually think about the big picture and realize they're optimizing for company success and not some arbitrary, often ambiguous goal like "good engineering".
Those people that are in the decision-making process need to then communicate the result of the decision with their team, and be able to justify the decision.
But the people in cross-functional roles are still being drawn from a probability distribution in which most people are unable to think cross-functionally.
That points to everyone being focused on their own goals rather than working together to deliver the product that will satisfy customers the best.