Seeking Clarity Without Being A Jerk

•communication
Back

I wrote this many moons ago when I still worked as a program manager for the GitHub Support Community forum (opens in a new tab). Back then, I focused on understanding and improving our problem resolution rate. The nature of my work was strategic, creative, and collaborative and my projects varied from researching, ideating, and creating content for helping first-time community members to collaborating with other teams to tackle a backlog of topics in our forum.

Let's talk about ambiguity 💁‍♀️

One of the key skills I'm learning to develop is identifying assumptions and asking questions, especially when new projects come. Some projects already have a clear goal in mind, while others don't.

For the latter, there are times when I feel like this:

There are times when I go through "paralysis analysis" where I think more about what to do than actually doing it. Something that's helped me move forward is asking for help.

Recently, one of the ways that I asked for help with understanding this problem space better is by joining our company's #how-do-i channel. The channel describes itself as a "safe place to start if you have questions about how to do or find something at GitHub."

The channel lives up to its name because of the many Hubbers who generously share their time and expertise. For this key skill, I asked them:

How do I learn more about asking the right questions to clarify ambiguous work requirements?

Shortly after posting the questions, I received a stream of responses, resources, and ridiculously good advice. I've done the work of summarizing it so you can read and apply it when the situation arises. 😉

The tricky thing about just asking... "why?" 😬

When faced with ambiguity, it's natural for us to just ask "why?"

Knowing the motivation behind a project is a key factor before choosing to invest more time and resources.

The way we find out about the motivation is also important depending on the outcome we want to drive.

Cindy, one of my colleagues, helped me understand that anytime we ask a plain "why?", it can sound like we're being defensive or reluctant to help. 😬

Repositioning "why" with curiosity 👩‍🔬

We can reposition this single-word question to exercise curiosity starting with these expressions:

And then leading into the question:

It can also help to include add a reason after asking the question:

Take the time to listen to these responses. Write them down and consider the other person. If this doesn't "work" for any reason, you can pivot the approach by stating your assumptions up front instead:

It’s much easier for people to react to assumptions than open-ended questions so you tend to get quick responses.

This approach can feel abrupt or offhand the first time you do it. It may also help to add a disclaimer that states the assumptions first and offer to meet with them over a call to clarify things further:

Hey, I’m going to state some assumptions in the hopes that can shorten our meetings. If these are completely off-base, let’s jump on zoom to discuss in real-time.

Going deeper, my awesome colleague Lizzy shared an experience around the difficulties of discussing work requirements if there's a technical knowledge difference between two parties:

I've found work requirements are harder to discuss if there is a technical knowledge difference between the two parties and one of my roles is to remind my teammates that they need to break down the technical components for me (and realistically for others reading who are not security SMEs). I'm not really afraid of looking like I know nothing anymore, but it can be hard to constantly out yourself as not very technical. It can feel like the answers to some of Cindy's questions are obvious to everyone else, but it's surprising how often that is not the case.

Cindy re-assured that it's okay to acknowledge those feelings and confronting the sentiments of the questions head-on:

I often tell people "it will feel awkward and embarrassing to ask these questions!" And unfortunately it doesn't really go away - I still feel a little anxious when asking people to clarify something or step back and re-state the problem. What helps is that I've seen it work every time: unless people are really resisting out of bad faith, they will answer and someone else in the room besides me will say "oh! I didn't realize that".

Lizzy also highlighted identifying assumptions as one of the primary technical skills as a Program Manager and the power of mindfulness:

I try to keep in mind as well that people don't want to assume I know nothing, because that's also a bad look. I remind myself that identifying assumptions is part of my technical skill as a PM.

I'm also big on self-deprecating humor because not all assumptions are done with poor intent and it helps set the mood as "I need to know this thing, but I don't need to focus on who's fault it is that you didn't already tell me this thing." Obviously, there are also times where you need to focus on how the assumption has affected progress or is belittling, but especially here, I have had wayyy more instances of the former.

Going deeper 🐇

A number of my colleagues suggested these books to learn more about the topic: