Top 5 Communication Frameworks for Engineers You Must Remember

Be convincing, be strategic, be heard

📣 Build AI-ready apps with HubSpot

The HubSpot Developer Platform gives you the tools to build, extend, and scale with confidence. Create AI-ready apps, integrations, and workflows faster with a unified platform designed to grow alongside your business.

Thanks to HubSpot for sponsoring this week’s newsletter!

---

Engineers with the best ideas don’t always have the most influence.

But those who can structure their communication do.

I’ve seen engineers with good ideas get overlooked while those with solid frameworks for presenting their thoughts get heard…and promoted.

Frameworks are simple structures that transform how your message lands. Whether you’re trying to convince people of an idea, writing strategy docs, in a 1:1 with a Director+ leader, or presenting a demo, frameworks make you look like a superstar in all of these.

Today, I’m sharing 5 communication frameworks I’ve used to turn rambling thoughts into persuasive messages that get results. Let’s jump into the first one!

1) PREP

The PREP framework is the most effective structure for making a persuasive case in any conversation, meeting, or proposal.

Here it is:

• Point: State your main argument immediately

• Reason: Explain why it’s important or why you believe it

• Example: Back it up with concrete evidence or a specific instance

• Point: Restate your main argument to reinforce it

This structure works across contexts. In technical proposals, it helps you build a tight case for your approach. In architecture discussions, it keeps you from rambling and losing your audience. In leadership conversations, it makes your observations clear and hard to dispute.

Here’s how I’ve used this in the past to make strong cases for technical decisions

Point: We should move forward with approach A because…

Reason: It leads to a more consistent developer experience and is easier for AI to reason about.

Example: We can see that 80% of the existing usages match a similar pattern already. Also, in these two comparative AI chats, we can see it was able to follow approach A much more easily.

Point: Given this, I highly recommend we proceed with approach A.

Using this structure makes such a strong case because you start and end with what should be done, using repetition and confidence. You summarize the high-level reasons that someone can also easily remember and get behind. And you drive that home with examples, showing that your reason has concrete backing.

This very newsletter uses the same framework!

1. Point: I recommend speaking in frameworks

2. Reason: Using frameworks turns your rambling thoughts into convincing ideas that drive action from others

3. Example: Each of these sections with examples of communication frameworks and how to use them

4. Point: The TLDR you’ll get to at the bottom of the newsletter

This has been the common format for over 100+ articles now, and hey, I think my newsletter has been decently successful 😄

Try this in your next important discussion: state your point, explain why, give examples, and restate your point. Your arguments will be more concise and convincing.

2) GROW

The GROW framework makes going from a current state to a future state easy.

Here it is:

• Goal: What outcome do you want to achieve?

• Reality: What’s the current situation?

• Options: What are the possible paths to get from here to there?

• Will: Which path are you willing to commit to?

I use this framework most for mentorship and strategy. For mentorship, it works like a gap analysis. You start by defining where someone wants to go, assess where they are now, explore the options to bridge that gap, and commit to specific actions.

Growth Plan Template

I mentored an engineer from Junior to Senior in less than 2 years using this framework.

• Goal: Senior engineer.

• Reality: Operating at mid-level with strong execution but inconsistent examples across the senior-level criteria. We looked at each engineering attribute and assessed where they were using a red, yellow, green system.

• Options: We discussed clear next steps to address each of the “red” and “yellow” areas, prioritizing the most important ones.

• Will: We had check-ins to track progress and add examples, gradually moving from “red” and “yellow” to “green”.

Because we had a concrete, structured system, they regularly made progress and were promoted to Senior in under two years. Without this structure, we would’ve had vague conversations about “getting better” without a clear path.

Outside of mentorship, when proposing strategies or plans, the same approach applies. You define a goal you want to achieve, state where you are right now, and communicate the path to get from here to there. I use this for one-pagers and proposals. I cover this use case more in the recent one-pagers article.

3) BLUF

BLUF (Bottom Line Up Front) is the single most important communication framework for engineers. If you only learn one, learn this.

✅ Do: In BLUF, you start with your main point, question, or request. Then, you only add the necessary context to drive that point home.

❌ Don’t: Start with lots of context, making the other person wonder where you’re going, and end with your point.

This framework is especially important when communicating with senior leaders. Until you make your point, they’re constantly wondering what is important to know or not, and where you’re going. By the time you get to the point, they’ve either tuned out or forgotten half of what you said.

When you lead with your point first, they immediately know what you need, which lets them filter the context you’re about to give. They know what to listen for. Even better, it lets them cut you off in a positive way. If you say, “I need approval to refactor the payment handler” and start explaining why, they can interrupt with “Approved, no need to explain further.”

Instead, if you started with context and they’re forced to wait unnecessarily long or cut you off in a frustrating way, “Sorry to interrupt, but can you speed up your ask?”

This framework applies across every communication channel:

• In emails: Start with a TLDR at the top. People can decide whether to read the rest based on that.

• In design docs: Open with an executive summary. Don’t make readers wade through background and technical details before they understand what you’re proposing and why it matters.

• In meetings and discussions: State your main point first. “I think we should migrate to PostgreSQL. Here’s why: …”

• In status updates: Lead with the blocker or the key outcome. “The release is delayed by two days” is more useful than a paragraph about what you shipped this week.

• In Slack messages and questions: Put your question or request in the first line. Long context dumps before the ask get ignored.

Remember BLUF for each of these scenarios and you’ll see how much more your communication is heard and people take action.

4) Observation-Impact-Question

There are many ways to give feedback. Most feedback frameworks I’ve seen feel too formal or forced, almost like you need to switch from “you mode” to “feedback mode.”

Many of these frameworks are great for giving feedback in a performance review setting, but they make less sense when you just want to give casual, on-the-spot feedback.

To do this, I use the “Observation-Impact-Question” framework I learned from Lara Hogan’s article.

1. Observation - Start with, “Hey, I noticed <action>”

2. Impact - State what the impact of that action is to you or the other person, like, “That leads to <impact>”

3. Question - Ask them a question or make a request like, “What are your thoughts?”, “Have you considered doing <x>”, or “In the future, would you be open to doing <x>?”

Putting it all together, it would look like:

You: “Hey, I noticed you use “um” and “uh” more often halfway through your presentation. Once I caught on, I had a hard time focusing on your content as much and found myself focusing on the verbal fillers. Were you aware you were using them often?”

We can make this better with a couple of bonuses:

1. Lead with a compliment

2. Ask for their permission to give the feedback

(Compliment) You: “Hey, I really liked <specific part of presentation> earlier. Would you also be open to some suggestions to improve it even more?”

Them: “Thanks a lot. Yeah, of course!”

(Observation-Impact-Question) You: “I noticed you use “um” and “uh” more often halfway through your presentation. Once I caught on, I had a hard time focusing on your content as much and found myself focusing on the verbal fillers. Were you aware you were using them often?”

Them: “That’s a good callout. It’s something I’m aware of but need to work on more. Do you have good suggestions for how you avoid them?”

You: “Yeah, I used to struggle with the same thing. Two things I do are practice and record myself and try to speak more slowly and let myself pause rather than using a filler. Over time, I could replace the pauses with just speaking normally, but I still fall back on pausing when I need to.”

In general, I try to remember the “I noticed” part of the framework and let myself fill in the rest of what makes sense based on the situation. Just knowing that as the starting point helps me figure out all the other aspects like leading with a compliment, mentioning why the observation is important, and moving to next steps.

Another way to think about this framework is, “What, So What, Now What.”

• The “what” is the observation, or the behavior you noticed

• The “so what” is the impact, or why it matters

• The “now what” is the question or request that helps the conversation move forward into action

5) Before-After-Bridge

Before-After-Bridge is a copywriting and sales framework for converting on a product you want to sell, but it works equally well for engineering presentations and demos. The product is just your story rather than something to buy.

Here it is:

• Before: Show how bad the situation was before your solution

• After: Show how it changed after adding your solution

• Bridge: Now that people are in awe and curious, show the approach, challenges, and lessons learned

I recently presented at an on-site and opened with some brief context about the project and then shared the results. Since beginning, we improved our top-line product metric by 23%. People wanted to know how. When I walked through the bridge, explaining the challenges and lessons we had learned, the room paid attention because they already knew it would lead to something significant.

If I’d started with the process, people would’ve tuned out. They wouldn’t know where the story was going or why the details mattered. By the time I got to the final change, half the room would’ve been distracted.

This is why many technical presentations can become boring. Engineers start with the problem, walk through the technical approach, discuss the challenges, and finally reveal the outcome. But the audience has already lost interest because they didn’t know where the story was going.

In your next presentation, restructure it to lead with the outcomes. Hook your audience with that, then share how you solved it. Enjoy higher presentation engagement!

📖 TL;DR

1. PREP: Use Point, Reason, Example, Point to make convincing arguments in conversations, meetings, or proposals

2. GROW: Use Goal, Reality, Options, Will to create structured plans for mentorship and strategy that bridge the gap from the current state to the future state

3. BLUF: Lead with your main point first, then add only the necessary context to drive it home, especially when communicating with senior leaders

4. Observation-Impact-Question: Give casual feedback by starting with “I noticed,” stating the impact, then asking a question or making a request

5. Before-After-Bridge: Hook your audience in presentations by showing the results first, then walk through how you achieved them

---

Thank you for reading and being a supporter in growing the newsletter 🙏

You can also hit the like ❤️ button at the bottom of this email to support me or share it with a friend to earn referral rewards. It helps me a ton!