To set your pace you need to take your iteration ends seriously. You want the most completed, tested, integrated, production ready software you can get each iteration. Incomplete or buggy software represents an unknown amount of future effort, so you can't measure it. If it looks like you will not be able to get everything finished by iteration end have an iteration planning meeting and re-scope the iteration to maximize your project velocity. Even if there is only one day left in the iteration it is better to get the entire team re-focused on a single completed task than many incomplete ones.
Working overtime sucks the spirit and motivation out of your team. When your team becomes tired and demoralized they will get less work done, not more, no matter how many hours are worked. Becoming over worked today steals development progress from the future. You can't make realistic plans when your team  does  more 

work this month and less next month. Instead of pushing people to do more than humanly possible use a release planning meeting to change the project scope or timing.
Fred Brooks made it clear that adding more people is also a bad idea when a project is already late. The contribution made by many new people is usually negative. Instead ramp up your development team slowly well in advance, as soon as you predict a release will be too late.
A sustainable pace helps you plan your releases and iterations and keeps you from getting into a death march. Find your team's perfect velocity that will remain consistent for the entire project. Every team is different. Demanding this team increase velocity to match that team will actually lower their velocity long term. So what ever your team's velocity is just accept it, guard it, and use it to make realistic plans.