The Most Important Concept Every Developer Should Know
- Discuss this with your agent
- Open in Claude
- Open in ChatGPT
When you discuss your promotion with your manager, how do you bring it up? What about when you tell a story in an interview? Or give feedback to a coworker?
In each of these situations, our intuition often lies.
Our intuition tells us things like:
- If I just tell my manager how much work Iâve done, heâll appreciate me.
- If I tell this interviewer how awesome I am, sheâll hire me.
- If I tell my coworker more about my solution, heâll get it.
Trust me, I wish.
The truth is: How you present your idea often matters more than the idea itself.
So choose wisely. Thatâs what youâll learn here: How you can frame your ideas for any situation effectively, also known as âframing.â

Framing translates your thoughts into a clear message tuned to the other person.
âď¸ Main takeaways
- A framework for framing any message effectively.
- Plenty of examples relevant to software engineers on how to use it.
đĄA framework for âframingâ your message
- Who am I speaking to?
- What do I want?
- What do they care about?
- How can I explain it to them in terms they care about?

Right now, this might seem a bit abstract.
But letâs jump into examples to see how it works.
đ #1: Resumes
Whatâs the number 1 most common resume mistake?
Bullets being too long or difficult to understand.
Example: âIntegrated the TKI framework into payment tracking system using our FPAY system, doing a full end-to-end deployment process and testing strategy.â
Whoa. Thatâs a mouthful. It isnât the worst. But most of the content is useless as weâll find out.
Letâs go through the framework and find out what we should do:
1. Who am I talking to?
- Recruiters and hiring managers. NOT engineers.
2. What do I want?
- Increase my chances of getting a job
3. What do they care about?
- Quickly confirming that I have what it takes to succeed at the job.
4. How can I explain it to them in terms they care about?
Going through this, we see how we should frame the message effectively to achieve the goal of increasing the chances of a job offer: Show competency as concisely as possible.
The initial message used domain-specific language, didnât cover the impact, and didnât speak the recruiterâs language.
Improved example: Led expansion of payment system to support 50% additional users by setting up load balancers and optimized database indexes.
This is better because:
- It starts with a concise explanation of what you did.
- Follows up with the impact of it.
- Ends with the âdetailsâ of how you did it, but is still using terminology the recruiter understands, like databases and load balancers.

đ #2: Getting a promotion
Promotion discussion with your manager
Here are a couple of ways you could bring up your promotion to your manager:
- âHey Jeff (manager name), I have shipped many projects over the past few quarters, and I want to be promoted. Can I go up for promotion next quarter?â
â - âHey Jeff, Iâve really been loving the projects Iâve worked on the past few quarters. I appreciate you giving me the opportunity to work on those. Iâd love to expand my impact on the team. What would a plan look like to get to the next level?â
â - âHey Jeff, I feel a bit frustrated because I feel like Iâve been stuck at the current level for a while. How can I get promoted?â
Which would you pick? Well, letâs use the framework to find out.
1. Who am I talking to?
- My manager.
2. What do I want?
- To be promoted.
3. What do they care about?
- Having a healthy team, with high-retention and high impact.
4. How can I explain it to them in terms they care about?
- Focus on the impact you have and can bring to the team.
Given the focus on impact to the team, (2) works best.
â (1) âHey Jeff, I have shipped many projects over the past few quarters, and I want to be promoted. Can I go up for promotion next quarter?â
This focuses on past impact, but not future impact, it surprises your manager if you havenât discussed it before, and it comes off as if you âdeserveâ it, which is something to avoid in general.
â âHey Jeff, I feel a bit frustrated because I feel like Iâve been stuck at the current level for a while. How can I get promoted?â
This does touch on the healthy team aspect, and is decent because it asks âhow can I get promotedâ rather than âCan I get promoted?â but (2) focuses on the positive in a more effective way.
â âHey Jeff, Iâve really been loving the projects Iâve worked on the past few quarters. I appreciate you giving me the opportunity to work on those. Iâd love to expand my impact for the team. What would a plan look like to get to the next level?â
(2), our winner, shows appreciation for giving opportunities and then asks for more opportunities to grow. Humans want to be consistent with their past selves. So by framing it as, âYouâve done this before, would you be open to doing it againâ works wonders. It also focuses on the impact part by asking for a plan to get to the next level.
Writing your performance review
How should you structure your performance review and write your bullets? Similar to resumes, many people write their performance reviews in paragraphs of text with overloaded detail. Heck, Iâm a victim of this. This is what I did in my first performance review (please, donât feel the need to read all of it đą):
What I did was remove the environment variable guard statements in the router, and move the checks to a container, where we are able to get the most up to date data from the store. I did so using the ârecomposeâ library, and a method called âbranch,â which is used only in 2-3 other places in the code. Additionally, all of the existing usages were using a simple case of rendering nothing if the conditions were not met, whereas we want to do a redirect if the conditions are not met. This involved a good bit of tinkering with HOCs on the frontend, but eventually we got it to work, so now the user wonât be redirected improperly, and we can get the most up to date data
1. Who am I talking to?
- My manager AND the people he needs to advocate for me to.
2. What do I want?
- To get a better review and be promoted.
3. What do they care about?
- Being able to understand the impact of my work in terms they understand and are able to describe to people who do not know me.
4. How can I explain it to them in terms they care about?
- Write concise bullets that include business impact while showing technical expertise, easily allowing my manager to explain the impact to other leaders who may not have the context of my work.
Using what we learned here, we realize that writing bullets like this is what works:
- Save ~$30,000 / month in dev hours by building a demo company builder for generating sample data locally and saving 5-20 minutes per dev when local testing
- Save ~$10,000 / month in customer support hours by building a self-serve payment portal which reduced customer support tickets by 95%.
Combine this with linking to relevant artifacts like design docs, pull requests, and announcements and you have a recipe for promotion.
đ¤ #3: Handling a disagreement with a coworker
A few years ago, I worked on a change that required alignment across the whole org. It took about 1 month to get that alignment to make a 1 line change. The day before making that change, we had someone blocking the change that had been supporting it throughout the 1-month process. Their claim was that the change would be too harmful to developer productivity.
How would you handle it?
Iâll tell you what I did.
- What did they care about? Ensuring our change did not reduce developer productivity
But thereâs 1 other thing they cared about that is true for practically everyone: being consistent with past behavior and actions. Something I remembered them saying often is that we should not be blocking changes that are easily reversible. Here, the change was a 1-liner that was easily reversible.
So my response?
[Paraphrased] âI understand your concern. I would share the same concern as well if the change was larger from a code perspective. Given the change is just 1 line, itâs easy for us to reverse if we decide it doesnât make sense for us, so it should be safe to experiment with. I know youâve mentioned that practice of shipping as long as its easily reversible as well, which Iâm an advocate for as well.â
And with that, his response was, [Paraphrased] âYouâre right. And good call on it being easily reversible. Letâs do it.â You can see how choosing the frame to present your message with can make work so much easier.
đ #4: Working with a cross-functional partner
Letâs say youâre working with a designer and youâre not a fan of their design because you think it doesnât look good.
What would you do?
You could tell them your opinion directly that you think it doesnât look good. But what would be the most effective way to frame it? Letâs go through the framework
1. Who am I talking to?
- My designer
2. What do I want?
- To get a better-looking design from the designer.
3. What do they care about?
- Shipping a polished, consistent, user experience and having ownership and expertise over their designs.
4. How can I explain it to them in terms they care about?
- Give feedback in a constructive way that still allows the designer to make the final decision and treats them as the expert.
The key is recognizing the last part of the above: âhaving ownership and expertise over their designs.â As an engineer, you donât want to overstep your bounds. Imagine if the designer started commenting on your code saying itâs ugly and you need to refactor it. Here are a couple of examples of good feedback to the designer:
- âI noticed the background color of the button isnât in our system. Should we use this color or should we grab one from the system?â
â - âI saw in our system guidelines we recommend using the toggle component only when it changes the UI immediately. Would it make sense to use Checkbox here?â
â - âI noticed the spacing here differs from how we did it on the previous page. Just wanted to confirm if you preferred them to be different or if we should match it with the previous page?â
As you can see, each piece of feedback points to consistency while also leaving it up to them to be the final decision maker, which matches exactly how we want to frame it.
đŁď¸ #5: Telling a story in an interview
When an interviewer asks you, âTell me about a time you had a disagreement,â what are they really asking?
The key here is the âWhat do they care aboutâ question.
They want to know you can work with others in challenging situations.
How to do it wrong: âSure! A few months back my coworker and I had a hard time agreeing on an API decision. I was pretty frustrated we couldnât move forward, so I brought my manager in to come up with a way we could get unblocked.â
This story isnât terrible. It does mention bringing in a 3rd party to unblock which shows you think about customer impact. It doesnât address what the interviewer actually cares about though: Working with others in difficult situations.
How to do it right: âSure! A few months back my coworker and I had a hard time agreeing on an API decision. One of the first things I try to do when I recognize weâre having a hard time agreeing is hopping on a face-to-face meeting. Once we got on there, I asked a lot about their concerns to try to understand how we could come to a mutual agreement that addressed everything from both sides. After learning more, I called out the areas we needed to come up with an idea for to address all our concerns from both sides. Listing these out made it easy to recognize there was a middle-ground solution that would work for both of us!â
This is a little longer, but calls out your thought process for handling difficult situations and shows you can work through them on your own without intervention.
đ TL;DR
If you take one thing from this article, itâs that before communicating, itâs important to do some âpre-workâ in your head about who your audience is, what they care about, and how to communicate your message effectively given that.
There are many other scenarios this is useful as a software engineer. Here are just a few more:
- Giving a Slack/email update about a new feature you shipped
- Sharing something you learned - how can they use it
- Writing a design document to convince the team to migrate to a new system
â
This article was originally on Jordan Cutlerâs newsletter, High Growth Engineer