Discover more from High Growth Engineer
Communicate like a Senior: Use clear deltas
Level up your performance reviews and influence. Get clear expectations to the next level.
You’re likely familiar with the term “code smell”—like a 4-level deep if-statement.
But I’m inventing a new term called “communication smell.” A communication smell is the same idea, except it’s when you notice a bad pattern in your communication.
One communication smell I see looks like this:
❌ We can improve the load time by caching images on a CDN.
“Improve” is vague. Would it improve by .0001 seconds, 1 second, 3 seconds?
Sure, it will improve the load time. That’s great! But what about the 20 other things that improve the load time? Why should we do this over those?
Here’s an improved version:
✅ I think we can cut the load time by 25% if we cache images on a CDN. That will take it from 3 seconds to 2.25 seconds.
The difference is communicating in deltas. There is a clear before and after:
Before: 3 seconds
After: 2.25 seconds
Improvement: 25%
Communicating in deltas makes your point 5x more convincing (see, notice the 5x 😄).
It doesn’t only apply to prioritization though. In this article, I’ll show you 3 of the best places to use this strategy to grow your career.
Use case 1: Performance reviews
The most common mistake I see in performance reviews is writing unclear impact.
Here’s an example:
❌ Impact: Reduced home page load time by adding caching
It’s an okay start. It’s focused on the user outcome, not the developer output.
But there’s a key problem: Your performance review isn’t only seen by your manager. It’s also seen by their peers who have little context on the work you did.
You “reduced” page load time, but by how much?
Let’s quantify it:
🟡 Impact: Reduced home page load time by 2 seconds through additional caching
It’s better, but it’s unclear how valuable 2 seconds is.
Let’s clarify by sharing the before-and-after (delta) and tying it to team goals.
✅ Impact: Cut home page load time by 66%, from 3 seconds to 1 second through additional caching. This resulted in a 30% increase in engagement, accounting for more than half of our quarter OKR target.
Now, imagine you are a senior leader hearing about this work for the first time and reviewing this person’s performance. With the new version, you know the work done, what it looked like before, what it looks like now, and how good that is because it’s tied to the team goals.
Below, you can see the senior leaders who love this approach:
John calls out that the final version answers, “So what?” We know why it matters.
One more bonus example: Yangshun Tay, CEO of GreatFrontend and ex-staff Engineer at Meta, shares how this same principle can be applied to resumes.
Resumes are often an even more concise version of performance reviews.
Share the delta. Don’t be vague!
Use case 2: Decision buy-in
Imagine you need to convince a team to adopt your new fancy framework.
How will you frame the conversation?
Would you say:
(A) Hey team, we’re working on helping teams adopt a new framework to improve the build health in CI. Can we work with you to get your team migrated?
Or
(B) Hey team, we’re working on helping teams adopt a new framework to improve the build health in CI. Right now, when developers on your team push up a PR to GitHub, it passes only 70% of the time because of build health problems. By adopting the new framework, we’d expect it to pass 99% of the time. This will give developers 1 hour per day in time back.
The first one, (A), is likely to get the answer, “I appreciate it, but we’re pretty slammed right now, so maybe next quarter?”
The second one, (B), will likely get the team jumping out of their seat asking how quickly they can migrate.
So what’s the difference?
The second one quantifies the current system, why it’s a problem, and what the new state will look like afterward. Painting that clear picture gets buy-in because it makes prioritization easy.
The other team has a million things they are balancing and trying to decide to do. Saying that the system will be “improved” isn’t clear by how much. Will it improve by .00001%? Or will it improve by 24% and give the team back a ton of time?
It’s like if a recruiter asks you, “Are you interested in a new job?” while you already have one compared to, “Are you interested in a new job? The pay is $500k per year, which is $200k higher than your current pay.” 200k higher!? Ok, let’s talk! Of course, they probably won’t know your current salary, but you get the point.
That’s what the second one communicated.
This trick works for decisions within your team too. If you want to get something prioritized, call out the quantified change you expect.
❌ Adding <x feature> will increase revenue.
✅ Adding <x feature> will increase revenue by an estimated $4million. This will get us from 10% completion of our quarter goal to 75%.
Use case 3: Getting feedback
Getting feedback, especially from your manager or senior teammates, is one of the best ways to improve.
But it’s hard to get good feedback; especially feedback that explicitly shares how you can operate at the next level.
That’s where this pro tip comes in.
Imagine you are asking your manager for feedback on how your recent project went.
Instead of asking:
❌ How do you think I could have done better?
You can ask:
✅ How could I have executed on this project at the senior level?
In the first approach, your manager has to try hard to filter all the possible feedback they could give and whether it’s worth sharing.
In the second example, they just need to focus on what they would expect from someone at the next level compared to how you did. If they have no feedback, that’s amazing! It’s a great sign you’re already on your way to the next level. If they have feedback, you now have actionable ways to work to the next level.
Alex Chiou, co-founder of Taro and Staff Engineer, talks about this in his answer to how to drive promotion discussions.
Understand the delta
✅ I would ask something like this to your manager word-for-word: "Thanks for the feedback around my performance! For each of these points, can you give me some clear examples of what I could do to satisfy each of requirements at a senior level?"
I credit Alex with much of this article’s core idea.
You can also ask for preemptive feedback this way too.
✅ Before starting on a project: What would senior-level execution on this project look like? I want to aim for that so I can continue growing and exceed expectations.
Here are two other ways you can use this strategy:
How can this be 10% better?
What would good vs. great look like for this project?
Asking for feedback this way creates clear expectations. You’ll know exactly what you need to do to operate at the next level.
📖 TL;DR
Don’t be vague. Communicate using quantified before and after states and see the benefits in performance reviews, influence, and clear expectations.
Here are the 3 use cases discussed and the key examples:
Performance reviews
❌ Impact: Reduced home page load time by adding caching
✅ Impact: Cut home page load time by 66%, from 3 seconds to 1 second through additional caching. This resulted in a 30% increase in engagement, accounting for more than half of our quarter OKR target.
Decision buy-in
❌ Adding <x feature> will increase revenue.
✅ Adding <x feature> will increase revenue by an estimated $4million. This will get us from 10% completion of our quarter goal to 75%.
Getting feedback
❌ How do you think I could have done better?
✅ How could I have executed on this project at the senior level?
📣 Shout-outs of the week
5 ways to show your work without being cocky by
and on — Great article on how to be visible and add value u are doing it.How Stripe Prevents Double Payments Using Idempotency by
on — Important technical concept to understand for frontend and backend developers3 Questions to Ask Yourself as a Leader by
on — Improve your self-awareness through these 3 questions: “Would you want to work for yourself?”, “Are you evaluating your actions periodically?”, “Do you balance your core leadership strengths?”
Thank you again for the growth to 60k+ subscribers 🙏 Here is the promised celebration 🥳
You can also hit the like ❤️ button at the bottom of this email to help support me or share this with a friend to get referral rewards. It helps me a ton!
You’ve hit the nail on the head, Jordan! I wish more engineers could learn this. It would pay off so much for their career growth, project success, and buy-in across teams.
Quantify, quantify, quantify.
So many senior or principal engineers who can’t connect why they are doing to an actual business need – which is a big red flag.
I think it’s because in our day-to-day jobs we focus so much on the coding on it, that we lose the bigger product/business/customer perspective.
Here are a few helpful questions to ask:
– Why are we building what we are building?
– What problem does it solve for our users?
– How much support time did this save our team?
– How much new revenue did this feature drive for the business?
If you can quantify your projects in how it impacted the business and the stakeholders, you will really standout to senior engineering leaders, business leaders, cross functional partners teams.
Thanks for the mention Jordan, and congrats on the 60k! 🙌
Business writing is very different from what we do in social media. We have to get rid of anything that doesn't indicate impact.
"Every sentence, every phrase, every word has to fight for its life - Crawford Kilian"