The Art of Asking Questions for Engineers
ENGINEERING
The Art of Asking Questions for Engineers and Data Professionals
in Meetings
As engineers, data scientists, or data analysts, we're often tasked with providing feedback or asking questions in meetings where new ideas, data product, ML model, or etc are being pitched. Especially for junior and mid-senior engineers and scientists, the ability to ask thoughtful, constructive questions can elevate the discussion and drive better outcomes for the project.
However, not all questions are created equal. Asking questions that are too basic, overly complicated, or unnecessary can derail conversations and reduce your credibility. So, how can you ask the right questions at the right time? Here are four guidelines to help you ask better questions in meetings.
1. Read the Room
Have you ever asked a question in a meeting, only to later regret it because you underestimated the expertise of the presenter or audience? Or perhaps you asked something so detailed or complex that no one in the room understood, leaving you feeling it wasn't the right time for such a deep dive. Don't worry – you're not alone!
One of the most important aspects of asking good questions is understanding who's in the room. The level of technical and Business expertise varies from meeting to meeting, and you need to tailor your questions accordingly.
If you're in a meeting with experts, you naturally avoid asking basic questions that everyone already understands. On the other hand, if the audience is more business-focused or less technical, you steer clear of diving into overly detailed technical queries that might confuse or alienate them. To strike the right balance, it helps to study who's in the room. Checking the participant list or their titles can provide insights. If you've been with the organization for a while, you might already know many of the attendees, making it easier to gauge the room. But if you're new to the team, it can be a bit trickier. In that case, pay close attention to the tone of the main presenter and the depth of the discussion. Or, you can wait for a few people to ask questions before jumping in with yours.
Remember, the goal is to ask questions that contribute to the discussion, not ones that cause frustration or distraction. By gauging the knowledge level of the participants, you can ask questions that are relevant and that help advance the conversation.
2. Focus on Possibilities Not Limitations
Often, when a new idea, data product, or a model is being pitched, the instinct (especially among data professional) is to question its feasibility. "Can this even be done?" is a common question. While this might be important eventually, it's more valuable to think ahead. Assume that the model, data or idea can be implemented, and focus on its impact.
For example, if the meeting is about a new prediction model, instead of questioning the necessary data for such a prediction model, first ask questions like, "Who will benefit from this feature?" or "Does this new model answer the questions that presented?". In fact, you are not confronting the idea with technicality, but you are looking for a solid business justification for the work.
This forward-thinking approach leads to discussions about value and future possibilities, rather than getting stuck in the technical weeds early on. It also shows that you're thinking strategically about the benefits the idea can bring once it's implemented. Remember, it doesn't mean that we don't discuss the technical feasibility of the pitched idea (which we should), but those questions should not come first. Maybe the idea does not have a solid business justification, then we spent plenty of time on technicality, before understanding that the idea or presented model does not solve the business or our research needs.
3. Let's Look Around
Engineers often get excited about their ideas, and that enthusiasm can sometimes prevent them from thoroughly researching existing solutions. It's the responsibility of more experienced engineers to ensure that the new idea, model, or data isn't just a duplicate of something already in place. After all, no one is familiar with every tool, solution, or dataset within an organization, so it's important to help your peers avoid reinventing the wheel. Sometimes, a small tweak to an existing tool can address the problem just as effectively. Specifically, ask whether the current tools, data, or features already meet the needs the new idea aims to solve. Personally, I made this mistake early in my career and worked on a piece of code to generate a visual data representation that another tool (which the company paid for its license) did it better. I didn't know such a tool existed until someone politely pointed out and later he showed me the tool and that specific visualization.
When someone is pitching a new product or dataset, it's important to ask how it differs from what's already in place. Challenge the presenter to explain why the new idea is necessary and what gaps it fills that current tools or data don't. This approach not only shows that you're critically evaluating the solution but also encourages the presenter to clarify the value of their innovation.
However, the way you ask these questions is crucial. Your tone should be collaborative, aimed at ensuring the presenter is fully aware of existing potential solutions. Simply questioning new ideas by pointing to existing ones, without understanding their differences, can stifle innovation within an organization. If people feel their ideas are constantly shot down by comparisons to current solutions, they may become less motivated to drive improvements. So, first take the time to fully understand the new idea. If you do know of an existing solution, ask for clarification on how it differs, rather than assuming they overlap.
4. Plan B
I've witnessed many meetings get derailed by endless debates over whether gathering a dataset or building a model is feasible. These discussions often lead to either abandoning the idea entirely or moving forward with uncertainty, hoping things will somehow work out. But it doesn't have to end this way. In more productive discussions, even when one side believes the approach isn't feasible, instead of letting the project die or pushing ahead unsatisfied, they propose a Plan B in case the original approach fails.
Rather than focusing on potential obstacles or why something might not work, shift the conversation toward solutions by asking for a backup plan. Instead of asking, "I don't think it works because data X is not available!" try, "What's our plan B if the data X is not available? How can we make it work in that situation?" This keeps the discussion proactive and solution-driven, encouraging others to think ahead and consider alternatives, rather than getting stuck in hypothetical problems.
By reframing obstacles as opportunities to prepare for contingencies, you not only foster a more constructive conversation but also show that you're committed to finding a way to make the idea succeed, not just highlighting its flaws.
Conclusion
By following these guidelines, you can ensure that your questions add value to the discussion and help drive better outcomes for the team. Asking the right questions is a skill that grows with experience, and these principles will help you build that foundation.
