What's in a Name? That Which We Call Ambiguity...

This is a story where I learned that words matter.

Years ago, I remember having a sit-down with my manager where I expressed deep frustration at some of my projects.

Here was my gripe: I felt that the initial project briefs I received rarely resembled where the project ended up heading, and I perceived a lot of my efforts going to waste due to the problem statements evolving every couple weeks.

I proudly told my manager that we needed to be stricter with our stakeholders and prioritize projects where we could clearly envisage the outcomes, so as to protect our time.

My manager didn’t shoot me down immediately, but did challenge me to think about why I was so uncomfortable with these situations.

I didn’t realize it at the time, but I was essentially voicing my discomfort with ambiguity.

That conversation was a turning point for me. And thus started a journey. I went from resisting ambiguity to coping with it. Then from coping to managing. Then from managing to embracing.

The end goal, of course, was to eventually thrive in ambiguity.

And it turns out that one important hack I learned along the way made a huge difference.

Here's the hack: eliminate "ambiguous" from your vocabulary.

No seriously. Here's why.

Deeming something ambiguous should be thought of as a lazy cop-out mechanism. It’s a subjective construct that doesn’t help us figure out why something feels ambiguous, and what can be done to solve it.

It merely gives us an excuse not to engage.

Instead, what we want to do is to reframe the situation, and forcing ourselves to use specific verbiage can help us pinpoint the exact roadblocks.

Here's a few specific examples.

1️⃣ Does a project feel "ambiguous" because the problem statement is unstructured?

For example, imagine that your business partner comes to you deeply worried, telling you the house is burning and you need to help them: Incentive payouts don’t seem to be working, travel budget is overrunning, critical roles aren’t being backfilled in time, product asks aren’t landing with engineering, and by the way sales teams aren’t diligently updating their pipelines… You get the idea.

Sure, you can call this an ambiguous project.

Or you can reframe it as unstructured.

And if you do that, then all of a sudden you have actionable next steps.

For instance, you might decide to better categorize this laundry list of problems by evaluating their respective complexity, impact, and urgency; you can then prioritize accordingly.

Or, you can also decide to tighten up the problem statements and avoid solving for red herrings. Perhaps the problem to solve for is not necessarily to get sellers to update their pipelines, but rather to ensure leadership has a way of getting easy visibility of what's going on in the business.

Whatever you do, assume agency, and challenge yourself to articulate what exactly makes something ambiguous.

2️⃣ Does a project feel "ambiguous" because the problem statement is complex?

For example: imagine that you’ve been asked to improve headcount efficiency by rethinking how we define client portfolios for sellers.

This is a beast of a problem: it’s not unstructured, but it’s complex as hell.

What if redefining portfolios across the organization leads to worse customer service and negatively impacts revenue?

What if certain teams suddenly get smaller and some managers' scope and leveling can’t be justified anymore?

And what if this affects the sales bonus structure and causes discontent amongst the sellers, or even attrition?

Reframing the situation as complex is the first step. At least you're not running away from it.

But once you recognize the complexity, you have the license to find ways to break it down into simpler pieces.

3️⃣ Does a project feel "ambiguous" because the problem statement is subjective?

I’ve been in situations where a VP simply asks something like, “Do we have the right data & measurement strategy?”

Sure, we can eyeroll and sigh all we want. What exactly qualifies as the "right" strategy?

Or, we can explicitly recognize that instead of framing this as too ambiguous, we can frame it as too subjective.

Then we can fix it. We can set up the right guiding principles and measures of success, to ensure we can develop an actionable working plan and tackle the original brief (and avoid going down a rabbit hole!).