‍

This video recently came up in my LinkedIn feed, and for whatever reason it caught my eye enough to make me stop and watch. (It's a whopping 2 minutes.)

‍

‍

The point resonated with me as it's reflective of how I often find myself working. Incidentally, I was in a meeting with an advisor whom I respect greatly a couple of days after I watched the video. During this meeting, he (knowingly or unknowingly — I'm not sure) made the exact same point, emphasizing the value of dumb questions.

Don't bite your tongue.

In a work environment, we're often preoccupied with coming across as not dumb. We bite our tongues instead of asking questions when we don't understand something out of fear that we might appear less than to our colleagues and clients. The irony, of course, is that most of the time someone else in the room has the exact same question.

I'm personally a firm believer in speaking up — in asking the dumb questions. It's a simple act, but one that resonates for me because many of the projects on which I find myself working are in areas that are entirely new to me. Every time I walk into a room to kick off a project or a Design Sprint, I'm doing so as an outsider to that team's core business. My recent long-term projects have mostly delved into spaces that were entirely new to me: video delivery for artists and creators, security for physical spaces, the property titling process, and financial management have all crossed my plate, in spite of having little direct background in those areas. In those situations I have no choice: either I ask the dumb questions, or I fail.

Because of this, I've learned to use my outside perspective to my advantage. By asking dumb questions, I ensure that, as a newcomer to a particular business, I can understand a client's goals, how the organization is structured to serve those goals, and what needs aren't currently being met. I can leverage the discovery and information gathering process to help clarify pain points and to elicit clear, simple responses and explanations from people who are engrained in this work on a daily basis. By asking them questions, I encourage them to step back and examine the things they take for granted in their day-to-day. In doing so, I learn how we at Apollo 21 can help solve our clients' issues — be that through technology or otherwise.

This effort is especially poignant for companies that don't have a background or core competency in software development. The stakeholders often know that technology can help them solve a problem. They have a sense that something is possible because they've seen other software that covers similar use cases. (And let's face it, almost anything is possible these days). But they have no idea how to go from identifying the problem to creating a solution. The gap from recognizing an inefficiency to creating technology to serve that issue can be huge, especially for a team that doesn't come from the world of building software.

Once again, this is where the dumb questions come in — and lots of them. In projects that are focused on building technology to increase internal efficiency, it helps to talk with everyone I can get in front of. Creating efficiency is about streamlining processes that have touch points throughout an organization. I like to learn about those processes from the perspectives of a variety of people across the company so that I can capture a clear picture of the overall effort. And I do that by asking questions...

• Explain to me how you approach this...
• Where do you run into problems when you're doing that?
• If the platform you're using were to do this for you, would it make your life easier?

The majority of the time, folks are happy to talk — especially after they understand that your detailed questions are in the interest of helping them better accomplish their jobs.

Approaching Dumb Questions

I find that there are two ways to approach asking questions. In some cases, these approaches are interchangeable and in others one may work better than the other (particularly depending on whether you're in a tactical or strategic conversation).

Approach 1: Own the lack of understanding.

Sinek outlines this approach in the video above. A little self-deprecating humor goes a long way, "I realize I'm the only one in the room without an MBA, but could you explain this to me again?" Or, "I'm new to this line of business, so excuse me if this is obvious, but..."

This approach calls direct attention to the dumb nature of my question and allows me to own the lack of understanding outright. In doing so, my intent is to put the person I'm questioning at ease by making it clear that they're not responsible for my shortcoming in understanding. This approach works particularly well in strategic conversations where there isn't a clearly demonstrable task to examine.

Approach 2: Ask to be enlightened.

In contrast to the above, another approach is to ask for a demonstration. This approach works particularly well for tactical questions, "Could you show me how you accomplish this in your workflow?" Or, "Walk me through the steps you take to get that done." This opens the door for follow-up questions that add clarity to the demonstration.

As ideas come to mind, I'll often pepper in further questions that hint at potential solutions: "This process looks like it takes a long time. If we were to do X so that software could accomplish Y for you, would that make your day to day easier?" And this is where the magic happens. As the other person realizes that you're trying to make their job easier, they'll often open up and become an active participant in the brainstorming process. "Yes, that would be great! Could we also...?"

Embrace the dumb.

In short, if your job is to help someone else accomplish their goals — whether that's by building software or any other means — it pays to grow comfortable with not looking like you know everything. Ultimately, you'll come up with better solutions for those you're helping and likely gain their respect in the process. All it takes is learning to ignore that little voice in the back of your head that says "But what if I look dumb when I ask this?"