Personalized Coaching for Senior, Staff, and Principal Engineers by a former Staff Engineer
A newsletter for Senior+ engineers doing strong work but not always seeing it translate into recognition, broader scope, or career momentum. Also useful for engineering leaders who want clearer language for developing these skills in their teams. Subscribe for thoughtful essays on influence, visibility, self-advocacy, and Staff-level growth.
You may have noticed this edition is arriving a week late. I'd just returned from Japan and was super jet-lagged last Sunday. On the upside, here are some cute Japanese wild macaques from the Arashiyama forest at the summit! 🐒
This edition also includes a meaningful update from my world: an unexpected invitation to speak at QCon San Francisco this November! More on that toward the end.
I'm glad to be writing to you again.
Four Japanese macaques eager to get food from humans at Arashiyama Monkey Park. We were inside the enclosed feeding station while they roamed freely outside!
With many companies preparing to kick off their annual performance-review cycles, I've been thinking about something that took me a long time to understand in my own software engineering career.
Being a strong engineer and knowing how to make my contributions visible and recognized required different skill sets, with some overlap.
For years, I believed that working hard, solving difficult technical problems, writing high-quality code, and being dependable would naturally lead to strong performance reviews and career growth.
Those attributes served me well. But they didn't automatically enable the organization to accurately evaluate the work I was doing.
And that gap became particularly clear during performance review season.
Like many engineers, I approached my self-review by looking back through Jira tickets, GitHub pull requests, design documents, and project milestones. I reconstructed what I'd worked on, how much I'd accomplished, and which problems were particularly difficult.
It was a reasonable starting point. After all, those were the most tangible records of my work.
But those records only told part of the story.
Engineering excellence and making your impact visible
Making the impact of your engineering work visible requires understanding the broader outcomes it enables, recognizing your specific contribution to those outcomes, and communicating evidence of your capabilities in a way others can evaluate.
It's possible to become increasingly capable as an engineer without receiving recognition and rewards commensurate with your growth.
I see this frequently in my coaching work. Engineers can explain the technical details of a project with impressive precision, but struggle when asked what they achieved, why the achievement was significant, or what their contribution reveals about how they operate.
Sometimes, they don't fully know the answers themselves.
What your performance review is evaluating
Even though performance reviews vary across organizations, a useful way to think about your review is through two questions:
1. What value did you create for the organization?
2. What capabilities did you demonstrate while creating that value?
These questions reveal different aspects of your performance.
A valuable outcome doesn't automatically explain what you personally contributed. And describing your individual contribution doesn't necessarily reveal the judgment, leadership, or other capabilities behind it.
Value created: What the organization gained
Imagine an engineer writes the following in their self-review:
I designed and implemented a tracking API for our notification platform.
This describes the work accurately. But how much can a reviewer infer about its significance?
Now consider the broader situation.
The engineering organization had developed a new notification platform capable of sending emails to millions of customers. However, product teams were reluctant to adopt it because notifications sent through the platform couldn't be reconciled with the company's standard analytics system.
Without that integration, teams couldn't confidently measure the outcomes of their email campaigns.
The tracking API removed an important barrier to adopting the platform.
Here we can distinguish three layers:
Work completed: Designed and implemented a tracking API.
Value created: Removed a barrier that prevented product teams from adopting a shared notification platform.
Individual contribution: Identified the integration gap, proposed a solution, and implemented the API that addressed it.
All three describe aspects of the same project, but each provides different information.
The first tells us what was delivered. The second explains the value it unlocked for the organization. The third identifies the engineer's role in delivering that value.
Individual contribution connects the value created for the organization with the capabilities you demonstrated in creating it.
This distinction becomes especially important in collaborative engineering work.
A successful migration might involve a dozen engineers across multiple teams, each with their own tech leads. Everyone contributed to the outcome, but their contributions were not identical.
Some designed critical components. Others uncovered hidden dependencies, challenged an unsafe rollout strategy, resolved cross-team disagreements, or prevented a costly failure.
Your goal is to represent your specific contribution accurately, without minimizing it or claiming credit for others’ work.
Understand the full impact of your own work
Paradoxically, being closest to the implementation doesn't necessarily give you the clearest view of its downstream impact.
Imagine improving a deployment pipeline and measuring success through deployment time and failure rates.
Those improvements may be meaningful on their own. But perhaps your work also reduced coordination overhead across multiple engineering teams, made releases less stressful, or enabled product teams to ship changes more frequently. That's the broader value your work created for the organization.
If you never speak with the engineers and teams benefiting from your work, some of those outcomes may remain invisible to you.
This connects to something I've discussed in earlier editions: the importance of technical, organizational, and business context.
When preparing your performance review, it's worth revisiting that context, especially through conversations with people who experienced the outcomes of your work from a different perspective.
You may discover achievements you hadn't thought to include.
Capabilities demonstrated: What your work reveals about you
There's a second dimension that's easy to overlook in your self-review:
What does your work tell someone about the engineer you've become?
Consider two engineers working on reliability improvements.
One receives a well-defined project, designs a technically sound solution, navigates implementation challenges, and delivers successfully.
Another notices an emerging reliability risk before it has become a prioritized project. They investigate its causes, evaluate the tradeoffs, build alignment across teams, and lead the effort to address it.
Both engineers may deliver valuable outcomes. But their work provides very different evidence of how they exercise judgment, take ownership, navigate ambiguity, and influence others.
As we've explored in earlier editions, engineers are expected to navigate an increasingly complex playing field as they grow in seniority, making higher-stakes decisions with broader organizational consequences.
This is why simply listing completed projects can undersell your capabilities.
Leverage the career ladder
Your engineering career ladder can provide a useful reference here. It describes the expectations associated with your role, including capabilities that may be harder to evaluate through deliverables alone.
For example, technical judgment might be demonstrated through the tradeoffs you evaluated under difficult constraints.
Leadership might be visible in how you helped other engineers make decisions or navigate a complex initiative.
Organizational influence might show up in how you brought stakeholders with competing priorities toward a shared direction.
Your self-review should help connect those capabilities to observable evidence from your work.
Make your growth visible
Think about feedback you received six months or a year ago. What have you changed since then?
Perhaps you've become more effective at facilitating architecture discussions, engaging stakeholders earlier, or making technical decisions with a clearer understanding of organizational constraints.
These changes also deserve attention because they demonstrate your development, even when they don't correspond neatly to a single deliverable. By making this growth visible, you help your organization recognize how you're progressing toward the next level.
Make the most of an imperfect process
It’s true that the evaluation process in complex organizations can be inconsistent and unfair. Managers, organizational priorities, calibration practices, and opportunities all influence how performance is assessed.
While you cannot control these aspects, you can influence how clearly your contributions are understood. A thoughtful self-review gives your manager and other reviewers stronger evidence to work with.
Put This Into Action
I'd love to invite you to the next Uncharted Lab: Make Your Impact Count in Performance Reviews, where we'll apply the framework from this edition to a meaningful project from your current review cycle.
We'll also go beyond the self-review to explore how your organization evaluates performance, how to use the review conversation to shape your future growth, and why waiting until review season to seek feedback can work against you.
Join me on Thursday, November 5, at 12:00 noon Pacific Time, for a free, interactive session featuring a short lesson, an individual exercise, group discussion, and live coaching.
In early summer, I submitted a few talk proposals to LDX3 London. One of those proposals caught the attention of a QCon track host, who unexpectedly invited me to speak at QCon San Francisco this November!
In Legacy as Leverage: How Brownfield Work Builds Technical Judgment, I'll explore how architectural decisions, organizational boundaries, and technical constraints accumulate over time, and how understanding their consequences can make us better engineers and technical leaders.
The topic is personal to me, having spent a few years working on legacy systems that I once thought were holding my career back.
I'm grateful for the opportunity to bring these ideas to another audience, especially at a deeply technical conference I've long respected and never thought I'd speak at.
How Can I Help?
If this edition resonated, I help engineers navigate these exact challenges through 1:1 coaching and a live course on behavioral interviews.
If you’re interested in exploring whether structured coaching support would be a good fit, reply to this email to ask about a 60-minute Clarity & Strategy Session. I’ll follow up with next steps.
If you’d like more essays like this, you can read past editions here.
You’re receiving this email because we connected in some way: through coaching, a discovery or complimentary call, a 1:1 conversation, a community, a talk, or resources and workshops I’ve shared on behavioral interviews, career growth, and technical leadership. You can unsubscribe at any time.
Personalized Coaching for Senior, Staff, and Principal Engineers by a former Staff Engineer
A newsletter for Senior+ engineers doing strong work but not always seeing it translate into recognition, broader scope, or career momentum. Also useful for engineering leaders who want clearer language for developing these skills in their teams. Subscribe for thoughtful essays on influence, visibility, self-advocacy, and Staff-level growth.