Staying Useful While the Work Is Ambiguous

Language:

I used to skim past the phrase in job descriptions: “must be able to handle ambiguity.” It sounded like one of those polite corporate requirements that could mean anything. Maybe the company did not know what it wanted. Maybe the manager wanted cover for bad planning. Maybe everyone just copied the same language from someone else’s posting because it sounded adult.

I understand it better now. In my last few roles I have worked with enough people who expected the plan to get locked once, as if a decision was a notarized truth rather than the best answer we had that week. When the plan changed, they did not treat the change as new information. They treated it like betrayal: Someone had moved the goalposts! Someone had failed to think hard enough the first time! Someone had broken the deal!

Sometimes that reaction is fair: Ambiguity can become a hiding place for weak leadership, and no team should have to live inside a fog machine because nobody wants to make a decision.

But there is another kind of ambiguity that is not caused by laziness. It is caused by reality arriving late, which is how reality often arrives when you are making something new.

Learning what the phrase actually means

Handling ambiguity does not mean enjoying chaos. It means staying useful when the work is not done becoming clear. That is a different skill from following directions, and it is harder than it sounds because change has a way of making adults feel embarrassed. A person can accept uncertainty in theory and still get angry the moment a design changes, a customer insight lands awkwardly, or an engineering constraint forces the team to redraw the route.

That is probably why employers keep reaching for words like adaptability, flexibility, and agility. In the World Economic Forum’s Future of Jobs Report 2025, employers said they expected 39% of workers’ core skills to change by 2030, and resilience, flexibility, and agility sat near the top of the skills they considered important. NACE found something similar in its Job Outlook 2025: more than two-thirds of responding employers said they were looking for flexibility or adaptability in candidates. The people who keep working well after the ground moves are valuable because they do not turn every new fact into a team-wide emotional event.

Watching certainty become a trap

One thing that has surprised me is how many people treat a changed plan as proof that the original plan was fake. I get it: A plan gives people relief. It lets everyone stop arguing for a while and start doing the work. It gives shape to the week. It lets a team say, “Okay, this is what we are building.”

But a plan is still only a bet made with the information available at the time. The more original the thing you are trying to make, the more likely it is that some of your early confidence is borrowed. You think you know what the customer needs until you put something in front of them. You think the technical path is clean until someone opens the codebase and finds the old assumption hiding under the floorboards. You think the goal is obvious until three reasonable people explain three different versions of success.

The PMI Pulse of the Profession 2026 report is useful here because it names this as ordinary project life, not a special dysfunction. PMI found that 97% of project professionals managed at least one complex project in the past year, and more than half called those projects significantly complex. The report describes complexity showing up in very normal ways: requirements shifting midstream, stakeholders disagreeing on priorities, vendors struggling to integrate, sponsors moving their attention elsewhere.

That sounds like most real work I have seen. It can be messy without being a scandal. The scandal is when a team refuses to learn because learning would require admitting that yesterday’s certainty was incomplete.

Building before the answer has arrived

This becomes very clear on small teams, especially when people start building in code before the fundamental questions have been answered. Code makes a guess feel real. A prototype has screens. A ticket has an owner. A pull request has weight. Once the thing exists, even in a rough form, people start treating it as evidence that the question underneath it has already been settled.

But code can only prove that something can be built. It cannot prove that the thing achieves the goal. A team can spend weeks making the wrong idea feel increasingly polished, and every week of polish makes it a little more painful to ask whether the idea should exist in the first place.

That is not just a philosophical concern. CB Insights analyzed shutdowns among VC-backed companies in its 2026 startup failure report and found that poor product-market fit showed up in 43% of the companies where failure reasons could be identified, behind only running out of capital. Their point was not that founders should never move fast. It was that running out of money is often where the story ends, while the deeper problem began earlier: the company never found a market that truly wanted what it was building.

I have felt a smaller version of that inside product work. A team can argue forever about the best way to build a feature before it has answered the more basic question: if this works exactly as designed, does it actually solve the problem we claimed to care about? If that question is still open, then change is not a disruption of the work. Change is the work trying to become honest.

Keeping order without pretending

None of this excuses sloppy communication. In fact, ambiguity makes communication more important, not less. When the work is uncertain, people need a clear current direction, a record of what has been decided, and a shared understanding of which assumptions might change. They need to know whether a decision is final, provisional, or simply the best path for the next two weeks.

The agile world has been saying some version of this for a long time. The Agile Manifesto values responding to change over following a plan, while still acknowledging value in the plan. The Scrum Guide describes work as empirical: teams inspect what happened, adapt, and repeat. That is the part people often flatten. Agile does not mean wandering around. It means creating enough structure that learning can change the work before the work becomes too expensive to change.

Google’s research on team effectiveness points in the same direction from the human side. In its Project Aristotle work, Google found that effective teams depended less on who was on the team and more on how the team worked together, with psychological safety ranked first among the dynamics it identified. People need to be able to ask basic questions, admit mistakes, and offer new ideas without getting punished for sounding ignorant or disruptive.

That matters because ambiguity already makes people defensive. If the room punishes questions, people will protect themselves by pretending the plan is clearer than it is. Then the team gets the worst version of both worlds: fake certainty at the beginning and expensive surprise at the end.

Staying useful in the messy middle

I still find it annoying to work with people who melt down whenever reality changes. I am not talking about people who ask for clarity, challenge bad decisions, or push leaders to communicate better. Those people are often doing the team a favor. I am talking about the person who experiences every adjustment as an offense and then makes the team manage their disappointment on top of the original problem.

That kind of reaction is disruptive. It also strikes me as immature, not because mature people enjoy uncertainty, but because mature people can distinguish discomfort from injustice. They can say, “I do not like that this changed,” without acting as if change itself proves someone did something wrong.

Communication is already hard when everyone is good at it. Most of the time, everyone is not good at it. People hear different things in the same meeting. They fill gaps with private assumptions. They nod along when they should ask one more question. Add a new product, a small team, technical constraints, customer uncertainty, and a deadline, and the whole thing becomes harder than any job description can politely admit.

That is the part I wish more people understood. Bringing something new into the world is difficult and painful. You can reduce the confusion. You can write better notes, make cleaner decisions, set better expectations, and test assumptions earlier. You cannot remove the messy middle entirely.

At some point, the map will fail. The team will learn something late. The decision that made sense on Monday will look weaker by Thursday. When that happens, the useful person is not the one who insists the first plan should have survived contact with reality. The useful person helps the team see what changed, decide what still matters, and keep moving without turning uncertainty into a second project.

Related

How I Decide Whether AI Output Deserves My Trust

How I Ship Real Products with AI-Assisted Product Design

Comments

Leave a Reply Cancel reply