Guns and Deadlines

Does the practice of setting hard deadlines improve the predictability of software delivery? It depends on the team.

Pros and Cons

Hard deadlines improve goal clarity and focus, so if that’s the only thing keeping you from predictable delivery, they might help. There are numerous stories of highly-skilled teams meandering along until someone came along to instill a sense of purpose and urgency. Among other things, they get the team to agree to a hard deadline.

On the other hand, predictable delivery also depends on factors such as competing priorities, competence of the team, completeness of the spec and design, production support overhead, extent of technical debt, and the reliability and availability of development infrastructure such as build pipelines and test environments. If you are deficient in these areas, hard deadlines are likely to hurt more than help.

Hard deadlines discourage change. Teams on a hard deadline will resist changes to scope agreed beforehand. You might even find it difficult to agree on swapping bits of functionality. “This will impact the date”, becomes a staple warning in every change conversation. As a result, you lose the opportunity to respond promptly to changes in the market and to release the most relevant functionality to your customers or users.

Hard deadlines also make it easy to justify cutting corners. Rash assumptions are made, code quality takes a back seat, testing is rushed, and only showstopper bugs are fixed. Usually this boomerangs in the form of incidents in production and a poor CX overall.

Self-inflicted Hard Deadlines

Not all hard deadlines come from the business. Some are self-inflicted by tech. Joel Spolsky wrote about it in 2007:

Many rookie software managers think that they can “motivate” their programmers to work faster by giving them nice, “tight” (unrealistically short) schedules. I think this kind of motivation is brain-dead...

Why do managers try this?

When the project begins, the technical managers go off, meet with the business people, and come up with a list of features they think would take about three months, but which would really take twelve. When you think of writing code without thinking about all the steps you have to take, it always seems like it will take n time, when in reality it will probably take more like 4n time. When you do a real schedule, you add up all the tasks and realize that the project is going to take much longer than originally thought. The business people are unhappy.

Inept managers try to address this by figuring out how to get people to work faster.?

What’s a Big Shot without a Moonshot

Un-self-imposed deadlines come from business leaders. Few business leaders in large organizations appreciate the problematic aspects of hard deadlines. Past performance has left them with a low opinion of their tech teams. They couldn’t care less about the counterproductive aspects of hard deadlines—all they know is that without deadlines, things will never get done. They haven’t lived in a different world and so that’s what they believe. They fight tooth and nail to preserve their privilege, nay right, to set hard deadlines for tech, often unilaterally. And the organization ends up paying the price.

Some leaders adopt OKRs because they believe it further legitimizes their right to set “stretch goals” in the form of tight hard deadlines. They might even frame it in terms of Kennedy’s 1962 moonshot speech. Today, the speech is considered to be the exemplar of a “bold push into the unknown”. That’s wrong. Kennedy did not come up with his 1969 deadline for putting a man on the moon without consulting tech. It was quite the contrary.

In the book “Good Strategy, Bad Strategy”, author Richard Rumelt shares that the moon mission had been judged feasible by a top rocket scientist. Besides, “Kennedy did much more than simply point at the objectives; he laid out the steps along the way—unmanned exploration, larger booster rockets, parallel development of liquid and solid fuel rockets, and the construction of a landing vehicle.” The author laments, “Unfortunately, since Kennedy’s time, there has been an increased penchant for defining goals that no one really knows how to achieve and pretending that they are feasible.”?

Parallels to the Gun Culture

One line of reasoning goes like this: “We can’t meet our commitments to investors unless you meet your delivery commitments.” This is flawed because the commitment to investors is in terms of business benefit, not mere product delivery. And as we saw earlier, hard deadlines actively work against iterating product delivery with feedback loops from the market and from the live product. In other words, they actively work against efforts to improve business benefits.

Nonetheless, the “investor commitment” argument is commonly offered as a justification for the right to set arbitrary deadlines.

The whole situation is a bit like the “right to bear arms” in the US. There was perhaps a time and place where it made it sense. But over time, gun culture has woven itself into the identity of certain communities. That’s truly deep rooted. It takes generations for a people to outgrow their inherited identity. Therefore, supporters of the right of bear arms cannot be swayed by arguments that it belongs to a different era, that it is counterproductive to safety in the 21st century, or that it affects the lives of school children. They must have their guns, period.

There you have it. One cohort feels violated and insecure without their right to bear arms. Another cohort feels violated and insecure without their right to set arbitrary deadlines.

Until next time, take care and prosper.

Sriram

agileorgdesign.com

Newsletter Home