I think I made a communication mistake recently.
One of my projects has been stuck in a cycle of revisions for almost two quarters. I found myself thinking about it even after work. We had already invested so much time, but I still couldn’t tell whether it would ever launch. I kept asking myself the same question: are we looking at sunk cost, or is it still worth investing another quarter?
Eventually I told my manager that all this uncertainty had been keeping me up at night.
My manager later escalated the conversation to my director.
Nothing dramatic happened, but afterward my tech lead gave me some feedback that I think I’ll remember for a long time.
- If leadership rarely hears from you, every conversation carries more weight.
My director doesn’t hear from me very often. That means each interaction contributes disproportionately to the impression they have of me.
If one of the few things they hear is that I’m anxious or losing sleep over a project, that’s likely to become part of how they remember me. It doesn’t mean I should pretend everything is fine. It just means I should make sure they also hear about the progress I’m making, the problems I’m solving, and the things that are going well.
- The project can have problems without me having problems.
This was the biggest lesson.
Projects become messy. Requirements change. Priorities shift. Sometimes you simply don’t know whether an investment will pay off.
Those are project problems.
My responsibility is to surface those risks, explain the trade-offs, and recommend what I believe is the best path forward.
What I didn’t realize was that by talking about my own anxiety first, I may have unintentionally shifted the focus from “this project is in a difficult situation” to “I’m struggling with this project.”
Those are very different messages.
If I think we should stop a project because the expected return no longer justifies the investment, that’s a business recommendation.
If it sounds like I want to stop because I’m overwhelmed, it may be interpreted very differently.
The recommendation is the same.
The framing isn’t.
- I need to separate project outcomes from my own identity.
This was probably the lesson I needed to hear the most.
Some projects fail.
Some never launch.
Some turn out to have been the wrong bet.
That doesn’t automatically mean the engineers on the project failed.
If I want to grow in my career, I obviously need successful projects and measurable impact over time. But I don’t need every single project to succeed. That’s impossible when you’re working on uncertain problems.
What matters is making good decisions with incomplete information, communicating risks honestly, and knowing when to keep pushing versus when to recommend stopping.
I’m still learning to separate the success of a project from my own sense of success.
The project can fail.
That doesn’t mean I failed.