Recently, Jim Benson asked if I could participate in an upcoming interview series on his blog called the “Modus 3-Question Series”. I unwittingly agreed. :)

Below are my answers to those interview questions.

Q1: Do deadlines empower your teams?

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, and often times 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 lead more effectively, they use a very handy (and simple) proxy for leadership…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 these teams become more order-taker and less partner 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:

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

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 explain those costs more fully 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 very 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 we try and aspire to:

• 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, and eliminate waste.
• 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. (we do more with much, much less)

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 a thoughtful reflection on the deadline based alternative – years of deadline driven management and all the dysfunction and unintended consequences it has created.