Anyone who works with me for a short period of time will hear this tumble out of my mouth. I can’t tell you the number of times someone launches into a 5-10 minute explanation of a really cool concept and giving me that “I have a cunning plan” look when they finish. However, because I didn’t have that one thing in my head they figured was obvious, I end up having to ask a couple questions to get myself on the same page. It’s never a big deal to fill in those gaps and the opposite party is usually happy to provide the context, but I do have to ask those questions.
Assumption: The Mother of all Screwups
The problem is with assumptions. Whenever we communicate with each other, we have to make an assumption about what the other person knows. Unfortunately, a lot of times those assumptions are wrong. Remember the ill-fated Mars orbiter where there was a mixup between the imperial and metric measurement systems? While we all smack our forehead and say “D’OH”, it’s pretty obvious that this is the result of one side making assumptions about the other side’s knowledge. If someone had questioned the basic assumptions of both sides, they might have saved that $125 million orbiter, but instead, the two teams ran off on different tracks because they didn’t want to appear dumb. (How how do they look now, right?)
I know we all get frustrated when the Level 1 support tech asks us if our network cable is plugged in or that we haven’t kicked out the power cable, but these are exactly the kind of questions we need to ask when troubleshooting database problems or building requirements for a project. The reason for this is because asking the dumb questions helps establish a baseline starting point for figuring out the problem. After all, when someone comes to us saying “the system is slow”, we don’t want to bash our heads with IO stats or memory pressure when all we had to do was deal with one blocking query. We wouldn’t know about that unless we asked the right questions to start our troubleshooting.
So tell me a little about yourself
The best approach is to dealing with this is to teach yourself to reduce the number of assumptions you make. Easier said than done, right? What really helped me was an exercise a former boss/mentor had me do early on in my career. It’s pretty simple: In one paragraph (no real limit on sentences or words), describe your work to someone who has no idea what you do.
Seems easy at first, but think about it for a second. Let’s break down the following sentence that I might use:
“I administer and maintain SQL Server databases.”
Already in this sentence we have several assumptions about the listener. First, that they know what a database is, and they know what maintenance and administration is for SQL Server. Chances are most folks don’t, so we would then have to explain those terms to them in a way they would understand. We don’t need to get overly complex, but provide the listener a basic grasp of what we’re talking about.
The end result is that this exercise puts us in the mindset of someone who may not have the same knowledge or experience as we have, thus getting us to restructure our thinking and presentation in a way that covers the entire context of whatever idea we’re presenting. It also gets us to start evaluating our assumptions based on our audience. We’re always going to make assumptions, but what we want to do is make them in the context of our audience. Speaking to a group of DBAs? Yeah, leave out that stuff about relational theory. Talking with IT infrastructure dudes? Chat with them a bit about database file layouts and managing I/O contention. Oh, monkeys from Kenya? Throw ’em a couple of bananas.
Duh!
So whether we’re asking ourselves or someone talking to us, it’s always good to get those assumptions straight. Sure, we all pride ourselves on figuring things out. That’s why we’re in this business, for the joy of solving that process that no one else could. But it never helps us when we get lost on that wild goose chase because we made the wrong assumption. Save yourself some time and a lot of headache, make sure you’re on the same page with those you work with, and ask some “dumb” questions. It never hurts.