When I started my career at 18, I thought high performance meant one thing:
Delivering exceptional output.
Write more code. Ship faster. Solve harder problems.
For years, that's what I optimized for.
I wanted to be the engineer who could take a task, disappear for a while, and come back with the solution. I wanted to be known as someone who could execute quickly, handle complexity, and produce work that didn’t need much correction.
And to be fair, it worked.
People noticed when I delivered quickly and consistently. I got more responsibility. I was trusted with harder problems. I started to believe that the path was simple: become better technically, move faster, produce more value.
But after almost a decade in software engineering, I've changed my mind.
The engineers I've trusted the most weren't always the fastest.
They were the most predictable.
They managed expectations exceptionally well.
And over time, I've come to believe something that sounds almost backwards:
Performance is downstream of trust.
The lesson I learned the hard way
Early in my career, I thought trust was earned through impressive results.
Today, I think trust is earned through reliability.
The difference matters.
Impressive results can get people’s attention. Reliability makes people want to depend on you again.
At work, that distinction is everything.
Imagine two engineers.
Engineer A:
- Delivers amazing work most of the time
- Occasionally misses deadlines without warning
- Sometimes disappears into implementation for days
- Gives optimistic estimates
- Surprises the team, both positively and negatively
Engineer B:
- Delivers solid work consistently
- Communicates risks early
- Renegotiates timelines when needed
- Rarely surprises anyone
- Makes it easy for others to plan around them
Who would you trust with a critical project?
Most managers choose Engineer B.
Not because they're technically stronger.
Because they're easier to depend on.
And dependency is what trust looks like at work.
This took me a while to understand because, as engineers, we often overvalue the final output and undervalue the experience of working with us.
We think, “The feature shipped. The bug was fixed. The system works.”
But other people are also asking different questions:
- Did I know what was happening along the way?
- Did I feel safe depending on this person?
- Did they communicate when things changed?
- Did they make my job easier or harder?
- Would I trust them with something important again?
That last question is where performance really shows up.
The expectation problem
The biggest insight I've had is that trust is often damaged long before anyone notices.
It happens through unmet expectations.
The tricky part?
Many expectations are never explicitly stated.
Nobody says, “I expect you to review my pull request before the end of the day.”
Nobody says, “I expect you to tell me early if this deadline is at risk.”
Nobody says, “I expect you to test the edge cases before sending this to QA.”
Nobody says, “I expect you to think about the business impact, not just the implementation.”
But when those things don’t happen, trust still decreases.
That’s why I now treat expectation management as a core engineering skill.
Not a soft skill.
Not something extra.
A core skill.
Because engineering is not just about writing code. It is about creating outcomes with other people. And the moment other people are involved, expectations exist.
Some are written in tickets.
Some are discussed in meetings.
Some live in company culture.
Some exist only in someone’s head.
And if you don’t discover them, you can easily fail to meet them.
Step 1: Actively discover expectations
I used to wait for expectations to be communicated to me.
Now I assume it's my responsibility to uncover them.
If someone has an expectation that I don't know about, and I fail to meet it, trust still decreases.
It doesn't feel fair.
But it happens anyway.
This was a difficult lesson for me because, early on, I thought unclear expectations were mostly someone else’s failure.
If the requirements were vague, that was a product problem.
If the deadline was unrealistic, that was a planning problem.
If the team expected something from me but never said it, that was a communication problem.
And sometimes, that’s true.
But as I became more experienced, I realized that waiting for perfect clarity is not how strong professionals operate.
Strong professionals create clarity.
So instead of waiting for expectations to surface, I actively look for them.
Some examples:
- What does success actually look like for this project?
- Is the priority speed or quality?
- How often does this stakeholder expect updates?
- What does "done" mean here?
- What risks are people worried about?
- Is this deadline fixed or flexible?
- Who needs to be informed if the scope changes?
- What would make this feel like a failure, even if the code works?
That last question is especially useful.
Because sometimes the code working is not enough.
Maybe the implementation works, but it creates too much operational risk.
Maybe the feature ships, but it does not solve the user’s actual problem.
Maybe the solution is technically clean, but it takes too long for the business context.
Maybe the work is correct, but the communication around it created stress for everyone else.
The more expectations become visible, the fewer surprises you'll create.
And fewer surprises usually means more trust.
Step 2: Turn expectations into agreements
Once an expectation is visible, only a few options exist.
You can:
- Accept it and commit
- Reject it and own the consequences
- Negotiate
What you shouldn't do is leave it ambiguous.
Unspoken expectations don't disappear.
They sit quietly in the background until someone feels disappointed.
That's what makes them dangerous.
I’ve seen entire working relationships deteriorate because two people had different assumptions and never realized it.
One person thought something was optional.
The other thought it was obviously required.
One person thought the deadline was a rough target.
The other thought it was a firm commitment.
One person thought “done” meant implemented.
The other thought “done” meant implemented, tested, documented, and ready for release.
Nobody was trying to be difficult.
Nobody was acting in bad faith.
They were just operating from different expectations.
That is why agreements matter.
If someone expects a feature by Friday, I don’t want to silently accept that pressure without checking whether it’s realistic.
I need to make the agreement explicit.
Can I deliver the full scope by Friday?
Can I deliver a smaller version?
Can we split the work?
Can we accept some technical debt temporarily?
Can we reduce testing risk?
Do we need to move the deadline?
The goal is not to say yes to everything.
In fact, saying yes too easily is one of the fastest ways to lose trust.
A yes that later becomes a surprise no is worse than a clear negotiation upfront.
Earlier in my career, I sometimes thought being a high performer meant accepting the challenge and figuring it out.
Now I think high performers are careful with their commitments.
They understand that every commitment creates an expectation.
And every missed expectation affects trust.
What this looks like in software engineering
When engineers hear "expectation management," they often think about deadlines.
That's only one part of it.
In practice, unmet expectations often look much smaller:
- Missing a deadline without communicating early
- Ignoring teammates' pull requests for days
- Reviewing pull requests carelessly
- Starting implementation without checking acceptance criteria
- Sending work to QA without testing it yourself
- Saying a task is “almost done” when there is still meaningful uncertainty
- Making technical decisions without explaining the trade-offs
- Waiting too long to say you are blocked
- Assuming product, design, or QA understood the same details you did
None of these are dramatic failures.
That's exactly why they're dangerous.
They slowly reduce confidence.
And confidence is difficult to rebuild once it's gone.
A teammate who waits two days for your PR review may not complain immediately.
A QA engineer who keeps finding obvious issues in your handoffs may not escalate it the first time.
A product manager who gets surprised by a delay may not make it a big deal once.
But these moments accumulate.
Eventually people start working around you.
They check in more often.
They ask someone else for a second opinion.
They stop giving you ambiguous or important work.
They include more people in the process because they are not fully confident things will be handled.
That is the hidden cost.
You may still be delivering output, but your trust level has dropped.
And when trust drops, your impact drops with it.
The expectations nobody writes down
The hardest expectations to discover are cultural ones.
Every company defines "high performance" differently.
At one startup, high performance might mean shipping three experiments this week.
At another company, the same behavior would be considered reckless.
I've worked in environments where the expectation was:
Move fast and accept mistakes.
And others where it was:
Move carefully and minimize risk.
Neither is universally correct.
They're just different expectations.
Some companies reward:
- Business thinking
- Product intuition
- Cross-functional influence
- Speed of learning
- Bias toward action
Others reward:
- Technical depth
- System design expertise
- Engineering excellence
- Operational reliability
- Careful decision-making
If you don't understand which game you're playing, it's easy to work extremely hard while being evaluated poorly.
I've seen engineers optimize for code quality when leadership cared about speed.
I've seen engineers optimize for speed when leadership cared about reliability.
I've seen engineers focus only on technical execution when the company expected them to think more about product and business impact.
I've also seen engineers spend too much time trying to influence strategy when what the team really needed from them was deep technical ownership.
Both groups felt misunderstood.
And in many cases, they were not lazy, careless, or underperforming in an obvious way.
They were simply optimizing for expectations that did not match their environment.
The real issue was that they never discovered the expectations they were being measured against.
That’s why I think one of the most important career skills is learning how to read your environment.
Ask yourself:
- What does this team praise?
- What does this company complain about?
- Who gets trusted with important work?
- What behaviors get rewarded here?
- What mistakes are tolerated?
- What mistakes damage trust quickly?
- Is this environment asking for speed, quality, ownership, influence, or technical depth?
Those answers change everything about what “high performance” actually means where you work.
Discover them.
Don't assume.
What changed for me
I still care deeply about delivering great work.
Great output absolutely matters.
In software engineering, it will always be part of the job.
But today, before I focus on execution, I focus on clarity.
What does this person expect?
What does this team expect?
What does this company expect?
What does this situation require?
Once those expectations are visible, I can decide whether to commit, negotiate, or walk away.
That single shift has probably done more for my career than any technical skill I've learned.
Because it changed how I think about responsibility.
Responsibility is not just taking the task.
It is making sure the task, the expectations, the trade-offs, and the communication around it are clear enough for people to trust you.
Sometimes that means asking one more question before starting.
Sometimes it means pushing back on a deadline.
Sometimes it means saying, “I can do this, but not at the quality level we usually expect.”
Sometimes it means telling someone earlier than feels comfortable that things are not going well.
Those moments are not separate from performance.
They are performance.
Because the people who consistently earn opportunities aren't always the people producing the most output.
They're the people others trust.
And trust is built one managed expectation at a time.
The standard I try to hold myself to now
I don’t think I’ve mastered this.
I still sometimes move too fast.
I still sometimes assume alignment when I should clarify.
I still sometimes focus so much on solving the problem that I forget to communicate the shape of the problem to others.
But I now have a better standard for myself.
Before I commit, I want to understand the expectation.
Before I execute, I want to clarify the trade-offs.
Before I surprise someone, I want to communicate early.
Before I call something done, I want to know what “done” means to the people depending on the work.
That is not as exciting as writing more code or solving harder technical problems.
But it is one of the biggest differences I’ve noticed between engineers who are simply productive and engineers who are deeply trusted.
At 18, I thought high performance meant exceptional output.
Almost a decade later, I think exceptional output is only part of the picture.
High performance is being someone people can depend on.
Someone who discovers expectations instead of waiting for them.
Someone who turns ambiguity into agreements.
Someone who communicates risks before they become surprises.
Someone whose commitments mean something.
Because performance is not just what you produce.
Performance is how much trust your work creates.
