I enjoy collaborating on decisions, but only with groups that agree to use a technique I refer to as consent-based decision making. I might not use that term exactly as the coiners intended, so let me explain what I mean. I characterize consent-based decision making by putting forth a proposal, then looking for reasoned objections. When no-one raises such an objection, we accept the proposal. I find this style of decision making quicker, easier, and better for team unity than typical approaches.

Consent-based decision making contrasts sharply with a typical decision-making exercise, which tends to follow these steps:

1. Present a need or problem.
2. Present options.
3. Solicit more options from the group.
4. Discuss the merits of each option in detail.
5. Propose solutions.
6. Combine the proposed solutions into a kind of hybrid solution to which everyone can assent.
7. Ask for any last-minute objections.
8. Decide.

I feel tired trying to make decisions this way, and it seems that the fatigue rises with at least the square of the number of people involved. Not only do I find it difficult to make decisions this way, but that difficulty encourages me to exclude people who might otherwise have valuable input. It puts me in a place of wanting to prune ideas, rather than generate them. You can understand why I’d want to avoid this kind of consensus building.

Some objections

When I have taught consent-based decision making to my clients, some of them have pointed out that it leads to a particularly negative culture: “Don’t bring me problems; bring me solutions.” I agree that, practised mindlessly, that could happen, but because I insist we practise mindfully, I think we can avoid this problem. Still others have pointed out that this style of decision-making stifles creativity because it intimidates people who want to point out a flaw in a proposal without necessarily having a better proposal. Again I agree, but we can mitigate this risk by looking at one of consent-based decision making’s greatest strengths: separating generating ideas from selecting a solution.

I remember dozens of meetings in which I participated in making decisions by building consensus, specifically how inconsistently engaged I felt. I would enter some of these meetings with a desire to generate ideas, brainstorm, and explore solutions; and I would entry other of these meetings tired of sifting through ideas, craving to decide on a course of action. I can’t tell you why I felt the way I felt, but rather just that it varied, and that I felt it strongly. Sometimes I wanted to expand the solution space, and other times I wanted desperately to contract it. So far, I don’t see a problem with that, but there are, of course, other people.

When you and I enter a decision-making meeting with different goals, we create problems for each other. When you want to generate ideas and I want to select a solution, we fight for air time, for space, and indeed for life… at least, it feels that way to me. I struggle to bring us to a sensible solution, and as my wish comes close to coming true, you trample on it with yet another pie-in-the-sky idea. Worse, your idea might fit perfectly, but I simply won’t see it that way. I will interpret your every new idea as an attempt to prolong the agony, whereas you will interpret my every attempt to choose a solution as an attempt to shut you down. Result? War. Root cause? Cross purposes. Remedy? Alignment. (Surprised?)

Two goals, two meetings

Consider, instead, having two separate meetings: one to generate proposals, and one to select a proposal. You might find that that helps.

In the first meeting, we generate ideas, brainstorm, solicit opinions, run impact studies… whatever we need to do to generate proposals. The people who come to this meeting might or might not care about making the decision. Whatever happens, we can feel certain that whoever shows up wants to lend their ideas to the group, and most importantly, we ignore any attempt at choosing a solution. We agree in advance to ignore them, because we have a different goal in this meeting. We agree not to chastise people for attempting to choose a solution because they form part of our natural impulse to jump to a conclusion. We agree to recognize each other’s humanity by allowing each other to compare or rank solutions, but we generally ignore those attempts in a quiet, friendly manner. (See Ask Why, But Don’t Answer for an explanation.)

The second meeting starts with a proposal. The group may ask clarifying questions, but by now we shouldn’t need to ask too many. The Proposer than asks the group to vote, which the group does by signaling thumb up, sideways, or down. A thumb up means “I accept the proposal”. A thumb sideways means “I will go with the rest of the group”. I thumb down means “I reject the proposal”. Of course, if you reject the proposal, then you must make a counter-proposal right away, otherwise the group feels free to ignore your vote. The group repeats this process until either it makes a decision or reaches a deadlock. If it reaches a deadlock, then we immediately adjourn the meeting and schedule another one to explore the competing proposals in depth. Why schedule another meeting? In part, to discourage people from rejecting a proposal just for the sake of rejecting it, and to give those people an opportunity to sleep on it before beginning another round of brainstorming.

No silver bullet

Naturally, people could abuse this system. And yes, when we have to make particular tough decisions, this system could take longer than the consensus-building approach. Even so, for more routine decisions, consent-based decision making works more quickly and easily, and I’d rather make easy things easy and hard things possible than optimize for the hard decisions.

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 practise, 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 decreases for 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.

Saboteur? You?

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.

And then…?

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.

Some ideas simply click with you. I remember reading about “the alignment of authority and responsibility” for the first time and feeling how much that idea resonated with me.¹ I worked at IBM at the time, on the (then) Net.Commerce project, and after about a year, I began to feel some responsibility for delivering on a project plan without any authority to negotiate scope, priorities, or timing with a stakeholder. I remember clearly staring at a whiteboard that waited for me to put work estimates next to a long list of tasks. I refused to do it.

“I don’t know long it will take,” I told my manager.

“Forget about getting the numbers right. Just give me something to put in the plan.” I knew he supported me, but he needed me to understand the difficulty in his position. He felt a similar powerlessness and asked me to help him work through it. I felt quite sad about it. While his response didn’t help me in the short term, but it opened my eyes to what I now know to call Schedule Chicken. I felt truly powerless in having to make a commitment to a schedule in which I did not believe.

I had had project managers hold me to rough estimates in the past. I had read about the “best practice” called No Hallway Estimates. I felt that Management (that nebulous machine that doesn’t really exist) foisted responsibility on me without the authority I needed to accept and deliver on that responsibility.

I had had enough. I started walking up and down the halls, asking, “Why do you make me guess? I always guess wrong.” Within two years, I left IBM with serious Authority Deficit Disorder. If you find yourself in a position of having to manage people with low authority and high responsibility, then you need to know the Law of Conservation of Authority and Responsibility.

People will correct an imbalance of authority and responsibility, whether you want them to or not, and on their schedule, not yours.

Consider the case of Jane, who has spent two years suffering from Authority Deficit Disorder. If you don’t give her more authority, then she will reach her breaking point, disrupt your organization, and eventually leave. Unfortunately, if you decide to give her more authority, then she will spend about two years demanding authority without responsibility, just to compensate for her two years of Authority Deficit Disorder. She will demand it. Either way, Jane will disrupt your organization, your plans, and probably your life. You will suffer, whether you deserve it or don’t.

So the Law of Conservation of Authority and Responsibility has a corollary.

When a person suffering from Authority Deficit Disorder has reached his breaking point, nothing you do can remedy the situation, except to wait.

Jane spent two years suffering, so she probably needs two years to recover. I understand how powerless and unfair that is, but I don’t find it any less unfair than the treatment Jane endured. This leads me to conclude

When you withhold authority, but insist on responsible behavior, everyone loses.

I don’t know how to solve that problem without simply balancing authority and responsibility better.

¹ I haven’t read it, but found at least one reference to this idea in Harry Chambers and Robert Craft’s No Fear Management.

J. B. Rainsberger, “Theory of Constraints”, Agileee conference, 2009 from Alexey Krivitsky on Vimeo.

I would like to find people willing to add subtitles to this video in any language, including transcribing it in English. If you’d like to do this, then please do it! I only ask that you email me with a link to the resulting video so I can add a link from here. Thanks.

I started trying to communicate exclusively in E-Prime less than a year ago. I felt motivated to do this primarily by this claim:

The translation [into E-Prime of the sentence “the movie was good”, which could become “I liked the movie”] communicates the speaker’s subjective experience of the movie rather than the speaker’s judgment of the movie. In this example, using E-Prime makes it harder for the writer or reader to confuse a statement of opinion with a statement of fact.

This claim resonated with me for at least two reasons: I tend to judge quickly, and sometimes harshly, so I wanted to reduce the amount of judging I do; and I pride myself on distinguishing opinion from fact, so I’d like any tool that helps me do that more effectively.

Rather than reproduce a general argument about the benefit of E-Prime, I’d rather share an incident that occurred recently to illustrate how E-Prime could improve communication. Granted, each of us gets to decide what constitutes an improvement.

I had just delivered a two-hour presentation to managers on the subject of test-driven development. I spent the first hour providing the context for test-driven development, reviewing how to apply concepts from Lean manufacturing to software, but focusing on design: concepts like YAGNI, evolutionary design, writing tests first, and refactoring. I spent the second hour taking questions from the audience in batches of five and answering them quickly — about ten minutes per batch. I felt good about the session; however, one person decided to give me some feedback just before we closed.

He did an excellent job of introducing his feedback, almost as though he had recently learned some popular feedback-giving model. He said, almost verbatim:

I have a comment for you. It’s more of a Simon Cowell comment.

I told him that I felt ready to receive his comment.

The first hour was useless evangelism. The second hour was much more valuable. I wish you had run the first hour like the second hour.

If I had felt particularly insecure at that moment, I’d have likely reacted strongly and negatively. Fortunately, I felt great, so I interpreted his comment more generously. I appreciated his directness, and although I thought he used unnecessarily judgmental language, I didn’t mind that he did so in front of the rest of the group. That gave me the opportunity to ask this question.

Why didn’t you say that after ten minutes?

He realized I had made a Lean-related joke, so he smiled and shrugged, before answering that he held his tongue out of respect. I understood. I followed up by telling him that I would have found it more respectful if he had saved me from wasting 50 minutes of everyone’s time.

It turns out that few people in the audience agreed with him. At least one person emphasized on his evaluation form how valuable he found the first hour. To borrow from the writers of Frasier, that’s pretty much what I figured.

If we’d had more time, I would have taken that moment to launch into a discussion of the Satir Interaction Model, given this perfect example of an action (not interrupting me to claim I was wasting people’s time) with two diametrically opposing interpretations: paying respect by not interrupting; showing lack of respect by letting me crash and burn on stage. You can probably reduce any rocky communication to an instance of a severe difference in interpretation.

What if this person had communicated using E-Prime? How might this have played out? I offer this potential translation of my commenter’s comments into E-Prime.

I have a comment for you in the style of Simon Cowell. I found the first hour useless, as though you wanted to proselytize me. I found the second hour much more valuable. I wish you had run the first hour more like the second hour.

As I wrote this, I hesitated on translating “evangelism”. I settled on the periphrasis “you proselytized me”, which I think captures the essence of “evangelism” well. I know I could have chosen different words there. I recognize that the words I chose reflect my lingering subconscious feelings about the incident. By writing his comment this way, I better surface my interpretation of it, which I find both clearer and quite instructive. I could have translated it this way.

I have a comment for you in the style of Simon Cowell. I found the first hour useless, as though you simply wanted to evangelize about TDD. …

I react to this slightly less strongly than to the first version, but that difference doesn’t interest me much. I more care about which the commenter would have chosen: did he choose the word “evangelize” because he wanted to emphasize how I related to him, or because he wanted to emphasize my intention? I believe that knowing that would have helped save me from a harsh reaction had I received his comment from a less centered place than I happened to find myself at the time.

Communicating with E-Prime could have helped avoid a gross difference in interpretation between the commenter and I, and perhaps could do so more regularly. I count this as one of the many reasons I choose to communicate as much as I can in E-Prime.