If you sit in enough scope discussions – I've been in hundreds — and you don't actually care about the scope, but instead listen only to what's being said and how it is being said, a texture of sorts, you'll hear some interesting things.
At a tech-savvy agency of about a hundred and fifty people, they were scoping a some sort of application that lied between marketing and a true piece of enterprise software. The floor-to-ceiling windows showed a stunning view of the city and the ballpark. Inside, the room was sharp, confident, moving fast. And I kept hearing three letters: API. As in, "they have an API that handles that." As in, "enough, next topic."
You probably know what an API is: application programming interface, a way for two systems to talk to each other. What it also means is that a critical piece of your project lives outside your control. Built by someone else, documented by someone else, governed by rules you haven't read.
I didn't know their client. Didn't know what the application would do. But I was hearing that acronym land with the strident confidence of senior clergy trying to keep the faithful anesthetized. The soiund of a faith that nobody in the room was going to stpe up and challenge.
So I played stupid for a few minutes, throwing out little questions like: had anyone actually seen the documentation? Did anyone know who maintained it? Had anyone tested what it returned?
And then I shut up. But good questions are contagious, and others soonrealized it was okay to ask too. Pretty quickly, a quiet despair settled over the room, as increasingly the answer to each of their questions came back some version of "not much."
The senior technologist stepped up and said he'd go find out what was really happening on the client side, what kind of pedigree this thing had. Good.
But had nobody pushed, they'd have built their entire project plan on a massive invisible assumption — that three letters and a confident voice meant the hard part was solved.
API: Always Pretend Ignorance. Your last scope meeting had a moment exactly like this one. You just don't know which overly-confident answer it was.
(postscript: the senior technologist had come back and said don't worry it should be fine, he had talked to them. Many months later, the project was hung up and teetering on the edge of collapse with flames coming out of one end. It appears the API was a little bit more of a problem than they expected.)
Lunchtime at the beach in Santa Monica
One fun thing about working at RAND was that we were adjacent to Santa Monica Beach and the locker rooms in the building opened into an alley that led directly to the sand less than a block away. You would meet other RAND people there and not even know who they were, like the one I met, whose name was Jim, but I called him in my mind, "tall skinny older guy that can smash the ball down really hard… Make sure he's on my team."
Jim Dewar spent decades on a problem that sounds academic but isn't: why do smart organizations get blindsided by things they should have seen coming?
His answer was a methodology he called Assumption-Based Planning. The core move is disarmingly simple: take any existing plan and reverse-engineer the beliefs hiding inside it. Find every concrete decision, such as "we will do A, not B," and ask one question: what would need to be true about the world for this to be a smart decision?
Dewar called the most dangerous assumptions "load-bearing." The ones the entire plan depends on that are also vulnerable to failure. And the worst of those are the ones nobody in the room even recognizes as assumptions. He had a term for this: the ghost scenario. The presumed future that everyone shares without ever naming it.
If you run an agency, your planning meetings are full of ghost scenarios. "The client knows what they want." "The timeline is realistic." "They have an API that handles that." Each one is a load-bearing assumption dressed up as a fact, and each one ends a conversation that should have been the start of an inquiry.
Dewar developed a specific technique for breaking through this. He called it Rip Van Winkle: ask the room to imagine they've been asleep for twenty years and just woke up knowing nothing about the current situation. What would they need to ask? The reframing forces people to see their own certainties as contingent rather than settled.
You don't need the full methodology to use the insight. The next time someone in a planning meeting makes a confident statement and the room moves on, ask the Dewar question: what are we assuming is true right now? You'll find the room splits fast between the people who actually know and the people who were taking someone else's confidence on faith.
The deeper lesson for me came from the sharpest researcher I worked with at RAND, a man named Dick: is that expertise itself creates the blind spot. The more you know, the faster you move. And the faster you move, the less you question.
Answers feel like progress. They feel like the meeting is going well. But every answer is also the end of a line of inquiry, and if it was the wrong answer, nobody finds out until the project is already in trouble.
Dick had a line for this that changed the way I think about hiring, team composition, and every planning meeting I've sat in since.
The Afghanistan Man
From Unmanaged*, Chapter 30: "Learner, Teacher, Manager" (pp. 326–327)*
This was the moment when I translated the idea of Jim, the tall volleyball player, into Jim Dewar, thought leder, futurist. and proponent of assumption based planning. He and I both left the sand a bit early that lunchtime, to shower and try to make a 1 o'clock meeting. I wanted to be on time because I was going to finally meet Jim Dewar in person… I even walked up to the meeting room right behind him, not realizing that it was really him.
The meeting was with a visiting scholar. This guy comes into the conference room that's already filled with a dozen or so of our six-sigma researchers, and they all dive in, talking about Afghanistan. [...]
After forty minutes of dense policy and political discussion, the meeting winds down, and the guest is ushered out. The sharpest guy in the room, Dick, smiles, looks at me, the MBA monkey, and says, "What do you think, Jack? Should we hire him?"
I knew this was a test. I looked at the table, and the best I could come up with was, "I think he had a lot of answers. He seemed quite knowledgeable." Dick laughed, slapped the table, and said, "Exactly! That's why we're not going to hire him."
It made no sense to me, so I just shrugged, giving up: "Okay, I'll bite."
He replied, "Answers are the end of all learning."
He went on, now that he saw I was getting it. "He was way too much into having answers. Every time we gave him a question, he answered. If I bring up a question to you, what you should be thinking about is, 'Is that question even the right question? Or what is it that led him to ask that question? Are those things true?' And we saw none of that thinking in our guest, so he does not belong here.
We're running an organization where we get paid to think of what's not being thought about."
