As part of our Deadlines Interview Series, We asked Jason Montague, Director of Application Development at R.W. Baird in Milwaukee, three questions about deadlines:

Q1: Do deadlines empower your teams?

Wow. You went right for the jugular on this topic, didn’t you.

Unfortunately, the short answer is YES, I do feel deadlines empower our teams, but NOT in the way you might expect. Deadline empowerment can lead to wildly varying, primarily negative, outcomes.

To begin, most organizations don’t have a good sense of how to manage software developers or “value” in software projects. So, instead of working on a way to manage more effectively, they use a very handy (and simple) proxy…deadlines.

For most business leaders who don’t have the time, patience, or inclination to learn about software development, understanding the nature of these projects and all the variables at the disposal of project teams is daunting. In many organizations, much of the complexity is ignored, or worse, dismissed. In these organizations, software teams and their importance in the business ecosystem is marginalized and quickly become more order-takers and less partners over time.

So then, what do deadlines “empower”?

Development teams, like any team of people, are motivated intrinsically to do a good job. If “doing a good job” becomes more about WHEN you deliver over WHAT, HOW, or WHY you are delivering, then those teams will move heaven and earth to deliver ON TIME, ignoring some key concerns.

Common missing components in deadline driven projects:

(WHAT/HOW) The deep complexity and craftsmanship needed to build a sustainable, resilient, manageable product that will grow and thrive over time.
(WHY) Why are building this? Is there a better way? Can we help make this any simpler? Should we build it all? Some of it? None of it?

When teams are faced with a deadline, the typical response is to focus on the deadline and deliver (no matter what). This is definitely empowering, and seems like a reasonable arrangement, until you realize the incredible cost associated with missing the WHAT, HOW and most importantly the WHY.

(I can elucidate those costs in another post.)

Q2: Do your customers expect delivery on deadlines?

Yes they do. And sometimes it is completely rational and unavoidable. Market pressure, response to regulatory mandates, legal requirements, etc., all require rapid, time bound responses to delivery.

However, in my experience over the last 17 years in (primarily) IT shops in financial services, insurance, banking, and even packaged software products, these deadlines are largely imposed by “managers” as a proxy for leadership. Customers, and IT managers, simply don’t know what else to do.

Q3: What are you doing to meet customer expectations (in response to or in lieu of deadlines)?

We are attempting to teach a new way of working. There are a few key steps we’ve taken to help our organization realize that deadlines, although sometimes helpful, can also cause mayhem and colossal long term costs if placed in the center of our work. These costs can be predominantly avoidable.

Here are some key tenets:

Ensure your decision makers (the “business”) are engaged and partnering daily, and understand tradeoffs related to their choices. With good decision making and partnership, we tend to maximize what we don’t build.
Educate the organization on the virtues of software craftsmanship, and why high quality software is crucial to reduce costs and to go fast. Architecture is then “baked in” to the process and we find ourselves leveraging our software versus fighting it.
Teach the organization to “shrink their bets”. Massive projects take on a life of their own. And living things tend to create antibodies to change. With large projects, too much is riding on the vision, plans, and promises of the project and its stakeholders. When that happens, human nature is to “press on” and achieve project deadlines (even if the project or company is destroyed in the process).
Teach organizations that learning is the most crucial, and scarce aspect of projects, not money or capacity. With smaller deliverables, teams can learn how to deliver high quality software extremely fast, and learn a great deal along the way. Rapid learning allows teams to change course quickly and achieve stunning results in the process, without massive investment in expanded capacity.

When the above conditions are met, customer expectations move away from simplistic models where DATES are the only thing they understand, to active partnership where RESULTS and VALUE once again take center stage. It’s not that deadlines are all bad. We understand they will always have a place in our work. We simply try and make them less important in our daily lives, and treat them as exceptions rather than the rule.

When we do this effectively, we find that deadlines take their rightful place in the background of our work versus in the center of it. The transition is tough and takes time. Over the years, we have found it becoming easier and easier to implement due to years of deadline driven management and all the dysfunction and unintended consequences it creates.