I knew from the looks on the other committee member’s faces that I had done it again. I had thrown my idea out on the table – whole cloth – without considering for a moment the effect on my audience. It was a terrible first impression, but the damage was done. Driving home, I turned over in my mind how I could have handled it better. My car nearly left the road when a voice in my head said, “Steve, channel your inner Gandalf.”
The chapter “Queer Lodgings” from The Hobbit had popped into my head. In it, the wizard Gandalf convinces Beorn – a reclusive character – to accept a wizard, a hobbit, and no fewer than thirteen dwarves as unexpected dinner and lodging guests. He does so gradually, by telling Beorn the story of their adventures up to that point, while gradually increasing the number of characters and introducing them in pairs. It has the added effect of making their host more intrigued by their story.
It is a clever literary device and great fun to read. In real life, of course, it requires a “wizardly” presence of mind in order to pull it off. That fact notwithstanding, the concept holds value. At the same time that it introduced the change initially as a rather minor detail, it gradually wrapped the entire request in context so that agreement was all but guaranteed to a reasonable mind. The gambit had both subtlety and framing, and divided the aspects of change into “easy-to-chew” sizes.
I will in no way try to cast myself as a writer of any merit, much less one as gifted as J.R.R. Tolkien. Nevertheless, I thought it would be fun to attempt an illustration of this idea within the context of a real world business problem. What follows is an entirely fictional conversation between a consultant (our wizard), and a CIO (the bear in our story). The consultant has discovered why the CEO’s daily sales flash reports are routinely late, but he knows that the cost of mitigation is going to cause extreme heartburn on the executive floor.
“Mr. Bruins, thank you for taking the time to meet with me.”
“Ben. Please call me Ben. And tell me your name again?”
“Dan. Dan Galf. I’m a consultant with Bertram, Thomas, and William. Our firm has the contract to develop S.M.A.U.G, the data warehouse feed from your new global costing tool.
“Nice to meet you, Dan. What can I do for you?”
“Well, perhaps it’s what I can do for you. As you know, your global costing system generates tons of data every day and we’re worried about processing time. Consequently, we’ve been looking at some of your existing procedures in order to squeeze out the best performance possible.”
“Sounds reasonable. What have you found?”
“Something curious. It’s a program that runs as part of your daily overnight processing. All it does is attribute some of your store-level general ledger data, but it runs on average for five hours per night.”
“Why is it so slow?”
“That’s the curious part. It updates the records one store and one attribute at a time.”
“I’m not technical, Dan, so I don’t understand why that is bad.”
“Consider this analogy, Ben. Suppose you have a large pile of treasure dumped at one end of a football field and every night you need to move a specific cubic foot of that treasure to the other end of the field. Rather than selecting the cubic foot you need and carrying it to the other end in a bucket, you choose to move the entire pile in order to guarantee that you deliver the part that you need. Moreover, instead of using a bucket you use a teaspoon. That’s thousands of trips across the field, and most of what you’re moving is unnecessary.”
“That does seem extraordinary. What’s the reason for it?”
“None that we can figure out. We’ve even met with some of your business folks and they can think of no earthly reason for it.”
“Have you spent much time on this quest?”
“We’ve logged about thirty hours. Several of us have looked at it because we thought we were missing something at first.”
“Well, don’t waste any more time on it Dan. But thank you for bringing it to my attention.”
“Before you dismiss it, Ben, you may want to be aware that this is the reason your CEO’s daily flash reports are late.”
“It is? Are you sure?”
“Absolutely. That report suite depends on this daily re-attribution process.”
“Oh. I see. That’s different. Madeline has been beating me up about it for weeks and she can be a real dragon. My people have been telling me that it’s a hardware performance problem.”
“We can help you fix the problem, you know.”
“Really?”
“First, we need to understand the existing procedure. There are places where it just doesn’t make any sense and your business people can’t explain the business rules.”
“How long will that take?”
“It could take as few as eight hours if the business can provide answers readily. If not, it could take substantially longer.”
“I see. But once you figure that out you can fix the problem?”
“We will need to do some design work first.”
“Why?”
“The current design forces you to scan all of the records multiple times, even though you only care about 8% of them. And of that 8%, you rarely need to change more than 11% on a given day. A more efficient approach is to partition the data based on relevance. Performance will be significantly better provided that the technical challenges of breaking the data up are addressed, hence the need for good design. That’s probably between twelve and sixteen hours of effort.”
“Okay, design. And then you do the fix?”
“Yes. Writing the new code will only take a couple of days, maybe twenty hours at most. We will need to spend at least as much time testing, though.”
“Why so much?”
“This is a key procedure driving, among other things, your daily flash, right?”
“Yes.”
“And the business makes key decisions based on those reports, right?”
“I get it, Dan. So altogether you’re saying this procedure will require…let’s see…, uh ninety-four hours to fix, including time already spent.”
“Don’t forget about coding and testing the deployment code. Figure another eight hours there.”
“So, one hundred and two hours.”
“And filling out and submitting the change management forms. Another couple of hours there.”
“Anything else?”
“Another two hours to document what we did so that whoever comes after us doesn’t need to spend so much time on discovery. Maybe add another four in case we hit a goblin along the way.”
“Well, it makes sense the way you’ve laid this out, but one hundred ten hours is a lot of time to fix one procedure don’t you think?”
“It’s a complex data set and we don’t want to buy performance at the cost of accuracy. Bear in mind also the cost associated with bandwidth trolls like this.”
“Well, I’ll probably have to green light this although it exceeds my monthly maintenance budget. Let me get approval and I’ll get back to you.”
Wouldn’t it be nice if the world were a reasonable and rational place where a conversation such as the one above could possibly take place? It is not, of course, so it must remain a fictional example of how to break an idea out into its constituent elements, laying it out in pieces so that it can be assimilated gradually. Also note that in today’s world the effort would probably have been absorbed into two Agile sprints instead of being cast as a linear “waterfall” effort. Bottom line, though, if Dan had thrown the 110 hours on the table at the beginning, Ben would probably have stopped listening.
Not being wizards, it will work much better for us if we direct the process as a series of questions that lead others toward a proposed solution. Here are the five steps to the process.
- Step 1: Begin by pointing out a factual condition and then ask one or more clarifying questions. For instance, “I was looking at the third bullet point in the selection criteria. Does anyone feel that it might be worded too broadly?”
- Step 2: Ask some more specific questions to illuminate the nature of the potential problem. “The wording stipulates that our selections express the memory, values, traditions, customs or aspirations of the community. Does this mean that each of us is to apply our own understanding of what those might be or do we need a more concrete set of examples?”
- Step 3: Only after the group begins to acknowledge that an improvement might be desired can the next step be taken. Instead of proposing a solution outright, ask instead for characteristics of a solution. For instance, “What might those examples look like?”
- Step 4: Close the circle. “Where might we find that information?”
- Step 5: Finally, if your idea has not yet been suggested, make your suggestion in the form of a question. “Do you think a town hall meeting might be an appropriate venue for gathering that information?”
I am looking forward to the practical application of this refinement in my personal style. Never again do I wish to see the looks of confusion and fear on the faces of my colleagues and clients. I may even try practicing this at home when I need to introduce a new idea into our routine. Of course, my wife proofreads these musings ahead of publication so she will be on to me right away.
At this point, my readers may be wondering why I am offering advice on something I have never tried, practiced, or been successful with before. I am not offering advice. I am offering a way of thinking about our lives when we find ourselves yanked from our comfortable mental hobbit holes to face unpleasantness in the form of our own weaknesses (I mean, opportunities for improvement). So follow along. The truth and the growth – as well as the adventure – is in the journey, not the destination. Just ask Bilbo.
What techniques do you use for creating buy-in for new ideas? Do you think self-awareness is overrated?
