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.

That is, until planes fall from the sky.

It's popular to mock aerospace engineering, but it's usually quite robust. Even if people still sometimes make bad decisions.

And move slowly. So when things turn bad, they will be bad for a decade - or more. See Boeing.

Boeings (software) issues stem from a removal of their Engineering skillset and replacing it with an outsourcing model don't they?

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.

Ah, I see where you're coming from. I've been hearing a lot of people talk poorly of aerospace as a whole recently, due to some Boeing issues, and I misread your comment as such. Apologies and thanks.

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.

Only if there are is organizational disconnect… which is the norm.

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.

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.

The point of a business is to generate profit.

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).

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.

I think AI will make it worse since it will allow the incompetent engineers to do much more harm.

In the short term, definitely.

In the long term, once the damage from vibecoding is better understood (for customer impact and team morale), there's an incentive to push them out, both from the leadership and the individuals side.

Well maybe you get hit with the gray arrows because you first make a sweeping generalization and then say "I have no sympathy for you". Food for thought?

I have communicated the business value in addressing tech debt, as in I have pointed out how many critical customer features got delayed by it and we churn customers we really can't afford to.

Still got overruled. The tech lead stepped in and threw his weight around with zero explanation to the CTO or the CEO. Who needs to hear what the engineers on the ground have to say, right? They cannot communicate!

Man, tearing down strawmen is easy. You should do better and see nuance. A lot of engineers communicate very well and are still ignored.

I think we are both operating on our priors. At least here in the Bay Area, those kinds of workplaces don't survive over the long term due to their incompetence and toxicity dragging down execution. I can't speak for where you might be.

* Product folks over-promise

* Engineers are consulted for estimates to facilitate long-term planning

* Middle management slashes those estimates in half due to pathological myopia

* Executives enforce musical chairs to assert their authority

* Consultants muck everything up while collecting enormous payouts

And yet the business cycle keeps cycling.