How do you Handle Ambiguity?

It’s a fair question, and a rather common one in interviews. Some may say it can be a red flag of a toxic culture - maybe, but the truth is, ambiguity exists in every organization and on every team. It exists all around us, not necessarily deliberate or willful, nor as some monolithic spectre, the mutually exclusive opposite of clarity and detail. Ambiguity doesn’t require a complete absence of these things; it more often exists in degrees as merely a lack of clarity or detail, interwoven among them.

The human brain has a way of automatically dealing with ambiguity even without our awareness. It does this by filling in the blanks with assumptions and inferences, often based on contextual clues. This can be beneficial at times, but not necessarily in a project management or product development setting.

Often, stakeholders may deliver ambiguity unintentionally. They may not know what information is needed by the next link in the stakeholder chain. Maybe what they think they’ve communicated is not what we think we have heard - the brain may have filled in too many blanks.

The first step in handling ambiguity is to recognize it when we encounter it. This requires a specialized skill, deliberate critical thinking to “short-circuit” our brain’s natural tendencies. In the software development life cycle, we write requirements that define the customer’s needs and expectations. Good requirements tell the story of the problem to be solved. Requirements are translated into tasks which are often broken down into smaller, more manageable tasks. Each of these steps is designed to eliminate ambiguity, and yet it still can slip through. Good product owners, project managers, designers and developers have trained themselves to ask questions and avoid assumptions.

Once ambiguity has been identified, the question remains what to do about it. Ambiguity is not inherently bad. In fact, it can be a valuable and healthy part of the process, one that inspires creativity. A judgement call must be made at this point. Do we accept the ambiguity or do we choose to mitigate it?

What type of mitigation is appropriate depends on the situation. The obvious move, the naive approach, would be to ask questions and wait for answers. This is not the wrong approach; asking for further clarity or detail is an important part of the process. But it can’t be our only approach in every situation.

Sometimes the right approach is to make our own decisions. By asking too many questions, we risk forcing people to make decisions that are unnecessary, or simply irrelevant to them. Long ago as a Panera Bread manager, I had a cashier who would inundate customers with questions. A person couldn’t order a smoothie from him without being forced to make unnecessary decisions. “Big straw or little straw?” “Whipped cream or no whipped cream?” “Would you like us to swirl the syrup around the cup before filling it?” Now imagine ordering a salad from this guy. Of course there was a standard recipe with defaults for all these details, and by turning those defaults into unnecessary options, he created unnecessary tension for his customers. What he thought was exceptional service could also be seen as a lack of professionalism.

As developers, we have access to recipes in the form of standards and conventions. We can use these to fill in the blanks and present solutions instead of questions. The key is to think critically about the nature of the ambiguity and our response.

It's also important to consider who is more the expert on the subject matter around the ambiguity. If clarity is needed on design standard, then that's a question for the design team. On a smaller project without a designer, a judgement call must be made regarding which stakeholder is more the expert. It's not a bad idea in the absence of a role-based SME, for a developer or other stakeholder to do a little research and make a decision, but we shouldn't ever place that burden on the customer. And be mindful when this move may cause potential rework; in that case, seek clarification.

Ultimately, we are here to solve problems. That’s our role. Our customer brings us a problem, and in return we provide them with a custom solution. How we decide to handle any ambiguity we encounter along the way should be guided by that simple fact. If the ambiguity relates to the nature of their problem, their needs or expectations, its appropriate to ask them questions to clear it up. Otherwise, questions go to the subject matter expert. If that person is you, make a decision based on your expertise, research and best judgement.