Strength Through Admitting Ignorance

Hello world, I'm Joy Ebertz. I'm a Staff Software Engineer here at Box who also dabbles in writing and crazy amounts of running (I recently got into ultras). I've been at Box for 5 years, which in Box (startup) time, makes me an old-timer. Over my time here, in addition to my prior experience, I've built up many thoughts and perspectives about coding enterprise software, building a career, managing people, not managing people, women in tech and life in general. As a bit of an introvert (like many of my fellow developers), I've found that writing is a good way to share my experiences and reach a broader audience. I usually write about whatever is top of mind based on conversations I have with my friends and co-workers, things that come up in the news or whatever happens to be happening around me.

I started publicly blogging last June on Medium, but hope to share some of those posts and some of my new ones here. Through my writing, I hope to share a bit of the Box culture and the things we think about, or at least what one engineer here thinks about.

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, 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. 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. When I later asked around 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 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. 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 noticed is that he asks a lot of questions. I’ve seen him ask questions where I initially thought the answer was 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 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 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 the question isn't broadly applicable, it can unnecessarily slow things down. We’ve all been in that large meeting where 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 not what I’m suggesting.

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 for someone to fill me in later.
• Can I quickly restate my understanding? This 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.

When should I ask?
Even if I’ve identified the right audience, it still matters when I ask the question. One of my friends described a meeting recently where they were deep in discussion about one topic and someone came up to the group and at a slight lull tried to completely hijack the meeting and change the topic. There are a lot more subtle examples of this where a group gets taken on a tangent. These sorts of things 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? 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 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, I should ask later.

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 more. 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 how or why we made the decisions has prevented churn. 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, 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? Is there 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.