The no BS guide to show your impact with XYZ Framework

How many times have you lost a promotion because you weren't able to describe your contributions to a project? Or even worse, has it never happened that you couldn't quickly present the impact you had with your last team during an interview?

I know the feeling, because I felt it more times than I'd like to admit.

For most of my career all that mattered was the quality of my code and how clear I was able to produce commits and documentation for my team.

While this made me "famous" around colleagues, it didn't help to spread my name in management. The people my promotion depended on almost didn't even know that I existed.

And this is mostly because I didn't pick up the habit to track my contributions, relying only on my memory. And it didn't help much.

Keeping track of your contributions is probably the most important aspect of your work as engineer, otherwise you'll be among the 90% that suffer from memory fade.

You can't expect your manager to check the PR description that you crafted for your team.

That's why in this article I want to talk to you about a framework, that Google used internally, that will help you not only to pick up the habit of keeping all your contributions in the same place but will help you translate our tech-jargon into clear goals relevant for the business.

Aren't frameworks full of fluff?

Let me just say: not everyone.

As a fellow engineer I do share with you doubts about the need to apply a framework while describing our successes, but the thing is similar as when we learn a new language, if we're serious about our career growth we have to adapt the way we share our accomplishments.

Let's put this into practice. Read this out loud: "Improved search feature."

As an engineer I am pretty sure your first question was "how?" We are more curious about what the improvement was and how it was applied, than the business implication behind it.

And that's fine, you're an engineer after all and you want to learn new things and help your teammates. But when you want to share your wins among other departments you have to write the information in a way that is gonna be easily understandable by them. Try to read the following: "Reduced search latency by 65%, increasing user retention 12% by implementing Elasticsearch caching."

How does it sound? Do you think that even less technical people will be able to understand the impact of your work?

I think so.

Let's dive a bit deeper into the structure of this message.

What's this XYZ?

The XYZ formula is a three-part structure for describing impact: Accomplished [X] as measured by [Y] by doing [Z]. Google popularized it. Engineering teams at Dropbox, GitLab, and most high-growth startups now expect it in performance reviews and resumes.

Here's why it works: it forces you to translate tasks into outcomes with proof attached.

Most engineers list what they did.

High-performers list what changed.

And not what changed in terms of the amount of lines, or metrics that are tightly connected with our code. High-performers are able to understand what the business really takes care of. In the example above, they don't care if you implemented Elasticsearch caching, their main interest goes to the increase of user retention that this implementation was able to bring. You added Elasticsearch almost for fun, and to let other departments know that you master such technology.

The Formula in Practice

Let's try with another example. You've just implemented new CI templates and parallelization to cut deployment times, how would you add it in your brag document?

"Worked on CI/CD improvements to speed up deployment time."

That's it? Outside your team, who even knows what a CI is?

But the thing is that you have to make these accomplishments understandable from someone that doesn't know our entire tech stack. So in order to do so we have to think about how we can implement the XYZ formula, here's how I reason about when I want to translate one of my contributions in a way that everyone can understand.

Now that we have done this exercise, making it more understandable is the easy part: "Cut build times 25% by introducing CI templates and parallelized jobs, enabling a 2x increase in daily deployment frequency."

Compare that to the previous, don't you think that's a great improvement?

Why This Matters for Performance Reviews

If you are working in a company that is taking care of you and wants to know how you improve inside the company, you most likely have at least a couple of performance reviews per year.

The issue is that managers handle dozens of engineers at once. Your job is to hand them a structured, evidence-based narrative they can defend in that room.

The "Chores vs. Wins" Problem

Engineers often write: "I was busy this quarter: fixed bugs, attended standups, reviewed PRs."

Management hears: "This person performed their job description."

What they need to hear: "This person moved the needle on company goals."

That's your main goal with a brag document: show off how you helped the company in reaching their goals task after task. Letting them know that you mastered a new framework is not relevant for the type of goals they have to track.

Finding the right balance with the 70/30 Rule

I know what you're thinking: I can't list all my contributions following this formula, it is simply impossible.

And I do agree with that, part of our work needs to live in learning. We need to learn new concepts, frameworks or simply keep up to date our knowledge; otherwise we will be outdated in the next few years.

What I am trying to say here though is that we need to find the right balance, and as in many other cases the Pareto Principle here plays a great role (even though we changed it slightly).

Here's how to balance an effective self-evaluation:

• 70% concrete wins with metrics
• 30% genuine growth areas

Connect both to quarterly objectives or team KPIs. This shows you're not just completing tasks but driving the company's mission.

Quantifying "Glue Work"

As we just stated, not all impact is quantifiable—especially because not all impact happens in code.

During your career you'll frequently find yourself mentoring colleagues, improving processes, or participating in cross-functional initiatives. These aren't easy to quantify, but if you want to make a good impression you have to do it anyway.

Here's how to think through each type and transform vague descriptions into XYZ bullets that actually land.

Mentorship

Let's say you spent six months helping a junior engineer get up to speed. Your instinct might be to write:

Before: "Mentored junior team members and helped them grow."

Nice. But grow how? And who cares?

Ask yourself: what changed because of your mentorship? Did they ship features independently? Did they start reviewing others' code? Did team velocity improve once they stopped blocking on you?

After: "Mentored 2 junior engineers to independent project ownership through weekly 1:1s and pair programming, increasing team project completion rate 20% as they began owning features without escalation."

Notice what happened here. The Z (weekly 1:1s, pair programming) is the activity everyone does. The Y (20% completion rate increase) and X (independent ownership) are what actually matter to management.

Process Improvements

You automated something boring that was eating everyone's time. Your first draft:

Before: "Built automation scripts to improve team efficiency."

Okay, but what was the cost of not having automation? And what did "efficiency" actually mean?

Think in terms of time returned, errors prevented, or frustration reduced. Can you count hours saved per week? Did error rates drop because humans were removed from the loop?

After: "Automated vendor payment reconciliation workflow, eliminating 40 man-hours of manual data entry monthly and reducing payment processing errors 15%."

The Z here is specific (vendor payment reconciliation). The Y has two metrics—hours saved and error reduction. The X is implied: more reliable operations with less manual labor.

Cross-Functional Coordination

You played the diplomat between teams that don't usually talk to each other. Your default description:

Before: "Facilitated communication between engineering and product teams."

Everyone says this. It means nothing.

What was the actual outcome? Did a project ship faster because you resolved blockers? Did feature quality improve because requirements got clarified earlier? Did you prevent a deadline slip?

After: "Coordinated launch initiative between engineering, product, and design teams by implementing shared project dashboard and weekly syncs, delivering high-priority mobile feature 2 weeks ahead of schedule with 30% fewer post-launch bugs."

Here the Z shows you didn't just "facilitate"—you built infrastructure (dashboard, syncs). The Y has speed (2 weeks early) and quality (30% fewer bugs). The X is hitting a business deadline that mattered.

The Pattern for Glue Work

Every time you do work that doesn't produce a commit, ask three questions:

1. What was broken before? (Context for why your effort mattered)
2. What did you actually build/change? (Your Z—specific tools, processes, structures)
3. What became possible after? (Your X and Y—time saved, people unblocked, risks avoided)

Glue work only looks invisible if you describe it vaguely. Get specific about the mechanism you created and the downstream effects it produced.

Building Your Brag Sheet

Don't wait for review season. Track monthly:

1. Projects completed → What metrics changed?
2. Technical decisions → What alternatives did you reject and why?
3. Collaboration → Who did you unblock? What processes did you improve?
4. Mentorship → Who leveled up because of you?

Pull from: calendars, project trackers, commit history, incident post-mortems, Slack threads where you solved problems.

Quick Reference: XYZ Builder

Template: Accomplished [X] as measured by [Y] by doing [Z]

Before: "Improved search features"

After: "Reduced search latency 65% (Y) by implementing Elasticsearch caching (Z), resulting in 12% improvement in user retention (X)"

Checklist for every bullet:

• [ ] Starts with outcome (X), not activity
• [ ] Includes a number (Y): %, $, time, count
• [ ] Describes specific technical action (Z)
• [ ] Could pass through an ATS without buzzwords
• [ ] Answers "so what?" without requiring explanation

The Bottom Line

The XYZ framework isn't resume decoration; it's a professional habit. Engineers who master it don't just do good work; they make that work legible to the people who decide on promotions, budgets, and hiring.

Start with your last three projects. Rewrite them as XYZ bullets. Put them in front of a manager or peer. If they ask follow-up questions, your Y isn't strong enough. If they glaze over, your X isn't concrete enough. Iterate until the impact is undeniable.

A Tool for the Habit

Here's the problem: you won't remember the details three months from now. That 65% latency improvement? You'll recall you did something with search, but the exact metric, the technical approach, the business outcome? All of it fades.

I've been there.

That's actually why I started building CareerCraft.ing.

It's a personal vault that captures your wins as they happen; PRs, commits, mentorship moments, process improvements. An MCP server extracts impact from your workflow only when you trigger it. No background scraping, no surveillance. Then the XYZ engine transforms your raw notes into the kind of bullets that actually get read.

Because tracking your career shouldn't be another chore. It should be automatic.

I will release this tool in Q2. In the meantime, use the XYZ framework to build your brag sheet and subscribe to the waitlist.