TL; DR:
Don't keep reliving the worst case scenario.
Imposter syndrome will keep coming up -- don't run from it.
Check out the live stream on Monday, September 8th at 7:00 PM Pacific (or watch the recording)!
Turning Ambiguity Into Growth
If you stay in software engineering long enough, you’ll eventually get put in charge of something that feels bigger than you. A project with vague requirements. A responsibility that feels way out of your depth. A set of expectations that nobody has written down clearly, but everyone is looking at you to figure out.
That’s stressful.
If you’re like many of the engineers that I’ve spoken to, it’s the kind of stress that can eat at you before the work even begins. You wake up feeling sick. You replay the worst-case scenario in your head. You start imagining failure before you’ve written a line of code or had a single planning meeting.
This article is for that moment.
I’ve been there. I’ve managed teams at Microsoft and led projects where the only thing I felt sure about was that I didn’t know what I was doing when I started. I want to share what I’ve learned about handling that stress -- not by pretending it doesn’t exist, but by reframing what it means to lead, and by practicing habits that make it survivable, even rewarding.
Why Ambiguity Shows Up As Stress
As a junior engineer, most of the tasks handed to you are well-defined. You’re fixing a bug, implementing a function, building a feature someone else has already broken down. The path is laid out. Your job is execution.
As you get more senior, that changes. Instead of problems with a clear shape, you’re handed spaces where problems live:
“Reduce downtime.”
“Make this system scale.”
“Help the team improve code quality.”
These aren’t Jira tickets -- they’re vague, messy goals that need to be clarified, scoped, and solved. You get to go figure that out.
That transition is where stress creeps in. Because ambiguity feels like danger. If you can’t even define the problem, how can you possibly solve it?
Actionable Tip: When the stress first hits, stop and ask yourself: Is the problem here the work itself, or the fact that I don’t understand the work yet? Most of the time, the stress is a signal that you need clarity, not proof that you’re incapable.
Remember: Someone Believes In You
It’s easy to slip into impostor syndrome when you’re handed a big, undefined responsibility. You think, “Why me? Jimmy or Suzie could handle this. I’m not ready.”
Here’s the truth: if someone gave you this project, at least one person believes you can handle it. Otherwise, it wouldn’t be on your plate. They would have handed it to someone else.
That doesn’t mean they expect perfection. It means they trust your judgment, your track record, and your ability to figure things out as you go.
Actionable Tip: Write this down before you start: “I was given this project because someone believes I can do it.” Keep it visible on your desk or in your notes. When the stress spikes, revisit it. It’s a tangible reminder that you’re not alone in your belief.
I know you're not going to remind yourself unless you write it down... so write it!
Start With Clarity, Not Solutions
One of the biggest traps new leads fall into is rushing to solutions. You’re given an ambiguous problem and your stress brain says: I need an answer now. So you guess, you build, and you pray it’s right.
Slow down.
Before you can solve anything, you need to truly understand the problem. That means asking questions, mapping out the space, and talking to stakeholders until the fog lifts.
When I first joined Microsoft, my assignment was to reduce downtime in Office 365 deployments. I had never deployed anything at scale. I had only built desktop software in my previous role. My first instinct?
Panic.
But the real first step was learning: What does “downtime” mean in this context? Why does it matter? How do we measure it today? Those questions turned fear into concrete starting points.
Actionable Tip: Build a Checklist:
Who owns the current pain point?
What exactly is broken or inefficient?
Why does it matter to the business or users?
How are we measuring it today?
Who are the subject matter experts I can learn from?
Your job isn’t to have answers on day one. It’s to ask better questions than anyone else has. It's to get moving in the right direction.
Stop Living Out the Worst Case
A lot of stress doesn’t come from the work itself. It comes from the imaginary stories we play in our heads:
“I’m going to fail.”
“I’m going to look stupid.”
“I’ll get fired.”
None of those things have actually happened. But your brain is living them as if they’re real. You’re running a simulation of failure every morning before work.
I’m guilty of this too. I’ve lost sleep replaying conversations that never happened -- it's just as bad as replaying the ones that have happened and you can't change. But here’s what I’ve had to remind myself: stress built on imagined scenarios isn’t helpful data. It’s wasted energy. I talked about this topic and others on this vlog entry on Code commute:
Lean On Your Network
Another mistake that's easy to make is thinking that leadership means solving things alone. Got a vague project? Lock yourself in a room, figure it out, and then impress everyone with the answer!
That’s not leadership. That’s isolation.
Every significant project is solved with people, not by individuals. You need to ask questions, pull in experts, and admit when you don’t know. Your credibility doesn’t come from pretending to be the smartest person in the room. It comes from building trust and creating progress.
Actionable Tip: Map out your support network for each project:
Stakeholders: Who cares most about the outcome?
Subject Matter Experts: Who has deep knowledge of the systems?
Allies: Who can you safely admit confusion to?
Mentors: Who has done something similar before?
If you can’t name at least one person in each category, you’re carrying too much on your own.
Practice Transparency
When I switched teams a few years into Microsoft, I inherited three sub-teams all within an area I wasn't familiar with yet. I didn’t know any of these at a deep professional level. Pretending otherwise would have destroyed trust.
So I said, “I don’t know all of this yet. I will have questions. I’m here to help you succeed, but I need your help too.”
That honesty did more to earn credibility than pretending I was already an expert. People don’t need their leads to know everything. They need their leads to be clear, open, and supportive.
Actionable Tip: In your next kickoff or sync, try this (or find your own words for it):
“Here’s what I know. Here’s what I don’t. Here’s what I’m going to do to close the gap.”
That simple transparency builds trust faster than false confidence.
Celebrate Progress, Not Just Success
Sometimes, you’ll grind through a project stressed the whole way. And when it’s done, your brain moves straight to the next crisis. You never pause. You never let yourself feel the win.
That’s dangerous. Because if every project just feels like survival with no recognition, you’ll burn out fast.
Actionable Tip: Try to consider the small wins along the way. Often large projects will have many smaller milestones -- celebrate them. Don't wait until the very end at the finish line to be the first time you recognize any of your accomplishments.
Stress Is Normal, Growth Is Optional
Here’s the thing: stress never disappears. Each new level of responsibility brings new ambiguity, bigger stakes, and fresh anxiety. What changes is your comfort with it.
Every time you face ambiguity and push through, you build a track record. Not just for your manager, but for yourself. You start to remember: I’ve done this before. I can do it again.
That confidence doesn’t kill stress, but it reframes it. Stress stops being a sign of danger. It becomes a sign you’re growing.
Actionable Tip: Keep a written record of your accomplishments. After each ambiguous project, write:
What scared you at the start
What you did to push through
What you learned
Flip back through it when impostor syndrome hits. The evidence of your own progress is the best antidote.
Final Thoughts
Managing stress as a tech lead isn’t about eliminating stress. It’s about reshaping it. Ambiguity means trust. Discomfort means growth. Fear means you’re stepping into something that will stretch you.
Don’t run from that. Lean into it. Ask the questions. Build the network. Celebrate the survival.
The stress won’t vanish. But over time, you’ll realize it’s not holding you back. It’s carrying you forward.
Join me and other software engineers in the private Discord community!
Remember to check out my courses, including this awesome discounted bundle for C# developers:
As always, thanks so much for your support! I hope you enjoyed this issue, and I'll see you next week.
Nick “Dev Leader” Cosentino
social@devleader.ca
Socials:
– Blog
– Dev Leader YouTube
– Follow on LinkedIn
– Dev Leader Instagram
P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!