• Context
• On the use of "narrative"
• The pillars of good self-narrative
• Pillar 1: Begin your narrative through honest attribution
• Pillar 2: Support your narrative with impact and outcomes
• Action ≠ outcome
• Hone your narrative with metrics
• There's power in measurement
• Pillar 3: Compare and reconcile perspectives
• Pillar 4: Own your areas for growth
• Application: Landing roles without checking all the boxes
• Application: Incident post-mortems
• Pillar 5: Tracking data over time
• What tracking looks like for me
• Application: building a new skill over time
• Application: a proud moment
• Wrap up
• Summary
• Footnotes

Context

Talking about yourself and your contributions, be it for self-assessments, pursuing promotions, or just updating your resume, is a part of professional life. And yet for many, myself included, it can feel awkward and potentially self-aggrandizing, especially if you were brought up in a way that extols the virtue of humility.

The challenge: when you can't correctly contextualize your own contributions, you become dependent on external validation. That may come infrequently, leaving you less able to advocate for yourself and more susceptible to burnout.

The goal here isn't to comment on the ills or virtues of how promotions sometimes work in tech. Rather, it's to share thoughts on how to mitigate the awkwardness and improve the effectiveness of talking about yourself when you have to. I'd also like to think of this as part of taking the reins on imposter syndrome.

On the use of "narrative"

What we think and say about ourselves is a form of storytelling. I use the framing of "crafting a narrative" to reflect that. It means deciding what information is most relevant for a given context and audience.

The goal is to be deliberate and effective with those storytelling choices.

The pillars of good self-narrative

It has been my experience that talking about yourself feels most constructive when it's anchored in truth and relevant context.

These are the pillars I've found useful for teasing out and contextualizing those truths:

1. Honest attribution
2. Focusing on impact
3. Comparing and reconciling perspectives
4. Owning areas for growth
5. Tracking data over time

Pillar 1: Begin your narrative through honest attribution

Give credit where credit is due—including to yourself. Take credit for what you've done without diminishing anyone else's contributions. Identifying the roles of contributors in your ecosystem makes it easier to clarify your own role.

It can be helpful to list who you think contributed what (while being mindful of availability bias). As Daniel Kahneman notes in Thinking, Fast and Slow

You will occasionally do more than your share. But it is useful to know that you are likely to have that feeling even when each member of the team feels the same way.

The point is that everyone is susceptible to feeling like they are carrying extra weight. The listing exercise can help to check biases in your perception of your colleagues' contributions. From there, focus on your own.

For instance, even if you're not the one who finalizes a solution, you can acknowledge your role in finding it. You can also give credit to those who drove the fix to completion. Likewise, if you put something up for review, acknowledge the reviewers whose feedback improved the output. Or, if you've reviewed someone else's work, take note of the utility of the feedback in shaping the final solution.

Here's an example:

Along with my teammates, we did {x} → My role was to do {1, 2, 3} → This led to outcome {y}, producing impact {z}.

You could legitimately frame this as:

I contributed to {y/z} by doing {1, 2, 3} on project {x}.

Additionally, sometimes the value of an action or role is only felt by its absence. Preventative work, such as identifying and mitigating risks before things break, often fits into that category. Call out the ways things might have failed or taken longer to diagnose had you not acted.

Pillar 2: Support your narrative with impact and outcomes

Effort alone isn't enough because, unfortunately, effort can be misdirected.

Focusing on impact involves three things: distinguishing your actions from their outcomes, honing your narrative with data, and actively participating in how your work gets measured. Let's go through each.

Action ≠ outcome

Your narrative should make clear the impact of your work. A useful, albeit somewhat cynical, way to frame it:

When you say you've done something, why should anyone care?

How did your actions ultimately support your users, customers, your team, or organization? A reader (including your future self) may have some context, but you can't count on that. Just tell your audience why they should care. Focus on the impact.

The Situation-Behavior-Impact feedback model can be helpful here. Though this model is intended for constructively communicating feedback to others, it's also an effective lens through which to examine one's own work as it encourages succinctly hitting the key elements for being understood.

An example that's a common mistake in large tech companies: citing membership in a working group as impactful work, without explaining the group's objectives or outcomes. The goal of working groups is usually to drive some cross-organizational change. For instance, driving the adoption or standardization of practice across otherwise independent, autonomous teams. Simply being a member doesn't convey what value was generated for the organization, or what part you played in generating it. Spell it out.

The method by which you did something is not the outcome, it's what led to the outcome. The outcome is the value delivered or lesson learned. For example, writing an RFC is an action, not an outcome. The outcome might be that you built shared understanding of a problem and identified the best solution given the constraints. The impact is the benefit derived from solving the problem.

Hone your narrative with metrics

Start by asking:

• Whose experience did you improve?
• How can that improvement be measured?

Try to gather either or both:

• Qualitative feedback. How do those affected talk about it?
• Least formal measure: just ask.
• Most formal measure: conduct a survey.
• Quantitative feedback: How can you count it?
• Least formal measure: rough estimates and extrapolation.
• Most formal measure: statistical analysis, A/B tests, etc.

There's power in measurement

In early 2023, I came across the concept of the legibility trap, and it crystallized something I'd been mulling over since 2021. It's a principle that states:

…as soon as something is quantified, power is given to the measurer.

— Corporate Legibility for Software Engineers, Matt Blewitt

The extrapolation is simple: it behoves the measured to participate in the measurement process. In practice, it's usually a good idea to exchange observations and calibrate expectations with whoever is assessing you. For instance, if you think, or are wondering, whether a particular contribution might tip you into "next level" territory, that's a valid conversation to raise.

This sentiment is again echoed by Blewitt:

Although the power primarily lies in the administrator class, the engineers are not powerless. By participating in the legibility efforts, they have the opportunities to make the measures work for them.

— Corporate Legibility for Software Engineers, Matt Blewitt

Goodhart's Law ("When a measure becomes a target, it ceases to be a good measure") could be positioned as an argument against this. But I'd argue it constructs a valid constraint, not a contradiction. The goal shouldn’t be to game the metrics, it's to make your legitimate contributions legible.

And managers need to take heed as well:

"People generally don't do what they're told, but what they expect to be rewarded for"

— People can read their manager's mind, Yossi Kreinin

As an individual contributor, understanding what your organization rewards helps you align your narrative. As a manager, it's a reminder that the incentives you set—intentionally or not—shape what people prioritize.

Pillar 3: Compare and reconcile perspectives

In practice, participating in measurement means sharing and comparing notes with whoever evaluates you—your manager, review board, or equivalent.

Goal: to maintain a healthy balance between doing and communicating about it.

How much effort should you put into talking about your work versus leaving recognition up to your manager? As with most trade-offs, the ideal is to find a healthy balance. Evaluators, usually managers, often operate at higher levels of abstraction. As a result, they may miss the nuances of individual contributions. Without outside input, this risks letting the Pygmalion effect or confirmation bias shape perceptions.

On the other hand, contributors shouldn't spend excessive time discussing their work at the expense of doing their work. This also risks rewarding the most vocal people rather than the most productive.

Pillar 4: Own your areas for growth

Honest attribution doesn't just apply to wins. To thrive and grow, you must be honest about your strengths and weaknesses. It's about having an honest grasp on where you stand. This is as true for individuals as it is for organizations. You can't be accountable if you aren't accepting responsibility.

Ask yourself:

• What have you learned from failures/mistakes?
• How have you or will you improve the systems involved as a result?
• How can you systematize or scale the things that contribute to success?

The only thing worse than expensive mistakes is repeating them. More on this in You will fail; Congratulations!

Talking about yourself or your contributions doesn't have to feel like "spin" as long as you're not presenting a disingenuous representation.

Application: Landing roles without checking all the boxes

I can recall instances where I applied for, and landed, roles despite not checking every "required" box in the job description. In those cases, I proactively called out in cover letters and subsequent interviews how I planned to close the relevant gaps. While that's not always a viable strategy, I think the earnesty can sway things in your favor when a decision is on the fence. And if you don't land a particular opportunity despite having that growth plan in place, actually following through with the plan makes you better prepared for the next opportunity that does come around.

And if you're tracking this kind of growth in a brag doc (more on that next), you'll have evidence of follow-through the next time an opportunity comes around.

Application: Incident post-mortems

Take this Cline security incident report as an example:

• What have you learned? Answered by the "How did it happen?" section.
• How will systems be improved? Answered by the "How are we preventing it from happening again?" section, which lists changes already made and those in progress.
• And, in line with Pillar 1, the report even acknowledges the person who discovered and reported the issue.

Pillar 5: Tracking data over time

Combat recency bias by keeping running notes—a "brag doc." A brag doc is simply a log of wins, positive feedback, challenges you've overcome, interesting problems you've solved—anything you'd want to remember.

Its contents don't have to be of any significance to anyone but you, the author. And it turns out that stuff is useful for more than you may expect: resume updates, performance reviews, reflecting on growth, even hyping yourself up to take on new challenges.

What tracking looks like for me

I maintain both personal and professional brag docs. I try to jot down stuff on an ad hoc basis as well as on a regular cadence (monthly to quarterly) and incorporate goal setting in addition to tracking.

Application: building a new skill over time

For example, when my team expanded to encompass data engineers and data pipelines, I set the goal of building at least basic data engineering competencies within 6 months. I broke that down to incremental actions, each contributing progress towards the goal:

• Month 1: Identify the skills gap. Find relevant training. Sign up.
• Month 2: Take relevant training. Share learnings/notes, since sharing learning is a valuable step for validating and reinforcing knowledge.
• There's a brag doc entry for completing a course and making suggestions to the course materials pertaining to setup gotchas.
• Month 3: Apply learning to production system(s) via low hanging or maintenance tasks.
• There's a brag doc entry for building my first data workflow!

Application: a proud moment

There was a two-week stretch in which I built a data pipeline for one project, shipped backend and web work for another, and stayed on top of my management responsibilities. The fact that I could juggle all of that without dropping balls or feeling like I was grinding was itself evidence that the systems were working — the kinds of systems I describe in On effectiveness and On scaling engineering teams.

Applying the framing from Pillar 2 (impact and outcomes), this entry could be thought of as:

• Action: I took on essential-but-low-complexity feature work for DE, BE, Web (think: CRUD + unit tests)
• Outcome: projects shipped on time without anyone needing to pull nights or weekends; reasonable delivery expectations were set and met
• Impact: that allowed DE and BE engineers to focus on areas of higher complexity or uncertainty without context switching

Perhaps these entries will provide no benefit beyond the intrinsic value of journaling. But perhaps, as with my last few promotions (where I pulled the majority of content from my brag doc), they could serve as reference points for supporting my narrative of readiness for the next level or competence at my current level.

Wrap up

For professionals, the game is twofold: be effective by doing the right things well, and make sure the right people understand it in order to keep the lights on. A good manager will support this process, but each person should also be an active participant—finding an authentic (i.e., non-gross-feeling), low-friction way of contextualizing and communicating about their work. If you read this through a cynical lens, it's about chasing comp and promotions. If you read it through the intended lens, it's about understanding your perspective, external perspectives, and bringing them into alignment.

In On effectiveness, I offered the definition that, "Being effective means doing the right things well." If this post adds anything to that, it's a corollary:

Summary

Key principles of effective self-narrative:

• Focus on honest attribution, giving credit where due—including to yourself.
• Emphasize impact and outcomes rather than just actions or efforts.
• Support your narrative with both qualitative and quantitative insights.
• Own your areas for growth. Know how you can improve and how you plan to do so.

Some practical tactics:

• Maintain a "brag doc" to track achievements and combat recency bias.
• Participate in the measurement process to make measures work for you.
• Compare and reconcile perspectives with managers to ensure fair recognition.
• Craft a narrative that aligns the value you generate with your organization's values (which requires understanding what your organization actually values).
• If those start to drift apart, the output of your narrative work can help guide your next steps.

Footnotes

• It is awkward to not only talk about yourself, but to talk about talking about yourself. Which is why I sat on my initial draft since 2021, after a promotion to Senior Engineer but before a transition to Engineering Manager. Since then, I’ve iterated and shared on an ad hoc basis with peers as it’s become relevant to them–usually once every year or two. With each share, people I care about have taken something useful away. That alone warrants overcoming the fear of cynical feedback to finally post publicly.
• AI usage: Level 1, proofing. The initial draft that I plugged into Claude was ~2300 words. After working through the feedback, it became ~2200 words. As I mention in On writing in the age of AI, "It takes more effort to publish fewer words."