Things are different now that a new company has taken over and we have a completely different system, but before that...
When we said it will take 8 weeks, nobody ever said do it in 7. Or if they did, we said, ok, we can do it in 7 if we take out this feature. Whether that's normal or not I don't know, but it sure helped things. After a while as manager/team leader, you should have a sense of how long these will take and when timelines aren't realistic. So at some point maybe you have to stick your guns? Or explain, ok, if we shorten the timeline, this and that will happen (like more bugs will require more support costing the company more in the long run, or whatever).
I got to the point where I almost never coded unless people were running behind schedule (which happened regularly but our dev cycles were more like 6 months long). We were behind schedule fairly often, too, because there were always external factors. So we regularly felt under the gun and under pressure. But again, if we weren't going to make a date we simply removed functionality. This was obviously easier when you had a 6 month release with six major features that include dozens of pieces that could be skipped if necessary.
I don't know that you could do that. But it's certainly worth considering being more forceful about your timelines and pointing out from the beginning which functionality could be skipped in order to meet an unrealistic date forced upon you. If you get that functionality done anyway then you look like heroes, and if you don't you look prescient.