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

1. Who am I speaking to?
2. What do I want?
3. What do they care about?
4. 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:

1. It starts with a concise explanation of what you did.
2. Follows up with the impact of it.
3. 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:

1. “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?”
   ‍
2. “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?”
   ‍
3. “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