Business Insight Zone

What if it’s just a mirage?

Try this on for size: Half a dozen times today, pause when you come across an assumption — yours or someone else’s — and probe it with questions like these:

• Does it really need to be that way?
• Is that really the reason?
• How do we know?
• What are the data?
• Which part of this is inference?
• . . .

This has been a long-running favorite thinking tool for me, but I was reminded of it with new force a couple of weeks ago when I read this great, short article by my friend Esther Schindler:

Fighting the Superstitions of Software Development: Questioning the Assumptions

[. . .] One of the wisest, most brilliant programmers I ever met had a team lead habit I loved. If you made a technical assertion, Mike would ask, “Is that true?” Mike didn’t ask the question to imply you were wrong; he asked, “Is that true?” to challenge your assumptions and to determine upon what data you drew your conclusions. If you said, “Yes, that’s right. Here’s why…” and made it clear your statement came from somewhere, he’d be satisfied, and you’d earn his respect.

If the programmer stuttered, “Um, I guess it’s true,” instead, more often than not the programmer headed back to his office to find out the real story. Or Mike would help the developer re-examine the assumptions being built into the software. If the assumptions made sense, fine. If not, it was an opportunity to write better code. [. . .]

Give Esther’s article a read — it’s worth your time, even if you’re not a programmer. As you take its lessons to heart, keep in mind that the point of the assumption-questioning exercise isn’t to do these three things:

1. Workplace epistemology. I’ll be the first to confess that I can get highly abstract at times. And it can be interesting to contemplate Deep Stuff as a change of pace from the go-go-go of the daily business grind. But don’t stubbornly keep your head in the clouds with philosophical questions: bring it back to the here-and-now for the sake of your teammates and your projects.
2. Arguing semantics for the sake of semantics. I hate it when someone says, “That’s just semantics” right after they’ve encountered a smart objection to something they said that was tendentious or unclear. Words matter — they matter a lot. But some people seem to relish arguing about the letter of the words at the expense of the spirit of the words. Don’t be one of them.
3. Showing others up. Do we need to spell this out? Super-programmer Mike wasn’t asking “Is that true?” because he wanted to humiliate anyone, but because he wanted to solve the problem. Go out of your way to make it clear (and to make it true) that you want to help find better answers, not tear anybody down.

If you follow Esther’s advice, and you avoid these pitfalls, you’ll uncover all sorts of fruitful avenues for improvement — for yourself, your team, your projects, and your organization.

Really.

~

(Mirage photo by Michael Gwyther-Jones.)

Category: Management, The business brain