When you should do nothing – maximising the performance of knowledge workers

Most of the ideas we write about are well supported by research, leaders in software development and business or at the very least are well established as best practice.  Instead today I want to write about a personal theory of mine, which is still very much developing but I think is important enough to share.

The training program for nearly any serious athlete these days is planned around the ‘season’ of their chosen sport, then their most important events and they work back from that to ensure they are in ‘peak’ condition at the most important times of the season.  As they build up to these peaks their program will push them through a series of harder and harder training sessions, building up fatigue and forcing the body to adapt to support the increased stress (essentially driven by our fight or flight reflex).

The body doesn’t get stronger during the workouts though, it’s actually being stressed and broken down during these sessions.  When an athlete stops to rest, eat and sleep the body has a chance to rebuild and adapt; because of the stress it’s been under the body adapts and prepares for the next time by building strong, faster muscles, etc.

It seems logical then that the best approach is to steadily increase the training load each session and over time get stronger and stronger and stronger.  In practice this doesn’t work. Athletes stop improving, they burn out and become injured or sick from the constant stress they are placing their bodies under.  There are two things at play here.  The first is that by training hard enough to stress their body and cause the positive adaptation they are also building up a debt of fatigue which eventually becomes too much for the body to overcome causing sickness, injury and burnout.  The second is that due to the consistent pattern of stress the body adapts, the workouts may become a little easier, but the athlete improves more and more slowly.

Enter periodisation, a process developed in the Eastern Bloc countries and now widely adopted by athletes the world over.  With periodisation a year, the macrocycle, is broken into a series of blocks, often four week mesocycles which are then composed of a number of week long microcycles.  Each mesocycle will include week long microcycles of training (increased stress), and most importantly a microcycle of recovery.  This cyclical approach allows the athlete to stress their body, but also to have periods of recovery allowing their body to reach a new peak of performance as it rebuilds and sheds fatigue.  This new peak then feeds into the next cycle, allowing them to undertake more stress, train harder and over the macrocycle increase their performance to levels unobtainable by a stead state training program.

Now let’s turn our focus to an Agile software development process; the routine and rhythms of a sprint process remind me a lot of an athlete’s training microcycle.  Week in, week out we kick off the sprint, have daily stand-ups, write code, test code and have a demo and retro at the end of the sprint.  Then next sprint we do it all again.

A common pattern I’ve observed with teams who adopt Agile is that around the 3 month mark they start to loose faith.  At the start the buzz of something new, a different way of working and the rapid feedback and transparency let the team quickly improve their performance.  But after a while the sprint to sprint performance increases slow, or even stop, and yet the team is working just as hard each sprint.  Often times the team’s performance will even drop off as they grow weary of maintaing all the habits for no noticeable improvement.

Does this sound familiar to the earlier example from the athletes?

Why are intensely focused working groups (often conducted off site from your normal office) so productive and satisfying? If it works so well why don’t we work like that every day? Why is it that often the best ideas come at unexpected times, under the shower, out for a walk or on holidays for a week or two?  Why do software developers seem to work so intensely sometimes and yet spend so much time going around and around on a problem getting nowhere, or surfing the web and staring into space ?

I think these things are just examples of accidental periodisation by knowledge workers and my theory is that the human brain is just like the human body in the way it can be trained and leveraged for maximum performance.   While ad hoc training programs can work well for athletes a structured program will nearly always deliver a better, and more importantly consistent result.  My hypothesis is that these same principles of training apply to the human brain and there are lots of practical ways to apply this for knowledge workers but I’m already overtime on this post… so I’ll save those stories for another day.