The disconnect is more between long term business value, and short term benefit for the most parasitic and manipulative actors within the business.
Engineering and business value go hand-in-hand in a healthy tech/engineering business.
A business that was built on great/innovative engineering, became successful, and then got taken over by various impostors and social manipulators, who's primary goal is gaming various internal metrics for their own gain, is not a healthy business.
The goal wasn't to mock Boeing, just to point out what happens when business overrides engineering. The context is the parent post making the point that there is little business value in good engineering.
I think that’s a bit unfair. I’d say shipping a product that solves a problem is the baseline entry fee into the market, just table stakes. Profitability is determined by the machine built around the product, like the efficiency of capital deployment, the speed of distribution, the defensibility of the business model against competition, etc. The product is just one variable in a much bigger equation.
Ime, a lot of the onus falls on Engineering and Product Management failing to make a case for why certain engineering decisions (eg. Investing in continual tech debt grooming) have business value.
The point of a business is to generate revenue. The point of employees is to do work that helps generate revenue. As such, any decision needs to ensure it has a business case aligned with revenue generation.
Good engineering hygine has significant business value such as in speeding up delivery of new features as well as keeping certain customers happy, but in a lot of cases there is an inability to communicate from either direction (eg. PMs not giving Eng full visibility into business decisions, and Eng not being able to explain why certain engineering choices have business value). If you cannot communicate why this matters, you aren't going to get it prioritized.
Unsurprisingly, at big organizations, communication can take the backseat because communication is hard and at a large company, there is some amount of complacency because the product is good enough.
Edit: Unsurprisingly got downvoted.
The only reason you are employed is to make value (which generally is measured in revenue generated). You are not paid $200k-$400k TCs to write pretty or a e s t h e t i c code. You can make a case for why that matters, but if you choose to bury your head in the sand and not make that case, I have no sympathy for you.
When all leadership is asking is "what is the short term business value?", it's pointless to make that case. It's much easier to measure "yet another feature" than "fix the root causes of what makes our product subpar and slows us down". Not only that, but an incompetent engineer's "tech debt grooming" may make things worse.
I think that this may eventually become better now that there isn't so much dumb money around (no ZIRP) and with AI assistants taking on some low-effort work (enabling companies to lay off incompetent engineers). But it will take many years for companies to adapt and the transition won't be pretty.
Communication is not hard, it's very easy, but there are actors who's goal is to obfuscate communication and prevent others from participating.
At the end of the day it comes down to who the decision makers are and how they are incentivized to act. As a simple example - company X has product C, and they set a goal of increasing usage of feature F (of product C). Currently this feature F completely sucks and users don't want to use it - so the idea is to improve it and thus increase usage.
There are 2 ways of increasing usage:
1) Make the feature F more useful/better.
2) Force/push your users to use feature F, by aggressively marketing it, and pushing it within the product surfaces, making it non-optional, etc. and other dark patterns.
Option (1) is hard to do - it requires deep understanding of the product, user needs, the related tech, etc. It requires close tactical collaboration between product and engineering.
Option (2) is easy to do - it requires ~zero innovative thinking, very surface-level understanding of the problem, and relies purely on dark patterns and sketchy marketing tricks. You can almost completely ignore your engineers and any technical debt when following this approach.
If your decision makers are imposter PMs and marketing/sales people - they will almost always choose option 2. They will increase the 'apparent usage' of this feature in the short term, while reducing overall customer satisfaction increasing annoyance, and reducing the company's overall reputation. This is exactly how many 'growth' teams operate. Short term benefit/gaming of metrics for long term loss/reputational damage. Their success metrics are always short-term and linked directly to bonuses - long term effects of these kinds of strategies are ~always completely ignored.
I work for some event ticketing business and I'd sign this. My bosses want features quickly. Does not matter to them if I need extra time to make stuff secure, doesn't matter to them if it wont scale. Its about short term revenue. Can always rebuild the software to fit the next short term goal...
If you understand what are the metrics being tracked, and what are the primary goals that an initiative or product has, you can make a case.
We are an engineering discipline and engineering decisions can have revenue making implications. But it is hubris to assume why you should care about the nitty gritties of a codebase. It's the same way no one in leadership cares about the nitty-gritties of HR policies or accounting practices - people are hired to deal with the intricacies.
When I was a PM, I didn't have a difficult time making a business case for "keep the lights on" or tech debt work so long as I was able to attach tangible revenue implications (eg. X customer might churn because of subpar experience and we have both customer testimony and user stats showing that) or roadmap implications (eg. If we spend 6 months refactoring our monorepo, we can add new revenue generating modules every quarter instead of annually).
