There are two very different things to talk about here, with two very different implications for your software, but I'll admit that which way around you label them can simply be language pedantry. So for the purposes of this discourse, let's say that:
- Taking a shortcut is using your knowledge and experience in place of studying things from first principles every time.
- Cutting a corner is a compromise in quality or good practices in the place of the prudent actions otherwise required.
Both are used to speed progress through a given piece of work. Using knowledge and experience is a time to market competitive advantage gained through having talented people, compromising quality is a time to market advantage gained through process; albeit purchased at the price of later cost.
Let's talk about taking shortcuts first. When you can do this confidently it is a magical place to be. I like to hire really smart people and give them the freedom to use the experience they've gained throughout their careers to leap frog us straight over the other organisations who had to do it all from scratch, the sources of the experience I want to tap into.
Experienced people have been through years of doing everything by careful analysis and research, gradually proving out a larger and larger set of assumptions which they can build up from, and using life's great feedback loops to tune their thinking until their instinctive decisions are as a good as a noobie's 3 months of science. That's why we hire the kind of people we hire.
Having all that collective wisdom at hand and not using it is irresponsible leadership and suffocating to the innovators you should be growing. There are still times when the right thing to do is take things back to first principles and do that 3 months of science, but the beauty of experience is it also tells you when it's right to use your instincts and when it's right to figure it out.
And now cutting corners. Reducing time to market but doing something less well (sacrificing quality) or by skipping validation steps such as doing less testing (taking more risk) works in the sort term, but really just exchanges a short term temporal win for a lot more trouble later. Often more later trouble than you really think, which is why this accelerent is so frequently misused.
I say 'freqently misused' quite deliberately, because in a pragmatic real world it is not always the wrong thing to do. Occasionally it can even be the path to very big wins, when time is absolutely of the essence and every day counts materially. But it is always the wrong thing to do to unconsciously blunder into cutting corners, to not be actively managing your quality, and to incur this type of technical debt without having a credible plan to come back to fix it up before it festers too long.
If you are not grown up enough to manage the payback, then you are not grown up enough to incur the debt.
Hire people smarter than you are. Empower them to use what they know and what they've done for your benefit - that's what they want anyway - and to use their time with you to further expand their horizons. Carefully manage your quality, incur technical debt strategically, and never do it without paying it back.
You'll do a good job and everyone will have a good time, most importantly your consumers.