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.
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:
“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?
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:
Other milestone examples might be:
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 manager 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?
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
Follow @growsmethod in the Fediverse, 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.