[nostrademons]

There are two sides to this:

On one hand, good management should realize that automating repetitive tasks and paying down technical debt is how you add to a tech company's capital stock, and is the only reason why tech company valuations tend to go parabolic. If you're just trading money for labor and labor for customer's money, you have a consulting service business. These can be profitable, but you don't build an enduring asset this way, and the valuations that business owners usually think about when they decide to start a tech company are those that come from owning a monopoly asset that you can sell to multiple customers for virtually no additional cost.

On the other hand, the part that engineers are usually blind to is the business context that the company operates in. Tech moves fast. It's not uncommon for basically all of a company's founding assumptions to be obsolete 3 years later. New tech platforms are available; customers want different things; a new competitor has just demoed a killer feature. All of these have the possibility to render large swaths of a product's feature set obsolete. There's no sense investing engineering time in a codebase that's about to be killed anyway; just rack up the technical debt and declare bankruptcy. Worse, management often can't tell engineering about many of these external realities without killing the product: would you continue working for a company that said "Our competitive position is untenable. Pump out as many features before anyone external notices so we can sell the company" or "We need you to keep the lights on for our existing customers while this secret division over there builds the next generation of the product"?

It's often good to ask questions about the company's overall strategy and competitive position (and to do research on this yourself) before joining. While the owners usually won't tell you everything, it'll build trust if they can tell you some things. They should be able to think of these issues in terms of trade-offs: "What's technical debt?" is the wrong answer, but so is "We care deeply about technical debt and give our engineers as much time as they want for code cleanup" (the latter is a bullshit answer, designed to make the hire). Similarly, it builds trust if engineers can also recognize the business tradeoffs and accept that sometimes the right answer is to hack something together and ship it so the customers can get value while management figures out the next strategic move.