When I walked into my first performance review, I thought I already knew how it would go.
Someone would tell me whether my code was good.
They’d mention the features I’d built.
Maybe they’d comment on my delivery speed, the bugs I’d fixed, or the complexity of the work I’d taken on.
In my head, the review was going to be about one thing.
How good of a programmer I was.
I couldn’t have been more wrong.
The Part I Had Prepared For Lasted About Thirty Seconds
My manager started by talking about my technical work.
Something along the lines of:
“Your code quality has been good. You’ve delivered your work well. Keep it up.”
And then…
We moved on.
That was it.
Months of writing code had just been summarized in less than a minute.
I remember waiting for the detailed discussion.
Surely we’d now talk about architecture.
Or algorithms.
Or design decisions.
Instead, the conversation went somewhere I wasn’t expecting.
Apparently… People Had Been Observing Everything Else
The rest of the review had almost nothing to do with code.
Instead, we talked about things like:
- How I wrote emails.
- How clearly I explained technical ideas.
- How quickly I responded to messages.
- Whether people found it easy to collaborate with me.
- How I communicated during meetings.
- How I handled disagreements.
- Whether I kept stakeholders informed.
- Whether I took ownership beyond my assigned task.
- How confidently I spoke with senior leaders.
- Whether people trusted me to follow through on commitments.
Some of the feedback was positive.
Some of it wasn’t.
But none of it was something I had consciously prepared for.
Because, until that meeting, I genuinely didn’t think these things were being evaluated.
Nobody Tells You This in College
Think about how we’re trained as students.
Assignments are graded.
Exams are graded.
Projects are graded.
The evaluation criteria are usually obvious.
Did your code work?
Did it pass the test cases?
Did you implement the required features?
Communication is rarely part of the score.
Professionalism almost never is.
Then you join the industry…
…and suddenly you’re working in teams of ten, twenty, sometimes hundreds of people.
Your ability to write software is still important.
But your ability to work with people becomes equally important.
Software Is a Team Sport
One thing I slowly realized is that companies don’t hire engineers to write isolated pieces of code.
They hire engineers to help teams build products.
That sounds similar.
It isn’t.
Imagine two engineers.
The first writes excellent code but disappears for three days without updating anyone.
The second also writes excellent code, but keeps stakeholders informed, helps unblock teammates, documents decisions, and communicates risks early.
Technically, they’re both strong.
Professionally, they’re very different.
And over time…
That difference becomes visible.
The Things That Quietly Matter
Looking back, there were dozens of things influencing my performance review that I had never considered.
Things like:
- Can people understand your emails without asking follow-up questions?
- Do your meeting updates make sense to both technical and non-technical audiences?
- When you encounter a risk, do you communicate it early?
- If someone asks for help, are you approachable?
- Do you take ownership of outcomes, or only your assigned tasks?
- Can people rely on your timelines?
- When something goes wrong, do you focus on solving it or defending yourself?
- Do you leave documentation behind for the next person?
- Can senior leaders trust your updates without decoding them?
None of these involve writing code.
Yet every one of them influences how people experience working with you.
And ultimately…
That’s part of your performance too.
The Biggest Surprise
What surprised me most wasn’t that these skills mattered.
It was how much they mattered.
If your technical work consistently meets expectations, it gradually becomes the baseline.
It’s expected.
What often differentiates engineers after that isn’t another programming language.
It’s everything surrounding the code.
Can you lead a discussion?
Can you influence without authority?
Can you explain trade-offs?
Can you build trust?
Can you help a project succeed even when your own task is already finished?
Those are the questions that start appearing.
About AI…
Today, writing a professional email is easier than it has ever been.
Need to summarize a meeting?
An AI assistant can help.
Need to improve the tone of a difficult message?
It can help with that too.
Need to structure a presentation?
Again, incredibly useful.
But here’s something worth remembering.
AI can improve your communication.
It can’t replace your intent.
It can make your writing clearer.
It can’t decide what needs to be communicated.
It can make your presentation more polished.
It can’t decide which risks should be raised.
It can draft an email.
It can’t build trust on your behalf.
Those are still your responsibilities.
The tools have changed.
The expectations haven’t.
If I Could Prepare Differently
If I were back in my final year of engineering, I’d still spend time learning data structures, algorithms, and software engineering.
Those fundamentals matter.
But I’d also deliberately practice things I once dismissed as “soft skills.”
I’d learn how to write concise emails.
How to present ideas clearly.
How to explain technical concepts to non-technical audiences.
How to disagree respectfully.
How to give project updates without overwhelming people with detail.
How to ask good questions.
How to listen before responding.
Because none of those skills suddenly become important after you get promoted.
They’re important from your very first day.
You just don’t realize you’re being evaluated on them.
Looking Back
When I think about that first performance review today, I barely remember the discussion about my code.
What I remember is realizing that my career wasn’t being evaluated through a single lens.
It was being evaluated through dozens of small interactions that happened every day.
Every email.
Every meeting.
Every status update.
Every commitment.
Every collaboration.
Every conversation.
That’s when I understood something I wish someone had told me much earlier.
Writing good code gets you onto the team.
Learning how to communicate, collaborate, and build trust is what helps you grow within it.
Your first performance review probably won’t be about the code you wrote.
It’ll be about the engineer your teammates experienced.
Because companies don’t promote repositories. They promote people others want to build those repositories with.