There is a huge body of work on software cost and schedule estimation. At its heart, the fact is that there is always some uncertainty, which means that there is always a nonzero probability of missing the deadline (and! a nonzero probability of coming in early). When you pull a deadline in, you are increasing the probability that you will miss the deadline, and you are increasing the probability that you are going to have other problems, because you are going to demand that your people cut corners, and cutting corners ALWAYS comes back to haunt you.
If you've kept historical data on projects and costs, you can calibrate an estimator to your organization, and you are then in a position to tell the CTO "This is what our historical data indicates we can do. If you want us to pull the deadline in, we will, but understand that you are going to have to accept increased risk of a blown deadline and serious bugs in the product."
The worst case I ever saw was at General Dynamics. A failure of the software source code control system meant that a bug was inadvertently introduced. An accelerated release schedule meant that a critical test, intended to detect that specific kind of bug, did not get performed until a day or two after the release had been sent out to Edwards AFB for flight test. The test showed a safety of flight issue that could result in loss of the test airplane and/or death of the test pilot. (The test airplane cost many, many millions of dollars, far more than the production airplanes,because it was a hand-built one-of-a-kind bird. Good test pilots cost almost as much, and they are very long-lead items.) All hell broke loose.