Endurance sports offer lessons on developing an athlete's productivity that are equally relevant to high-performance IT teams.
Believe it or not, there's an incorrect way to run. Despite nearly 9 years as a runner and lackluster endurance athlete, I recently found out that I was, indeed, doing it wrong.
For most of my running career, I've assumed that training should be all about raising my pace, and the best way to get there was to run harder. Being a gadget freak, I've had fancy GPS watches that detailed my heart rate and pace, but I wasn't correctly correlating the two, assuming that I had to work hard (a high heart rate) to achieve optimum productivity in the form of a faster pace.
An increased focus on cycling this year in preparation for triathlon season brought about this revelation. I've been following a cycling plan that focused primarily on base building, which is essentially keeping one's activity (heart rate) low, and increasing the productivity, measured in watts, that can be generated at that activity level. I've conditioned my body to produce higher results at lower activity levels, an ability that's critical for longer endurance events. I've begun to apply this same method to my running, taking runs that seem painfully slow in an effort to keep my heart rate low, while seeing dramatic increases in the pace I can produce at these lower heart rates.
With an exceptional base, an athlete can compete for hours while their body efficiently burns stored fats, versus the sugar stores that are required at higher levels of activity. Since the average human only has enough stored sugar for about 30-45 minutes of performance at this higher level, the ability to deliver high productivity at an efficient activity level is obviously valuable.
The dangers of focusing on activity
Like my misguided use of heart rate data in my previous running training, many teams focus on increasing activity to drive results, rather than improving the quality of results delivered at a sustainable activity level. Detailed project plans, task management tools, and dashboards give us the illusion of training correctly, but we're often structuring our work around increasing activity rather than increasing productivity.
Work is the ultimate endurance event. While a triathlete might compete in a 5- to 12-hour event, the average career is measured in decades. Consider your IT organization for a moment. If it's like the majority, it's been conditioned around sprinting. A firefight or development sprint results in a fury of activity, the organizational equivalent of an athlete spiking her heartbeat to the max and tenaciously hanging there until it's physically impossible to sustain that level of effort. Like the athlete, after the sprint the team usually hits a wall and performance crashes down-- employees even become physically affected by the workload.
Contrast this to the team that has trained and measured around the productivity they can produce at sustainable activity levels. There's a quiet energy and diligence, and this team can make a strategic sprint or two when the time comes, without depleting themselves and falling apart.
What's your team's watts?
The metric that has driven this revolution in cycling training is power, generally measured in watts. Power is the measure of how much force the rider is applying to the bicycle, and is independent of wind, rider size or gender, elevation of the route, or any other factor. A rider of any type who can produce 100W for an hour is more productive than another who can produce 90W, irrespective of physical condition, bicycle, or riding uphill versus downhill. Combine this measure of productivity with the standard for athletic activity in terms of heart rate, and it's easy to see how you perform at different effort levels.
In most other environments, it's difficult to find a metric as pure as power and heart rate, but they do exist. The key to increasing your team's endurance is identifying a metric that captures effort or activity, and a metric that captures productivity. In a helpdesk that might be a combination of ticket resolution time and reopen rate, while an e-commerce operation might use purchase completion rates and return rates.
Regardless of the metric, your ultimate goal should be increasing the productivity metric without increasing the corresponding activity metric. As you develop this base level of team fitness, you'll find fewer panic situations, and a team that consistently performs well over the long term, rather than a team that must resort to heroics that leave them spent and ineffective for weeks.
- Transition between IT projects like a triathlete (TechRepublic)
- How television show Shark Tank can guide your project vetting process(TechRepublic)
- Can large companies adopt the agility of startups? (TechRepublic)
- When good enough is better than perfect (TechRepublic)