Deadlines are a ubiquitous tool in the business world. Something that a team can focus on and strive towards.
KPIs, OKRs, and other goal-setting, progress-measuring systems are put in place at personal, team, divisional, and company levels. If done right, they can clarify objectives and form part of a continuous improvement process, or "Kaizen".
But setting "challenging" short-term deadlines for your software team often devastates its productivity.
Long-term objectives are all well and good, but in my experience, having short-term hard deadlines where certain pieces of work must be complete is unnecessary micro-management that very quickly reduces a team's velocity.
Why? Because there's no way of speeding up without cutting corners.
Any piece of work will take as long as it takes to do a proper job, and developers are already working as hard as they can. So, in the incredibly rare instances where all work has been analysed perfectly, you will get away with it. But, any miscalculation in time required means either working overtime (in which case an unhappy team and poorer quality code are a certainty), or developers need to save time.
So, how do you save time?
Write less (or no) unit tests.
Just blast out some substandard code without refactoring.
Don't even think about the application architecture. You haven't got time.
Don't ask for a code review. Nobody else has got any time either.
You might get away with this in the very short-term (the next release or two), but all of the above will result in either (or both of):
An increase in bugs, each of which needs to go through the whole develop, test, and release cycle. This is a massive waste of time and resources that could have been spent on developing features.
An increase in the complexity of the codebase. Every bit of rushed or poorly architected code increases the difficulty level of developing on that codebase. It takes more time to read, understand, and add to.
Most deadlines can be converted to goals. A marker to head towards.
Obviously, deadlines exist in the real world. Teams need to co-ordinate their releases, and marketing needs to know when to start banging the drum. But, developers know how to write code in such a way as to maximise the long-term velocity (which is what really matters), and should be given the space and the autonomy to do so.