GROWS logo

February 19, 2019

Using time to enforce a deadline can instill a sense of urgency for teams to amp up their efforts, and managers often use this as a primary means of driving and measuring performance. But that doesn’t mean it’s the right thing to do. In fact, it is exactly the wrong thing to do.

A Quick Look at Deadlines

Many managers have a strong dependence (or reliance) on time, and often use time as a de facto management tool. It’s a topic business schools spend lots of ‘time’ on, and time is most often used to drive deadlines.

Why is this use of time the wrong thing to do? There are several reasons, including:

  • People are horrible at estimating how much time something will take, and as evidenced by just about everyone, we’re not good at predicting any remotely reasonable deadline.
  • Using a deadline as a motivational tool is a poor proxy, or substitute, for true value. Time may be a component of value as in, “if we can meet this goal by this date, we get this reward.” But as you can see, time is only one part of the value statement and doesn’t convey to the team a meaningful goal to achieve on a repeatable basis.
  • Deadlines as a management tool tend to be associated with a “fear and consequences”-based management approach. Based on research, that’s not the best way to motivate a team to be successful.
  • If you subscribe to the iron triangle of time, quality and money where you can only pick two of those items, and if, as usual, time and money (schedule and budget) are the two items chosen, you will inevitably pay a big price over the long-term. This is because each time you make that choice, you are creating more and more technical debt related to the quality shortcuts taken.
  • Working software is much more than a date. No doubt, dates can have consequences and can be important, especially in certain scenarios, but a date is just one attribute.

“The impediment to action advances action. What stands in the way becomes the way.” -Marcus Aurelius

We can easily interpret this as work or items you must deal with to get to a goal, a destination, or do a job. If the goal your team is trying to meet involves flow, or a state of continuous delivery of valuable software, you would then want an approach that minimized ceremony, overhead, obstacles or anything else that may get in the way. If you take that further, you could add artificial gates or mandates whose value is not easily understood by stakeholders and teams.

I contend that a deadline is an artificial gate whose significance often is simply to push teams to perform with little understanding of the reason why that date is important. As such, without a strong reason or understanding of why the gate is important, it loses much of its meaning with teams, and often will lead to burn out, poor performance, and an ever-increasing mountain of technical debt.

So what do you do?

The Case for Milestones

In a simpler world, delivering working software on a continuous and short cadence would suffice. It is the ideal goal. However, we do need to show teams how their work contributes to the company’s overall success (as well as proper incentives) if we want teams sufficiently motivated. A great way to do that, with minimal ceremony or overhead, is a road map with milestones that help teams and management see the progress of their product or internal software offering.

What are milestones? Milestones are demonstrated, valuable capabilities (working software) that are independent of a fixed date. A fixed date or deadline may be a consideration or have certain implications that are notable related to a milestone. For example, this could be a fine for not remedying a problem, or the promise of some business value if we beat “XYZ Corporation” to market. However, when we say milestone, we are talking about a software component that has value. A simple definition of a milestone would follow a pattern of what action is completed by the component and what value it adds. Optionally, you could add supporting information related to time if and only if its relevance is clear.

As an example, here is a milestone with a relevant time component:

  • Approval workflow-Build the Approval Workflow audit check to provide an audit trail for loan approvals. Supporting Information: If this is completed by January 1 we avoid the potential for a fine of $50,000”

Other milestone examples might be:

  • Notifications-Deliver a notifications component to provide status on active tasks
  • WebSite Purchasing-Extend online purchase options (Zelle, PayPal and Square) to increase new orders
  • Executive Dashboard-Deliver a real time dashboard (stock price, ROE, ROA and profit margin) for up-to-date performance metrics
  • Logistics Status-Deliver current logistics status to improve customer satisfaction and reduce costs

By doing so, we can provide a much more complete picture of the value of the software. Works such as “Drive” (Pink) and supporting research tell us that having a better sense of the purpose is one of the three motivators of Mastery, Autonomy and Purpose. Sense of purpose is a much better motivator than an artificial gate or deadline.

While it is much harder to take the time to lay out a road map and milestones, doing so provides a critical defense against the typical project success criteria (on time and within budget). This is due to the fact that functionality or quality is often deferred to subsequent follow-on projects. This only obfuscates the true picture of time to market and total cost of ownership that you originally expected to receive from the first project.
While the value of this approach is clear, meeting the goal isn’t easy. Historically, teams have a role of a product owner or something similar to make these decisions for them. That’s problematic as well. We see that role as a proxy and much prefer a larger body of representatives such as user groups, direct customer involvement, or committees with every group represented to help make those decisions.

This type of approach takes more coordination and likely more time to get groups working collaboratively but, in the long run, provides a much more diverse and rich perspective the team needs to ensure they are maximizing the value they deliver.

And isn’t that what we’re here to do?

Jump In

While these practices are easy to understand, they can be difficult to master. If you’re just starting out with new approaches, please take a look at our suggestions in Starting with GROWS.

For more information on these and other practices, head on over to growsmethod.com and sign up for our newsletter. Don’t worry, we won’t spam you: we’ll only send a few emails a month, and will never sell or rent your email address to any third party without your permission.

If you really want to jump start your change efforts, we offer a two-day workshop as well.

But no matter how you proceed, the important thing is to proceed. If you aren’t addressing these four key areas somehow, your team and your organization will not succeed in this rapidly changing world.

And we’d really like to see you succeed.

Thanks,

Tony


More news: ← Older |

Follow @growsmethod on Twitter, or subscribe to our mailing list:

Sign up for more information on how you can participate and use the GROWS Method™. We will not use your email for any other purpose.