Ambiguity Is a Feature, Not a Bug

Great engineers don’t wait for clarity. They create it and help everyone move faster because of it.

Some engineers thrive with a clean spec. Others thrive when there isn’t one.

Here’s the truth:
You’ll rarely get handed perfect clarity.
You’ll get just enough to start and be expected to figure out the rest.

That’s not dysfunction. That’s the job and as teams ship faster, the cost of misalignment rises. Ambiguity isn’t just annoying, it’s expensive.

The real difference between good and great engineers?
It’s not how fast they code, it’s how well they move through ambiguity and make it easier for others to move, too.

The Real Work of Senior Engineers

Most engineers think clarity is someone else’s job.

They wait for better specs. A final design. A product call.

But the engineers who grow to get trusted with big bets and earn influence without a title don’t wait for clarity. They create it.

👉 They turn loose direction into real decisions

👉 They spot risks while everyone else is still heads down

👉 They don’t just unblock themselves. They unblock the team

This is the hidden work that makes the visible work possible. Let me show you how it played out for me.

The Gift That Kept on Giving

At Trade Republic, I got pulled into a project called Gifting: a way for users to send stocks/ETFs as presents, complete with a lottery mechanic. Nine milestones. Four platforms. Six weeks.

The PRD was already excellent. The team was doing great. But, the project had already kicked off, and something was off.

Product was still shaping requirements. Engineers were shipping. Testing hadn’t started yet, no one owned the big picture and no one had time to ask the most important question:

Are we still building the same thing?

So I was asked to step in.

I started by pulling context: PRD, Slack, designs, DMs.
Then I wrote out what I thought we were actually building: edge cases, failure paths, inconsistencies. I used a simple Given–When–Then structure:

Given [state]
When [event]
Then [expected result]

Example:

Given a user opens an expired gift link
When they try to redeem it
Then they should see an error and a CTA to send a new gift

I didn’t write these for anyone else at first. I wrote them so I could think straight,
but, they spread. Engineers started validating their work with them. Product used them to check intent and when priorities shifted, I updated the cases.

I wasn’t the project owner. That didn’t matter. Someone saw what was missing and brought me in to help the team move with confidence.

That’s what clarity looks like in practice.

How to Create Clarity at Any Stage

If you’re working on a project right now, beginning, middle, or end this is how you can bring clarity starting today. These are the same tools I’ve used across complex, multi-platform builds where timelines were tight and alignment mattered most.

1. Document the Gaps

Most specs only cover the happy path. You cover the rest.

In every complex project I’ve worked on, the real risks hid in the gaps: network failures, edge cases, undefined states.

Take your current feature and write:

Given: [a real edge case]
When: [an action occurs]
Then: [what should happen]

Do this for 10 real scenarios. Share them with your team.

In most cases, at least 2 or 3 will surface different assumptions across functions, saving you days of rework down the line.

💡 Quick Tip:
To write high-quality Given–When–Then statements, start by thinking like a tester, not just a developer.
Focus on observable behavior, not implementation. If it can’t be validated from the outside, it doesn’t belong in the statement.

(This approach comes from Behavior-Driven Development practices: Dan North’s original BDD work is a great source if you want to go deeper.)

2. Create a Source of Truth

In fast moving projects, information lives everywhere. If you don’t centralize it, your team wastes time asking the same questions.

I’ve used this on high pressure builds where scope shifted weekly. A single shared doc kept the team aligned across mobile, backend, product, and design.

Create a simple doc with three sections:

What We’re Building

A 3 sentence summary in plain English

Open Questions

Checkboxes for unresolved logic or decisions

Key Decisions

List what’s been agreed, with a date

Keep it updated weekly (or daily if you're moving fast). No process. Just facts. When it starts getting referenced in standups or Slack threads, you’ll know it’s working.

3. Check Across Platforms

The most common source of bugs I’ve seen? Two platforms solving the same problem in different ways.

Talk to someone outside your lane. Backend if you’re frontend. Mobile/Web if you’re backend.

Ask:
“How are you approaching this feature?”

Compare what you hear to your own mental model. Then document the differences and clear them up before they turn into blockers.

It takes 15 minutes. It avoids weeks of confusion. You can usually get this done during a technical kick-off, or technical planning session after the initial product kick-off has happened.

4. Challenge the Plan

Most teams avoid these questions because they sound negative. But, in every team I’ve led, asking early has saved us hassle later down the line.

Try these:

• What are we assuming that hasn’t been validated?

• What breaks if this fails?

• Who owns the outcome when something goes wrong?

You’re not second guessing the plan. You’re strengthening it before it gets expensive by creating alignment across everyone and accountability to whomever is leading.

💡 Quick Tip: Use a RACI matrix early in a project to clarify roles and avoid misalignment. Assign who is Responsible (does the work), Accountable (owns the outcome), Consulted (offers input), and Informed (kept in the loop).

This simple grid helps prevent duplicated effort, missed responsibilities, and vague ownership.

5. Run a Pre-Mortem

When timelines are tight, most teams focus on best case execution. But, great teams try to flag risks as early as possible. You may have heard of a post-mortem during an incident call, or incident reporting. But, what is a pre-mortem? Instead of looking at the past, we look into the future.

“It’s three months from now. The feature failed. What happened?”

You can then use the 5 whys principle to answer your question. Here’s a real world example:

Feature: Scheduled job that generates monthly invoices and emails them to customers

1. Why did it fail?
   The job didn’t retry failed invoice generations due to transient API errors.

2. Why wasn’t there a retry?
   The invoice generation function was fire-and-forget and wrapped in a try/catch, with errors logged but not rethrown.

3. Why was failure treated as non-blocking?
   The job was designed as “best effort” to avoid alert fatigue during initial rollout.

4. Why wasn’t this flagged as risky?
   Engineering assumed failed invoices would be retried next month.

5. Why did that assumption hold?
   The system didn’t track failed generations or persist state, it operated statelessly, by calendar date.

Root cause: The team had different mental models of failure tolerance. Product saw invoices as critical. Engineering treated it like a batch process that could tolerate loss. No shared definition of what “done” meant for the job.

What we should’ve done:
Define success criteria upfront:

“The job must guarantee delivery of all invoices within a 24 hour window or raise a critical alert.”

This is one isolated example, but a pre-mortem is used to identify every risk. Organise your document by identifying risks, root causes and action items before go-live. Assign owners and timelines to make sure the risks are mitigated accordingly.

What This All Buys You

When you reduce ambiguity, you reduce the cost of speed. You prevent the kind of misalignment that turns into bugs, rework, or missed deadlines.

It’s not extra work. It’s leverage.

You become the person who helps everyone else move with more confidence and less waste.

✅ Your Move This Week

Option 1: Edge Case Audit
Write 10 Given–When–Then cases for your current feature. Share them with your team. See how many prompt discussion.

Option 2: Platform Sync
Have a 15 minute sync with someone on another platform. Compare what you each think the feature does. Document the gaps.

Option 3: Living Doc Test
Create a one-pager: “What We’re Actually Building.” Capture what’s known, what’s still fuzzy, and what’s been agreed. Update it for one week. See who starts referencing it.