You want to make a good investment in your people, and you know they need training, but when you invest thousands of dollars in courses without giving your people the slack they need to apply what they learn, you’re just being cruel.
Now granted, you don’t mean to act cruelly, but you have to take responsibility for the fact that when you give someone a chance to learn, but not to practice you not only waste their time, but you tear down morale. Some of your people will even interpret your move as shallow, transparent appeasement. I’ve seen it, and I’ve felt it.
Let me explain.
First, let me start with a diagram that you absolutely need to know. I didn’t invent it, and I have definitely simplified it, but I believe I’ve kept its essence intact. This diagram graphs productivity against time as we learn a new skill.
When you provide your people training, you start them off at the beginning of this graph, with whatever productivity level they have in that area. If you wanted to train your people in design techniques, or a new programming language, or a new programming platform, then you could interpret the productivity level in terms of features delivered per week. If you wanted to train your people in negotiation techniques and interpersonal communication, then you could interpret the productivity level in terms of complaints about others, fights, or the general quality of discourse you perceive in meetings and during daily work. However you choose to interpret this graph, it works out the same for just about any measure of productivity. Before training, your people find themselves at the far left, at some baseline level of productivity.
After training, your people start to incorporate what they learned into their work. As they practise, they learn to execute the new techniques correctly, with uneven results. Once they become comfortable with the basics, they exhibit some improvement, but over weeks or months, they reach the first plateau. At this point, they have learned most of what they will learn from the first set of ideas and techniques they try.
Next, they incorporate some more of what they learned into their work. This time, their productivity decreasesfor a while as the new techniques they try clash with what they already know. During this time, they don’t know which techniques work best in which situations, so sometimes they choose well, and other times they choose poorly. They generally struggle integrating the new ideas and techniques into their work. Eventually they reach a point where the new techniques begin to mesh well with what they know, they see new benefits that they didn’t see before, their confidence improves, and their productivity resumes its increase, past their previous highest level, on to higher levels than they’d experienced before. This continues until they reach the next plateau, then the cycle begins again: struggle, bottom out, improve, plateau. This cycle continues indefinitely… unless you get in their way.
I’ve seen two major categories of errors that managers make when they encourage their people to develop new skills: giving them no slack to learn, and panicking when they bottom out the first time. You might not realize you do these things, so watch for them, because I routinely see otherwise thoughtful, intelligent managers ruin potentially game-changing improvement programs by doing one of these two things. Let me clarify what I mean.
I’m going to tell you a story
I remember when I first tried to use the Getting Things Done system to manage my own work. I spent dozens of hours creating projects, contexts, and next actions. I think my first task review took an entire day, as I questioned at every step how to review tasks “correctly”. I also remember spending plenty of time learning to use first iGTD, then later OmniFocus, struggling with how to synchronize tasks with my calendar, and generally feeling my way around the system. I remember mechanically clipping parts of email into an OmniFocus task, creating a project for it, then responding to the email and marking the OmniFocus project as “completed”. I remember thinking that this couldn’t possibly improve my effectiveness, as it now takes a handful of steps simply to reply to an email, when it used to take only one. Still, I knew that unless I practised the steps, I’d never manage to execute them deftly, so I invested the time I needed to practise. For that, I needed to build some slack into my schedule.
Building slack into my schedule meant disappointing some people. It meant letting some revenue-realizing activities slip. I invoiced clients later, I paid bills slightly after they came due, and I turned down some opportunities to market myself that would surely have resulted in an increase in sales. I knew I had to do this, because if I didn’t improve how well I executed the work I needed to do, I would never clear the ever-lengthening backlog I had to complete. (Before you comment, I did consider throwing away the bottom 80% of my backlog, and could manage to throw away only about 20%. This helps you understand how far behind I fell in completing this work.) Even in a desperate situation, with wolves knocking at the door, I invested the time I needed to learn how to work more effectively, because if I hadn’t, then I would have continued struggling while even bigger, more ferocious wolves found me and knocked longer and louder.
Turning the first corner
Over several weeks, I noticed the first hint of what Getting Things Done promises: the feeling of having a trusted system that helps you ensure you do whatever you need to do. I started to see tasks show up a week after I’d added them, because they started to come due. Unfortunately, while I saw some early wins, I feel into a deeper trap: due dates. Knowing the urgency of my backlog items, I’d set tentative due dates for the vast majority of the tasks that I felt I needed to complete within two months. Naturally, since I had a blind spot for identifying all the tasks I needed to complete a project, that meant I had hundreds of tasks with due dates, averaging about fifteen per day. Every day when I looked at that list, I felt defeated, but I tried to soldier on. I fell into a rut of completing about five tasks, while deferring five more to “three days from now” (or worse, Friday) and, at the end of the day, pushing the last five to the next day. Within two weeks I went back to bed, feeling depressed about having over 40 “urgent” tasks to complete in a single day. It seemed hopeless.
At this point, I could have filed for temporal bankruptcy, abandoned Getting Things Done, thrown away the task list I’d spent dozens of hours crafting, and wallowed in my own inability to make progress on my backlog. I had some serious deadlines looming, which then passed, and I began to suffer so much from the stress of the wolves at my door that I reach my wit’s end. I could have simply quit, and for a while, I did.
Summoning the courage to try again
After a few weeks of fighting fire after fire, interspersed with hours spent in a mild vegetative state in front of the TV, I resolved to try again. I had read a great article about why high achievers procrastinate, and it resonated with me. At the same time, I ended up spending a week at my wife’s family cottage, re-reading Getting Things Done, then reading The Four Hour Work Week. Armed with more information, more ideas, and renewed enthusiasm, I cracked open OmniFocus, performed a thorough task review, threw away 90% of my due dates, and moved most of the projects into “Someday” and “Maybe” folders. This took over six hours spread over two days. After I got back to the office and resumed completing tasks, I noticed how much more I felt in control of my work. Within a month I had made more progress on my backlog than I had in at least two years. I felt better, but noticed a new problem: due dates started sneaking up on me.
Into the abyss once more
Since I had stopped setting due dates for most tasks, I found that some due dates began sneaking up on me. Some deadlines blew right past me. I felt a momentary and mild depressive state as I wondered whether I had chosen incorrectly in removing all the due dates. I read some more, thought some more, and performed another very thorough task review. After a week I decided to experiment with adding due dates only when I absolutely knew the date on which a task came due, then measure the results. I would occasionally agonize during a task review about whether I needed to put a due date on a certain task. Sometimes I decided in a few seconds, and sometimes it took me fifteen minutes, because I didn’t want to do this mindlessly. I needed to avoid falling back into the old habit of deferring tasks that had due dates, but didn’t really need doing by that date. I needed not to see 40 tasks due on a Friday ever again. I persisted and, since then, I gladly report that I get good results from my use of Getting Things Done: I still have the occasional hiccup with a due date sneaking up on me, but it happens once every couple of months. For the most part, I do what needs doing and aggressively look for ways to delegate what others could capably do for me. Services like Your Man in India and elance.com help me with that. I still have things to learn, but I’ve reached a pretty comfortable plateau where my productivity level appears to have matched my current workload.
So why did I tell you that story? I hope to demonstrate the power of having slack to apply what you learn when you learn it, and the power of not panicking when things start to go wrong. Specifically, I have this advice for you:
- If you plan to provide training to your people, you need also to provide about 20% slack time for them to practise what they learn.
- If you cannot provide your people with 20% slack time, then do not schedule any training yet. Instead, figure out how to get them the slack time they need.
- If you have currently scheduled training for your people and they won’t have the slack time they need to practise what they will learn, then balance the cost of canceling the training against the cost of getting them that slack time between now and when the training will begin.
- After your people complete their training, work with them to build a charter related to the way they will use what they learn. This consists of a time-boxed experiment with a single measure of progress and a single goal related to that measure.
- When you choose the length of time for your time-boxed experiment, make sure make it long enough to get past the first bottoming-out phase working towards the second plateau.
- When your people show that they continue to struggle even half-way through the experiment, don’t panic! Trust the system, and maintain your commitment to invest in the entire experiment. Continue to measure progress, and make sure to check in with your people frequently and regularly, but whatever you do, don’t panic.
If you’d like to learn how to help your team adopt new practices effectively, schedule a private course with J. B. During your initial conversations with him, he will walk you through chartering how your people will use what he teaches them, help you figure out how to give them the slack time they need, and even give you tips on how not to panic.
Written by: JB Rains