alt Hacker NewsIme, 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.
Replies
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...
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.