I help people deal with fear when I coach people, teams, and organizations. All coaches do this. In particular, I encounter decision-makers afraid to take some of my advice, for a variety of reasons:
- There’s a lot to do, and we don’t have time. (Have you read chapter 6 of Planning Extreme Programming?)
- What you suggest sounds difficult, and I don’t think we can do it well.
- What you suggest changes everything, and I don’t know where I will stand afterwards.
I often deal with this problem with a relatively simple working session that often takes less than an hour. If you like it, then please try this at work.
I recently described this to a friend and colleague who reported trouble with a client resisting his advice regarding emergent architecture. I had suggested that he throw some keywords into Google and start reading, when he replied that he tried that, spent considerable time, found conflicting information, and didn’t know which authors to trust. He needed something that would open his client’s eyes to what’s possible. I wrote him this:
That’s the problem your interlocutor probably has: “I am unsure whom to trust.” Data will not help. In that position, your interlocutor will probably trust the people who agree with the position he already has in his head and not trust the people who don’t agree with the position he already has in his head.
As to opening his eyes to what’s possible, I doubt anything will impress him, although I’d enjoy his proving me wrong on that. I anticipate a lot of “Yes, but…” followed by a lengthy explanation of why that won’t work in his context.
I suggested saying something like this to his client:
I understand that the idea of letting architecture emerge sounds scary. I happen to think it’s just as scary to try to get it right years in advance. I can make some guesses about what scares you about this, but I’d rather you tell me. What’s one thing that scares you about trying intentional, guided emergent design…?
I play a little game with the client’s answers. I write each fear down on a card, then after he has finished telling me what worries him, I pick a card at random and ask the client: “What can I do to alleviate this fear?” I suggest things. I try to talk about concrete issues. I pull out information about his context. I learn about him, his situation, and his fear. I write my suggestions down on cards: “Try TDD”, “Get some C++ training”, “Run a Product Sashimi session with five key customers”, “Reorganize department X into feature teams”, “Run Open Space days once per month”. After an hour or so, we have a list of ideas on cards. Each of these ideas addresses one of his stated fears, concerns, anxieties. When there’s nothing more to explore, I look at the cards and group them like this:
No Obstacles: Just Do It
These are the cards that you can deal with starting today, if you want. You have the authority to do these things, there are no technical obstacles, you simply need to learn to do them and choose to do them.
Obstacles You Can Overcome: Do It This Year
These are the cards that you could deal with starting today, if you did one or two other things first. You might need to seize the authority, but you think you can. You might have some technical obstacles, but you have the skill to overcome them. You simply need to commit to doing them, then start chipping away at them.
Obstacles You Don’t Yet Know How To Overcome: Five-Year Plan
These are the cards that probably involve larger-scale cultural change or learning transformative skills. You don’t know how to solve these problems yet, so you need help: hired guns, books, training, advice, whatever. You might find something here that you have energy to explore, but for the rest, you probably need to show some results from Groups 1 and 2 before you’ll dive into Group 3. When you’re ready, I have some ideas for you on where to start.
The Big Question
Finally, I ask the big question. Even if you never end up doing intentional, guided emergent design, which of these cards look like things you’d like to do or think need doing?
- Dale Emery’s model of motivation, which I use frequently. Dale makes me look like a genius with this one.
- Planning Extreme Programming, which remains a classic.
* The title is a joke that comes from my days at IBM. My then manager, Tack Tong, told me that in order to have my patent applications taken seriously, I needed the title to be something like “System and Method to…” and use the term “apparatus” a lot. I miss Tack.