Not all questions are created equal.
Recently, some discourse has been happening in my early career program around finding our voice, participating in meetings, and asking questions. This tends to be harder for early-career people for a multitude of reasons. I think a common denominator for a lot of the reasons comes down to self-limiting beliefs and fear.
Separately, I’ve been subscribed to a couple of developer-focused newsletters, and there’s been a recurring theme around ‘just asking’ and all the benefits that come with it. While I agree, and there are innumerable benefits to asking more questions, I think there is an important caveat worth considering. That is the concept that not all questions are created equal.
Understanding when, where, what, and to whom to direct questions is an important skill to develop. It is powerful for your own growth and being a solid contributor on a team. I will go into a few simple tips I have learned along the way, with some gems from teammates who have a lot more experience than me.
Do the work before you ask.
Before bringing a question to a teammate or into a meeting, I first try to find the answer myself and exhaust my resources. This is especially true for technical questions or general curiosity like what is this? How does this work? These tend to be thinner questions that are worth trying to resolve on your own first, as there is usually a black-and-white answer out there. It’s absolutely okay to escalate them to a teammate if you hit a wall or it isn’t clicking. Building those exploratory skills before offloading the question is part of growing as a developer.
A related tool is that if you know what someone may respond with to your question, you should look into that before asking. For example, say they likely would say, “Have you looked at x yet?” You should look into x before asking! It will show that you are trying to solve your own problems before asking. It will go a long way with your team.
Know your audience and your setting.
Tied closely to the above is understanding who you’re asking and whether the question makes sense for that person. Knowing your audience is paramount so that you don’t waste other people’s time, but also to get an accurate answer.
This becomes even more critical in client or stakeholder-facing meetings, where impressions matter more. I personally do a quick review with a teammate of any question I’m thinking of raising in those settings beforehand as a sanity check. This makes sure the answer isn’t already available to me somewhere, or I am not missing something obvious, and it’s worth surfacing in one of those meetings.
The same concept applies to where and when you ask. Does the setting warrant the question? Asking the team how the new sprint ceremonies feel in a refinement meeting obviously would not be the place. Asking in the right environment increases your odds of getting a good answer, and being respectful to the purpose of the meeting. Being attuned to these nuances is a part of developing good instincts.
Write it down first.
Before asking a question, I write down the key context and points I want to hit in a bulleted list. These keep me on track, make sure I don’t forget anything important mid-conversation and give me a reference point. I’m a big fan of a good artifact, and this is one of the simplest ones you can make. I like to take notes during conversations and I can cross reference the list to make sure I got all the questions answered.
Decide on meeting-appropriate questions.
Bring thick questions into meetings. These are the questions that are genuinely valuable for the group and spark deep discussion. Think “why” questions. Or, “Have we considered X?” or, “Is Y a concern?” These kinds of questions open and encourage discussions instead of closing them. Bonus points if you have follow-up questions to dive deeper and expand upon ideas.
Does the team benefit from having this discussion? This is a crucial idea to consider for bringing up a question in a meeting setting. For most things development related absolutely the team should be in on it! Things like a new idea for a way forward or a bug to bring up would be great. Bringing up that I left a comment on someone’s PR to remove some import would not be right for a group setting.
Try the Diamond Strategy.
The basic idea is to open up with an easier thinner introductory question before diving into the deep stuff. It can be a powerful segue into deep conversation and makes gradual progress into good collaboration. It’s a simple tool, but it helps conversations flow smoothly. Here is an example of this strategy at work:
Thin opening question: How are we handling error states in this service?
Thick continuation question: Why are we catching every error? Should they bubble up? Do we really need an error state for that?
Thin closing question: So it’s better to let errors bubble up in this service so we preserve the full stack trace, is that right?
This is a pretty simple, clear-cut example of how a conversation with this framework in mind could work.
The goal of this post was not to make asking questions harder, but rather to give you tools to make you more effective at this. Asking more questions in general is good, but going in prepared with an artifact for reference, knowing your audience/setting, and letting the conversation flow progressively make these questions better for all involved. Like anything, these skills take time to improve at, and don’t let the fear of asking a bad question stop you from asking at all! I have asked many silly questions in my early career. Below is a paragraph of all the negative things I have experienced from asking non-perfect questions: