Strength Through Admitting Ignorance
I recently switched to a new team within Box. On my new team, I’m working on a new project with new people in a language I haven’t touched since college (Java). Because of all of this, I found myself taking a bit of a back seat and letting others take the lead. I found myself assuming that if something didn’t quite make sense it was because I was new. I didn’t want to admit when I had no idea what was happening and certainly not to the entire group. I asked my questions later to a single person or I would try to figure out things on my own. Over time, I started to realize that I wasn’t the only one with some of my questions. One day at standup, someone suggested we work on a particular task and I didn’t think we were in a state where it was ready to work on, but no one else objected, so I figured they knew something I didn’t or the task was something different from what I thought it was. When I later asked person after person on the team, they all said the same thing — they also didn’t think it was ready to play. I don’t know what held them back, but it did make me realize that I needed to speak up more.
I quickly realized that speaking up can be hard and definitely goes against my nature. By raising questions, I admit that I don’t understand or that I have a knowledge gap. I admit that I’m not keeping up with a conversation that everyone else appears to be following. It sometimes feels like I’m interrupting a productive flow or taking us on a tangent. Even when I know raising the questions may be the best thing for the team, it can be very hard to do and goes against my grain. Asking questions feels like I’m showing weakness.
The more I’ve been thinking about this, the more I’ve realized that it takes strength to speak up and some of the best technical leaders I’ve seen are those that are willing to ask questions. There is a principal engineer at Box who I’ve really admired for his ability to both move projects in positive directions and to also get people on the same page. He does a lot of different things well to contribute to getting these objectives accomplished, but one of the things I’ve really noticed is that he’s never afraid to ask questions. I’ve seen him ask questions where I initially thought the answer was obvious and implied by what the speaker was saying only to see his questions reveal differing interpretations. He’s quick to ask for clarifications or better explanations of even somewhat basic things. At first, it sometimes felt as though he was slowing things down, but I’ve come to realize that it’s through these clarifications and basic questions that he’s able to so effectively build consensus and a shared understanding.
What makes a good question?
There are clearly a lot of benefits in slowing down to make sure everyone is on the same page before charging ahead. However, if everyone is already on the same page or if only one person is confused, it can unnecessarily slow things down. We’ve all been in that large talk when that one person gets up and asks a question that is clearly so niche that there’s no way anyone else will have any interest in the answer. No one likes that person, and that’s obviously not what I’m suggesting.
It’s important to think about the appropriate audience for your question to make sure you’re not wasting others time. At the same time, waiting to ask everything in private doesn’t allow you to discover that other people also have the same question or that the assumed shared understanding actually isn’t the same. There are a few things I try to think about before asking questions.
- Can I ask a modified question to understand if everyone else already understands something I don’t? For example, can I ask something like, ‘I’m a little confused about how we plan to do X, does everyone else understand it?’ If the answer is a sheepish no, then it’s a great time to dig in with everyone. If everyone else does understand it, I can tell the group we can move on but that I’d like to circle back with someone later to fill me in.
- If I think I know, but I’m not quite sure, can I quickly restate my understanding? This can be a really good technique because it not only forces me to digest something enough to re-state it, but it can also be a quick way to validate that I actually do understand something. I might do this as ‘My understanding is X. Is that right?’ or ‘I want to make sure I’m understanding you correctly. Are you saying Y?’
- Have I given the person enough context to effectively answer not only the question I’m asking, but also any deeper questions I may be trying to explore? There may be different answers depending on my situation or it may be that I’m asking entirely the wrong question. These sorts of things can only be revealed if the person answering has enough context. That said, my life story isn’t relevant, so a quick two sentence introduction to why I’m asking is probably enough.
When should I ask?
Even if I’ve identified the right audience, it still matters when I ask the question. One of my friends was describing a meeting recently where they were deep in discussion about one topic and someone else came up to the group and at a slight lull in the talk tried to completely hijack the meeting and change the topic. There are a lot more subtle examples of this as well where a group gets taken on a tangent to the main conversation. These sorts of things can cause a lot of context switching and can cause a group to spend a lot of time on things other than the most important topics. At the same time, I’ve also seen my team table so many topics that we reached the point where we weren’t ever answering or deciding on anything. To try to find that happy medium, I try to think about a few things before asking a question or raising a topic.
- Is there a more appropriate time/meeting to ask my question in? Even if I think of the question now, if there’s a different meeting where we will be discussing similar topics, it may make sense to table the question.
- Do I suspect people are actually thinking or saying two different things? In some cases, I’m pretty sure people are on totally different pages. If that’s the case, then getting a shared understanding early is important.
- How many times have we tabled this topic or question? Depending on the topic, it may still not be relevant enough to discuss, but the more times something has been tabled, the more likely it’s something that actually needs to be resolved. Resolving it will likely allow the team to move ahead more effectively.
- Does the question have a short answer? If so, just ask it. Even if everyone already knows the answer, it will be quick to clarify so it shouldn’t take the group on a long tangent.
- Is the piece I don’t understand so fundamental to the entire meeting that I won’t be able to contribute if I don’t understand? Even if I am slowing down everything, if there’s value to me actively participating in the meeting, that value can only be harnessed if I understand. If I’m in the meeting primarily as an observer, maybe I should ask later.
- How hard is it to get in touch with someone who can answer my question? If I’ve waited on hold 5 times, or waited 2 weeks as my meeting was rescheduled 4 times, it’s even more important that I make sure I have clarity on any information I’m receiving and can be worth taking the time to be absolutely sure that I understand something.
What should I do with the answer?
It’s great that I now have my answer, but that’s only part of the value. We’ve all been that person who’s asked the same question 2 or 3 times or maybe even more. That’s not a great use of anyone’s time. There’s also a chance that what I learned might come up for someone else in the future or might be relevant to a broader audience. I’ve also seen times when having documentation around any decisions made or even why we made the decisions can be very valuable in the future. How and when things get documented or shared can be almost as important as the original questions. To that end, there are a few things to think about in terms of how to make sure the appropriate information is disseminated effectively.
- Are there other people right now who might have the same question? If so, maybe I can find a way to present my findings to a larger group or I can write a blog post or email sharing my findings.
- Maybe there aren’t too many others right now who will actively be interested, but will this question likely come up in the future for someone else? In this case, it may be valuable to document my findings in some way that will be easily find-able by others.
- Was there a decision involved that might be revisited? Were there others not present who might want to understand a decision or how it was arrived at? Do I want to make absolutely sure that everyone is on the same page? Meeting notes or a quick email clarifying what was agreed upon can be helpful.
- Do I think I might forget some part of the information? Do I think there’s a quick visual that will help me jog my understanding? If so, I might draw out a diagram to post at my desk or jot myself a note somewhere where I’ll find it.
In the end, questions are really valuable because they can reveal differing understandings within a team allowing everyone to ultimately move ahead more quickly. They also help me learn and they allow me to clearly identify where I actually do understand something versus where I might need to do some research or pull someone aside to dig in with me. They can also help the team as a whole identify areas where we might all have a bit of a knowledge gap, allowing us to fill it. While it can be incredibly difficult for me to admit that I don’t understand something, I’m learning the value of questions and am starting to realize that using them tactfully can actually be a form of strength.
If you like this post, don’t forget to recommend and share it. Check out more great articles at Code Like A Girl.