I recently overheard a "startup mentor" telling a CEO that developers are very smart and sometimes persuasive, but that they don't have a clue what is going on

I recently overheard a "startup mentor" telling a CEO that developers are very smart and sometimes persuasive, but that they don't have a clue what is going on and need to be told exactly what to do. She then went on to tell the CEO that she took an intro to javascript class and she felt that doing that gave her great insight into how long things reasonably ought to take developers to finish. It's amazing that this kind of mindset exists today. While it often makes sense for startups to take on technical debt (as well as management debt and other practices that don't scale well) the issue is rarely that developers are clueless, it's that the project cycle does not include a proper accounting of tech debt and the compounding interest that it generates. The simple answer is to first establish the minimum guaranteed lifespan of the business based on funding that is guaranteed, and work backwards to determine what milestones are necessary to extend that timeline and create a profitable (or venture backed) business. If the only option is to take on technical debt, plan for when it will be paid off. I've seen many cases where an early team rallies to ship a product and takes on technical debt so that it can be viewed as having shipped successfully, only to find themselves mired in the debt a few weeks after launch, during which time they lose a lot of credibility and some may even end up burning out and quitting the team. If you are hiring junior engineers, that may mean you are taking on technical debt... maybe even architecture debt. This may be a smart decision, as long as you are aware you are doing it and have a plan to pay it back before it becomes too costly.