A protocol for asking and answering questions, gathering information, and getting to the best decisions faster.
The SOLID principles of object oriented design, includes a principle that’s often overlooked in application and library design, which is the “Open/Closed Principle“. The basic premise is that you should design systems and organize classes in such a way that your system is “Open to extension, but Closed to modification” – that is, you add functionality by adding new code, not by modifying existing code.
But that’s not really what I want to talk about today. I want to talk about how to apply that same idea to communication, with my Open/Closed Principle, which is this – “Ask open-ended questions, give closed, concrete answers.”
In consulting and software development, we spend our day doing one of two things – we’re either gathering information, or we’re acting on that information. That’s either by building applications, or by communicating with other humans beings. It’s very rare that any of us can get by without interacting with other people, be it teammates or clients, to deliver on our own commitments. In the course of those interactions, at some point, we’re going to need to extract some information from those other people. Our first instinct, right out the gate is to ask the most targeted, specific questions possible:
- Anybody know a good example of adding an extension method to Int32?
- What’s the latest version of Automapper?
- What’s the password to the production database?
- Anyone have experience with RPG III on an AS/400?
- Will feature HS-102 be done by Friday morning?
- And so on.
That last one is the most extreme version, what I call a “Binary” question – it only has two possible answers: “yes” and “no.”
Here’s the thing about closed/binary questions like those above – the form of the question implies, to its audience, that there is a right answer.
We’ve all been trained since school that having the right answer is a virtue. And human beings generally want to be helpful. So, our natural urge is to jump in and provide an answer to the question as given. When it’s a question that requires a commitment from us, we often double down on the desire and give the answer that’s “right” – as in, “Yes, absolutely, that feature will be done by Friday morning” instead of the answer that’s “true” – “Given our progress to date, I don’t see any way to have that done by Friday.”
When we ask closed/binary questions, we get incomplete, closed/binary answers.
Asking open questions is a skill. It takes practice. “Open” here doesn’t mean “directionless,” it means “open to the full answer.” Getting a full answer starts with asking a full question. For example, instead of “will it be done on Friday” you might frame it like this:
“I’m sure you all know that we have our regular feature demo on Friday with Joe, and HS-102 is the most important feature we’re targeting for this release, and it’s definitely the most important to Joe’s boss, Chris. He’s mentioned to me several times how excited he is to see it. So, my question is, what do you need that you don’t have right now to be able to deliver that by Friday morning?”
This is more than just a question. It’s the start of a conversation. In this form, rather than just collecting tactical information, you’ve provided context, and aligned everyone around a common purpose. Also, you’ve taken the question from closed – “will it be done by Friday,” to open “how could we get it done by Friday.” This invites the other party to think through how to meet the goal at hand, rather than worry about whether they’re giving you a “right” answer.
Something else that asking open questions like that does is it gives the other party full ownership over the answer and the outcome.
Open Questions are:
When we ask open, full questions, we invite others into a collaborative problem-solving experience.
Reversing a Closed Questions
When faced with a closed question, one of the best things you can do is a “reverse” – in its most basic form, the reverse is “Why do you ask?” The goal is to get the asker to back up and give you more context about what they’re after. our human nature makes us want to jump in and provide that “right” answer. But the best answer is going to require more backstory. I call it “The question behind the question.” Reversals can be tricky, and if you’re not careful they can come off as too confrontational.
One way you could reverse “Will HS-102 be done by Friday” might be “Right now I don’t see a clear path to that happening. But I assume you must be asking that question for a reason. Can you tell me more about the situation, and let’s figure out what we could do to address your need?”
The Closed Answer
When, as the party being asked, you’re presented with a good, open question, how do you answer? This is the other side of Open/Closed Principle – “ask open questions, give closed answers.” In other words, give as specific and complete an answer as possible.
“Well to deliver that feature, people on this team are going to need to write better code.” – that’s a vague, open answer. Nobody can act on that.
“The biggest challenge we’ve had with that feature is that QA has been finding an average of 3 defects per submission, and the number hasn’t been declining. The source of bugs has moved down from UI layer to back end code, so it looks to be a systemic quality issue. We’ve got one more QA round before Friday. So, I’ve gathered up all their existing defect reports, and I’d like Brandon’s help reviewing them to see if we can find a single root cause. We’re going to do that this morning. In case that doesn’t yield anything, if two of us could volunteer to do a pre-submission run through of all the existing QA test cases for that feature, that’ll give us time internally to respond to any discoveries so we can have them fixed by Thursday. Emmanuel’s the primary author of that feature, so in addition to him doing his own test development, it’d be valuable for Sharon, as tech lead, to review his dev plan prior to him getting started, and then also check in mid-day on his progress. If she wrote some of the core unit tests while he’s doing the implementation, that’ll help us catch any issues sooner as well. That plan ought to put us on track to close out that feature.”
Closed answers are:
When we provide closed, concrete answers, we make it possible for others to rally around a plan and see their part in it.
Permissive Reader, Strict Writer
Writing this reminded me of another programming concept that feel analogous – which is the Permissive Reader/Strict Writer guideline.
That is, if you’re consuming data, be flexible about what you will accept. Recognize that not everyone is going to conform perfectly to every aspect of a data specification or file format. Allow for some variation, especially known variations from specific sources. This will make it possible for you to handle data from lots of sources.
On the other hand, when producing data, be as spec-conforming as possible. Don’t deviate from the spec. Make your output flawless. This will make it possible for your data to be handled by as many other systems as possible.
Asking Open Questions is like being a Permissive Reader – it maximizes your opportunity to take in information and act on it. Giving Closed Answers is like being a Strict Writer – it maximizes your opportunity to provide information for someone else to act on.
In dealing with teammates or with clients, frame your questions in open forms – remember to make your questions Conversational, Context-rich, and Collaborative. When asked a question, make sure you’re hearing an open question. If not, reverse it, and get to the “Question behind the question.”
Then, be sure to give a closed answer – Comprehensive, Specific, and Actionable. When you ask open-ended questions, and give closed, concrete answers, you maximize the opportunity to share information and get not just the right answer, but the best result – which is what we’re really after, after all!