Doing the Work or Defining the Work? A Career Advancement Approach to Ambiguous Tasks

At 2 a.m., Lin Hang had been staring at the PRD document for nearly two hours. The product team said to "optimize the system performance," and his manager @mentioned him in the group chat: "Can this go live by Friday?" But no one told him—optimize what? Where is it slow? How do we judge whether the "optimization" is successful?

He gritted his teeth and typed a few lines of code, deleted some logs, and adjusted the thread pool, feeling like he was building sandcastles on the beach. A wave of drowsiness hit him, and only one thought remained in his mind:

What problem am I actually solving?

This is a familiar scene for many professionals. Ambiguous tasks are like real-world questions conjured out of thin air: no clear goal, no measurable standard, and even the person in charge is unsure of the direction of the problem.

But experts often don't rush to write code first. Instead, they pause and define the problem itself.

Not solving the problem, but finding the problem

When Lin Hang first started working, what he feared most was this kind of "figure it out yourself" task. He was used to opening the IDE and writing code right away—a line of SQL optimization, a bit of cache acceleration, a few try-catch blocks wrapped around. The delivery looked like a lot of work, but after going live, no one gave feedback, and the team felt nothing.

Later, he was assigned to lead a project to improve system availability. It was the same familiar recipe: vague goals, scattered data, conflicting requirements. That time, he decided to try a different approach: don't start working, ask questions first.

• What does "availability" mean? Reducing failure frequency? Improving response speed?
• Who thinks the system is "not good enough"? Customers? Customer service? Technical support?
• What historical data can measure whether improvements are effective?
• What exactly happened that made this problem worth solving?

He spent three days creating a problem map: different departments' definitions of availability, the frequency of common issues, blind spots in existing monitoring, and keywords from user feedback.

This map allowed the team to talk about the same set of problems for the first time. Six weeks later, they successfully reduced P2-level incidents by 76%, and customer service calls dropped by half. During the post-launch review, even the usually silent CTO nodded and said, "You didn't just solve the problem—you first found the right problem."

Ambiguity is actually an opportunity

Many people want to run away when they hear about ambiguous tasks. But in the eyes of experienced people, ambiguity represents freedom, control, and even opportunity.

Because once you can define the problem—you gain the initiative to set standards, secure resources, and establish influence.

In Lin Hang's team, a habit gradually formed: whenever an unclear task appeared, they wouldn't hold a meeting or evaluate it right away. Instead, they would quietly write a problem clarification document. This document doesn't provide answers; it only lists key questions:

• What are the success criteria?
• Who are the direct beneficiaries?
• Are there any red lines that should not be crossed?
• Which assumptions might be wrong?

This sounds like taking a detour, but it is actually the fastest shortcut to effective action. Because in ambiguous tasks, 90% of the time is wasted on misunderstanding and rework. You think you optimized performance, but they actually wanted to add a loading animation; you spent two weeks refactoring the architecture, but the business side just wanted to make the error message text more presentable.

True experts can make ambiguous tasks land with impact

Lin Hang is now the technical lead of his team. When newcomers ask him, "How do you push forward when requirements are unclear?"

He no longer talks about flowcharts or recommends any framework. He just says one sentence:

"Can you describe the problem more clearly than anyone else?"

It's not about who acts faster, but about who sees more deeply. It's not about rushing to do the work, but about daring to define the work.

Final thoughts

Ambiguous tasks will not disappear. Like fog, they will always drift across your path as you get promoted and earn more.

But some people wander in circles in the fog; others look for light in the fog.

The key is not how capable you are, but whether you ask that critical question:

What problem are we actually solving?