They'd say, "We want to be this far along by July," or "By August we need to be able to handle these types of transactions." I'd ask them how they'd established

They'd say, "We want to be this far along by July," or "By August we need to be able to handle these types of transactions." I'd ask them how they'd established those deadlines. The answer was always the same: No businessperson had asked for a specific amount of progress by a specific date, but the team had decided how far along it needed to be at various checkpoints to feel good about the overall progress. It's unfortunate that the author had this awesome insight, and then went off on a tangent about people being more comfortable with schedule pressure than with quality pressure. "Feeling good about the overall progress" as presented above isn't schedule pressure, it's a measure of quality and efficiency. "We want to be this far along by July" is a way for the team themselves to gauge if, for example, they are spinning their wheels doing the wrong thing (because it's taking too long, because it's too hard, because it's not broken down into subtasks properly, whathaveyou), which directly relates to quality. As this "deadline" approaches, one can judge if with greater accuracy if it's going to be made. And since these "deadlines" are not hard and fast, or at least not as hard and fast as if some business person had set them, tweaking them is less work and less upsetting. Don't think all seven of the transaction types are going to be done by August? Scale it back to five, work on getting it into a state where these five can be handed off to the next team to work on the next part and build it such that new transaction types can be added later so more people can work in parallel. Dependency handling (with the core dependency getting the project in a shippable state within a reasonable amount of time) is the reason schedule pressure exists in the first place. I've often had to say to my team "We seem to be spending a lot of time on X, and are close to [or past] the initial estimates for completion. Are we doing the right thing here? What else are we going to have to cut? What do you want to cut? Is it too complex, and can we simplify it?". Too often, even the list of things (features) that need to be in the final product are determined externally (read: by business people), without any input from the people who are actually going to do be doing the work. The implementing team should be involved in both the feature list and the schedule (a regular topic on HN). I've been on both sides of the table too many times where there is a "technical" resource included in the scheduling planning/meetings just for show and their insight and participation is discouraged, usually because promises have already been made and the planning meeting is just a big Tetris game, an attempt to fit a bunch of lines and shapes into a fixed size box. That all being said, bluishgreen's comments about revolving around the customer are spot on too. A lot of that comes down to handling expectations. In my experience, schedule pressure is often the result of improperly used Gantt charts. Gantt charts should be living documentation used to answer questions about scheduling and dependencies, not a static bible to be used to browbeat people (both the implementors and the customer) into buying into some fantasy dates.