Sometimes, in a big project, it's OK to take a shortcut: the work might not hold up, you might have to redo it, but that's OK, because there are more pressing things to get done right now. You've traded time tomorrow to get back some time today.

Sometimes shortcuts are a good idea, other times they aren't—that's a judgment call.

What's never a good idea is stupidity: doing something incorrectly that saves no time.

Using a flathead driver to turn a Phillips-head screw when you don't have a Phillips driver is a shortcut; it's not ideal, but might save a trip to the hardware store. Using a screwdriver to set a nail when you have a hammer is stupidity; it saves no time and you'll probably break the screwdriver in the process.

What's tricky is telling them apart. Experience helps.

When it comes to software, too much of what we call "technical debt" is stupidity, not shortcuts. We think we're saving time, "moving fast and breaking things", when in reality we're all a bunch of ignorant slobs, Stack Overflowing our way through Python directory layouts, until we can pass the whole mess off to the next guy. And the cycle repeats.

I think this is a failure of middle management. It's not realistic to expect every CEO to be a coder. But great software companies have what I'd call a "guild culture" internally: they manage to give credit equally to the flashy v1 demos, and the tough maintenance slogs. The starters, and the finishers.