Someone has to define that project. It might as well be you.

When leadership passes ambiguity down the chain, the person who fills the void wins.

Feb 03, 2026

👋 Hey, it’s Stephane. I share lessons, and stories from my journey to help you lead with confidence as an Engineering Manager. To accelerate your growth see: 50 Notion Templates | The EM’s Field Guide | CodeCrafters | Get Hired as an EM | 1:1 Coaching

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

Your team just got assigned a “critical” project from a very senior leader in the company. There’s excitement, buzzwords are flying, and the timeline is aggressive.

There’s just one problem: nobody can tell you what they actually want.

You ask questions. Product is confused. The answers contradict each other depending on who you ask. Meanwhile, the clock is ticking on a deadline someone promised without consulting anyone from the team.

This scenario is so common in some companies it barely registers as a dysfunction anymore. It’s just... how things work. But here’s what most engineering leaders miss: this chaos isn’t something to put up with. It’s a gap where leadership is needed.

And if you’re the one who steps in, you get to decide what success looks like.

The problem isn’t the ambiguity

When a project lands on your team with unclear requirements and impossible timelines, the instinct is to push back. Demand clearer specs. Escalate the timeline concerns. Make sure everyone knows this wasn’t your team’s fault.

These are reasonable responses, but they’re also insufficient.

The ambiguity exists because no one above you is willing or able to make decisions. Leaders have a vision, but it’s more a feeling than a plan. The product team passes questions up and gets mixed answers back.

Everyone is waiting for someone else to define the thing.

That someone can be you.

I’m not suggesting you ignore the dysfunction or pretend the timeline makes sense. What I’m saying is that in the absence of clear direction, whoever defines the project first often wins. Not because they have authority, but because everyone else is relieved that someone finally made a decision.

Filling the gap

Early in my career, I witnessed a principal engineer handle a similar situation. Our product manager wanted a “customer dashboard” by end of quarter. No spec. No mockups. Just vibes and a deadline.

Most of us were complaining about the impossibility. He did something different: he wrote a one-page document titled “Customer Dashboard: Proposed Scope”.

It wasn’t a spec per se. It was a starting point. Here’s what we’re building. Here’s what we’re not building. Here’s what “done” means. He circulated it around with a simple message: “Unless there are any objections to it by Friday, this is what we’re delivering.”

He heard some pushback, made some minor adjustments, but mostly people were relieved. The execs finally had something concrete to react to. Product had a baseline to refine. The team had clarity.

The project was delivered. Was it exactly what people had originally imagined? Probably not, because there was no clear image to begin with. But it solved the stated problem, and it landed on time.

He didn’t wait for permission to lead. No manager told him to do that. He just did it.

If you’re enjoying this article, consider subscribing to get:

✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers
🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide

How you can navigate this type of ambiguity

Taking ownership of ambiguity requires a specific approach. Here’s how to do it without overstepping or creating more chaos.

Start with the stated outcome, not the requested features. Stakeholders rarely care about implementation details. They care about results: revenue, efficiency, customer satisfaction, competitive positioning. When someone says “build me a dashboard”, they mean “help me understand something I can’t see right now”. Start there. What decision are they trying to make? What would change if they had this information?

Once you understand the underlying intent, you can propose a scope that actually serves it, even if it looks different from what was originally requested.

Create a “proposed scope” document, not a requirements doc. The language here matters. A proposed scope says “here’s what I think we should build, and why”. It invites feedback.

Keep it short. Include three sections: what we’re building, what we’re explicitly not building, and what “done” looks like. The “not building” section is often the most important, it’s where you draw boundaries that prevent scope creep.

Circulate it with a deadline for feedback. Don’t schedule a meeting to discuss it. Send it with a note: “This is our proposed approach. We’ll proceed with this plan unless we hear significant concerns by [date].” Give people 48-72 hours.

This approach leverages a basic truth about organisations: most people would rather react to a proposal than create one from scratch.

Document the decisions, not just the outcomes. As you get feedback and make adjustments, keep a log. “Stakeholder X requested Y, we agreed to Z instead because...” This isn’t about covering yourself (though it helps). It’s about creating institutional memory for a project that’s being defined on the fly.

When the project finishes and someone asks why you built X instead of Y, you can point to the decision trail. This transforms potential blame into evidence of thoughtful leadership.

What about the deadline?

Ah yes, the arbitrary deadline that someone promised without consulting anyone technical.

Sometimes you can’t move the deadline. An exec made a commitment. A contract was signed. A board was told. The date is fixed.

When that’s the case, your job isn’t to repeatedly explain why it’s impossible. Your job is to figure out what is possible within that constraint.

This is where your proposed scope document becomes essential. If you’ve already defined what “done” looks like, you can have a concrete conversation: “We can deliver features A and B by the deadline. Feature C would push us to three weeks later. Which matters more?”

Give them a choice. Executives hate being told things are impossible. They’re much more receptive to trade-offs they can weigh.

And if you’ve been documenting decisions all along, you have evidence that the scope was negotiated, not arbitrarily reduced. That protects you and your team from the “but I thought you were building everything” conversation later.

Think about it

Most engineering leaders treat ambiguous projects as problems. Minimise damage. Protect the team. Wait for it to blow over.

That’s a reasonable defensive posture. But it leaves you at the mercy of whatever chaos flows downhill next time.

The alternative is to see these moments as leadership opportunities. When no one knows what they want, the person who defines it first shapes reality. When deadlines are arbitrary, the person who frames the trade-offs controls what gets cut. When communication is broken, the person who documents decisions becomes the source of truth.

This isn’t about being political or playing games. It’s about seeing that leadership gaps always get filled, one way or another.

If you don’t step in, someone less prepared will.

Or no one will, and your team will deal with the mess.

You already have the expertise to define what’s technically possible. You already understand the trade-offs better than anyone outside of the team. The only thing holding you back is the assumption that someone else is supposed to make these decisions.

Sometimes no one is. And that’s your moment.

One more thing

None of this works if you approach it with resentment. Yes, the system might be broken. Yes, someone should have defined this before it reached your team. Yes, the deadline is probably unreasonable.

All true. Also: not that relevant to what you do next.

The leaders I’ve watched build remarkable careers aren’t the ones who are best at explaining why things can’t work. They’re the ones who find a version of “yes” that actually makes sense and lead others toward it.

Your team is watching how you handle this. Show them what it looks like to lead into uncertainty rather than just complain about it.