One thing I've had a lot of success with as I help early to mid stage (usually YC) startups try to tune things is empowering engineering by giving bizdev and st

One thing I've had a lot of success with as I help early to mid stage (usually YC) startups try to tune things is empowering engineering by giving bizdev and stakeholders the understanding and expectation that ~25% of eng's time should be spent on things like writing tests, refactoring, and otherwise reducing tech debt. Putting a focus on reducing tech debt up front via CI, automated testing (including both unit and integration tests), coding style guidelines, CI checks for all of the above, etc., and giving engineering the time to attend to these issues and practices has turned around many flailing or failing startups that I've consulted with and/or provided advice to. The ones that do fail are usually the ones that resist addressing tech debt in favor of shipping more features. In truth, it is usually quite possible to do both at the same time, and it is in the very least possible to tackle new features in a way that doesn't increase tech debt at the previous bad rate through updated automated testing and CI requirements that ensure new features are fully tested before they are merged. The hardest thing, especially with non-technical founders, is getting them to understand that yes, their precious features need to be pushed back a bit, but that this will prevent major issues, downtime, and slowdowns next quarter or next year, and that issues they are experiencing now are often due to neglecting tech debt in the past. Once they get this, the company usually has a much better outlook. This is also an investing criteria (what is your ongoing plan to reduce technical debt) for some of the better tech investors, I've heard.