Ask the Dumb Question First

A few years ago I stopped a team in the middle of an architecture review to ask what a Lambda was. I already had a rough idea what a Lambda was.

They were walking me through a SaaS build on AWS – we'll build this Lambda, then this other service, then this – and I said let's pause for a second, can you explain that to me, I'm not familiar with it. Which was mostly true. I'm not a software developer and my understanding was vague enough that the question was honest. But I'd have asked it either way.

So they backed up and defined it. Then I said, okay, let me make sure I've got this: you're going to build a Lambda to do this specific thing, and that's what we'd use it for. Yes, that's right. Cool.

Then I asked why that was the right approach, and what the alternatives were, and what else we might consider. Why this one.

We talked it through for a while, and their answer was good – the Lambda was the right call. But that same team, in that same period, was reaching for a database structure that wasn't right at all, and they were reaching for it because it was what they'd always worked with. That one we caught the same way.

The ladder is the whole trick

None of that was improvised. I use a framework out of instructional design called Bloom's Taxonomy, which maps levels of cognitive complexity you can walk someone through to build real understanding.

The bottom level is remember – vocabulary, definitions, do you know what these words mean. Above that is understand and apply: can you grasp the concept well enough to use it on something you actually need to do. Above that, analyze and evaluate – can you hold several options side by side, compare them, and decide which one is right. And at the top is create, taking everything underneath it and building something that didn't exist before.

I'm not at the create level for anybody's architecture. That's not my job and I'd be bad at it. But I can absolutely walk a team from remember up to analyze and evaluate, and that's where the decisions we actually care about get made.

The reason to start at the bottom is that it changes what the question means. If I skip the ladder and open with "why are you doing it that way," I've asked them to justify themselves. It doesn't sound like curiosity. It sounds like I don't trust them, and depending on the day it sounds like I'm building a case.

If I come in at the definition level and work up, the words coming out of my mouth are "help me understand your thinking." The end result is identical – they reflect on the decision, we sometimes land somewhere better – but it happens as something we're doing together instead of something I'm doing to them. Same challenge. Different door.

There's a side benefit, too: in most meetings, somebody else in the room also didn't know and wasn't going to say so.

You already know how to do this

You run user research this way, or you've at least watched somebody good do it.

You would never sit down with a customer and open with "why did you do that?" You ask them to walk you through it. You ask what they were trying to get done. You let them narrate, and the narration surfaces the thing you were actually after, and they never feel cross-examined. That discipline is already yours.

Bloom's Taxonomy is that same instinct pointed at your own engineers. You're not learning a new skill; you're aiming an old one at a group you'd stopped thinking of as people who need to be understood rather than convinced.

What makes it hard has nothing to do with the framework. It's that asking the basic question requires enough security in your own identity that you genuinely don't mind if someone in the room is thinking why is he asking that? You have to be okay looking like the person who doesn't know. In my experience the people who can do that get the most out of a room, and the people who can't spend a lot of energy protecting a position nobody was attacking.

The cost of skipping this is quiet. Teams get stuck in understand-and-apply. They've got a hammer that has worked before, so everything gets treated as a nail, and they apply and apply and apply and nobody stops to ask whether this one is really a nail. That's how the database decision almost happened. Not incompetence – habit, which is harder to see and much more common.

This has been useful to me at every stage of my career, and I think it's especially worth having early. If you're a few months into product management or software development, keep the shape of it in your head: remember, then understand and apply, then analyze and evaluate. Work up one rung at a time. It gives you a structured way to learn, and it builds trust with your team while you're doing it, which is not a small side effect.

The alternative to asking the basic question isn't asking a smarter one. It's staying quiet, which is the only move in this whole thing that guarantees nobody learns anything.