Absolutely true that 'tight deadlines' and 'meetings' are anathema. After all you're not working if you are 'meeting'.
That said, the thing that most affects delivery schedules are communication delays between inter-dependent people or groups. I really got to appreciate this at NetApp when a project was spread across two teams, one based out of Bangalore India and the other in Sunnyvale California. The 12 hr delay that occurred during non-overlapping sleep schedules tripled the length of time the project took.
The mechanism is a variation on the makers schedule / managers schedule problem which pg discusses nicely in his essay on the topic [1]. The essence of that is that "makers" have a synchronization time, when they change gears. Think of it as a 'makers near / makers far' issue and it has properties that are remarkably similar to computer memory synchronization issues. Engineer is cranking along on some part of the project and hit a problem in some other engineers part of the system. If they can turn/walk over and start talking to them they carry their context in their heads, discuss, resolve, and keep cranking. If on the other hand the other engineer is 'far' and not immediately available, they have to stop, create an imperfect summary, message it out, and then wait. The 'far' engineer gets the message, reads the summary, then responds with questions (generally the first engineer who has the whole picture in their head leaves stuff out of the summary) and those go back, which then interrupt the first engineer in what they were now doing so they task switch back into that original problem, add additional detail to the summary and respond, maybe at that point they can pick up the phone and call (not often to India but certainly for a remote office in the same time zone that works). And the process continues. The problem gets resolved and our original engineer is off and running again. Often times people won't even really realize how much time they are spending synchronizing as opposed to working.
The more intertwined the system these folks are working on is, the more these synchronization points occur, and the more they risk slowing everything down.
So if the problem is 'things are not getting done in a timely way' and the cause is engineers being spending time being stuck waiting for some time with another engineer who knows the part of the system they are stuck on, the solution is more rapid communication between engineers. You can focus on fixing that issue. Sometimes just having an IRC channel where folks can talk is enough, sometimes you need something more. Sometimes a sync meeting is the correct answer.
That said, the thing that most affects delivery schedules are communication delays between inter-dependent people or groups. I really got to appreciate this at NetApp when a project was spread across two teams, one based out of Bangalore India and the other in Sunnyvale California. The 12 hr delay that occurred during non-overlapping sleep schedules tripled the length of time the project took.
The mechanism is a variation on the makers schedule / managers schedule problem which pg discusses nicely in his essay on the topic [1]. The essence of that is that "makers" have a synchronization time, when they change gears. Think of it as a 'makers near / makers far' issue and it has properties that are remarkably similar to computer memory synchronization issues. Engineer is cranking along on some part of the project and hit a problem in some other engineers part of the system. If they can turn/walk over and start talking to them they carry their context in their heads, discuss, resolve, and keep cranking. If on the other hand the other engineer is 'far' and not immediately available, they have to stop, create an imperfect summary, message it out, and then wait. The 'far' engineer gets the message, reads the summary, then responds with questions (generally the first engineer who has the whole picture in their head leaves stuff out of the summary) and those go back, which then interrupt the first engineer in what they were now doing so they task switch back into that original problem, add additional detail to the summary and respond, maybe at that point they can pick up the phone and call (not often to India but certainly for a remote office in the same time zone that works). And the process continues. The problem gets resolved and our original engineer is off and running again. Often times people won't even really realize how much time they are spending synchronizing as opposed to working.
The more intertwined the system these folks are working on is, the more these synchronization points occur, and the more they risk slowing everything down.
So if the problem is 'things are not getting done in a timely way' and the cause is engineers being spending time being stuck waiting for some time with another engineer who knows the part of the system they are stuck on, the solution is more rapid communication between engineers. You can focus on fixing that issue. Sometimes just having an IRC channel where folks can talk is enough, sometimes you need something more. Sometimes a sync meeting is the correct answer.
[1] http://www.paulgraham.com/makersschedule.html