Dear diary, today I learned that
I have to learn how to live with ambiguity. It’s part of my job to make sense out of things.
Walking the tightrope
Ambiguity has become my default state. I feel it more often than anything else. It’s like walking a tightrope: every step forward requires balance.
As a lead engineer, I’m expected to know. But the reality is: more often than not, I don’t.
- Should we introduce technical debt now to ship a feature faster, or will it come back to bite us in six months?
- What I said on the 1:1 call – was it the right thing? How did the person perceive it? Even if they say “it’s fine”, do they really mean it?
- When different stakeholders ask me, “Will this feature be live by date X?”, how can I answer if I don’t even know the final scope?
And of course, I can’t just say “I don’t know what I’m doing”. Would you trust a leader who says that?
The Maze of Choices
Sometimes, discussions feel like running in circles indefinitely. Every choice depends on another choice. Change one assumption, and half the plan collapses.
On top of that let’s add that the industry is changing, and we have to constantly learn new things. How do RAGs, evaluators, LLMs fit into the existing architectures? How the solution is going to behave in a few years? Is the 3rd party tool to manage prompts even going to exist or would we have to perform a migration soon?
What helps me deal with it
I’m not immune to this uncertainty. But I also want to stay authentic as a leader. I don’t aim to lie that I know what I’m doing. I want to build confidence first to bring more certainty to others.
These are some practices that keep me sane:
- Ask for feedback – especially about expectations. Half of ambiguity is just misalignment.
- Discuss rationales with my manager – not to get answers, but to sharpen my own reasoning.
- Break work into small pieces – list out the steps, the dependencies, the blockers. (I wrote about it here).
- Name the decisions explicitly
- I apply here the learnings from The Staff Engineer’s Path – make the work easier for people you’re waiting a response from. E.g. list options with pros and cons, ask specific questions, to make it even more likely I receive answers.
- Identify learning gaps – admit where I don’t know enough, then go learn (right now it’s AI engineering)
- Make some space to think – and the smart ideas will start popping up as well as challenges I haven’t thought about before
- I wrote about it here already – Thoughts need space to grow
- Find analogy – describing abstract concepts becomes easier when you compare it to less abstract objects – e.g. the bucket metahpor from the previous LED’s entry
- Write it down – I often get clarity when trying to write dow and explain the issue.
- Remember it’s part of the job – James Stanier put it beautifully on the Tech Lead Journal podcast: “If you’re so sure about something, talk to more people, seek more opinions, get people to challenge you, because you probably have missed something. Nothing is ever very easy or straightforward.”
It’s a feature
One more time, it’s not a bug—it’s a feature of leadership. The role of a lead engineer is not to eliminate uncertainty but to make it navigable for others. My job is to take the fog, sketch some maps, and help the team move forward.
