Software engineering, leadership, and career growth
My Senior Engineer transition was a complete disaster.
Not because I lacked skills.
Because I showed up like I already had the answers.
A manager I used to report to introduced me as the ‘star hire.
Day 1, my mindset was simple:
“I’ve seen this before. I know what to do.”
I did exactly what I thought seniors were paid to do:
- Proposed fixes before understanding the why
- Suggested “better” patterns without knowing the trade-offs
I thought I was adding value.
I was actually eroding trust.
Within weeks, the signs were there:
- Feedback slowed, then stopped
- Discussions turned defensive
- I stopped getting pulled into key decisions
Then someone said it plainly:
“It feels like you’re solving a problem we don’t have.”
They were right.
I lasted 8 months before moving teams.
In my next role, I tried something different:
For the first 60 days, I didn’t focus on improving things.
I focused on mapping how things actually worked.
Instead of jumping to solutions, I asked:
- What trade-offs led to this design?
- What’s been tried and failed before?
- What’s too risky to change right now?
I also did something uncomfortable:
I asked engineers to explain things I didn’t understand.
Not to test them.
To learn from them.
Something changed.
People opened up.
Context surfaced.
Problems made more sense.
And once I understood the system—
influence came naturally.
I wasn’t pushing change anymore.
I was part of it.
I stayed on that team for 8 years.
The difference wasn’t my technical skill.
It was the trust I built by being curious instead of impressive.
Here’s what I got wrong the first time:
Seniority isn’t about having better answers.
It’s about earning the context that makes better answers possible.
Teams don’t resist change.
They resist people who try to change things
before understanding them.
If you’re stepping into a new role:
Don’t optimize for being impressive.
Optimize for being curious.
What’s the fastest way you’ve seen a strong hire lose a team’s trust?