5 Frameworks To Master Communication And Influence As An Engineer

Hi all, Jordan here 👋

Today, we’ll dive into the top lessons and frameworks from Wes Kao and her course on Executive Communication and Influence. Wes writes one of the highest-value newsletters I know, sharing the most specific advice I don’t see anywhere else. She was the cofounder of both Maven and altMBA, and has been in leadership positions throughout her career.

I joined Wes’s October Cohort course, and she graciously allowed me to share a few of the lessons from the course with you all. Get ready for super practical and specific communication advice to level up your influence and presence.

What to expect from Wes’s course

Before jumping into the advice, here’s a quick overview of what it was like.

In any sort of teaching, there are three levels you can learn—the goal, the principles, and the specific tactics. Wes focused on 80% principles and tactics, and just enough on the goal, or the “why.”

I tried to count how many tactics I learned from my notes, and I lost track after 50. The sheer amount of practical strategies to apply was mindboggling, and I’d highly recommend Wes’s cohort from that alone.

Each tactic was also well-explained and incredibly high quality. There was always a bad example, a good example, and a clear explanation of the difference.

With that overview out of the way, let’s jump into my mini-version of Wes’s lessons.

1) Framing: Signposting

Signposting is rarely done, but it’s so simple to add and so pleasant when you see it as a reader. It turns walls of text into easy-to-parse chunks and makes your intent clear.

In short, it reduces cognitive load on your reader.

My takeaways were that signposting is the art of 2 things:

1. Breaking your message into sections

2. Making good and bad news clear

Wes gives a huge list of signposting words in her article here, but I’ll inline my favorites.

1. For example: < content >

2. Action items: < content >

3. Action needed: < content >

4. Next steps: < content >

5. Context: < content >

6. Recommendation: < content >

7. Tradeoffs: < content >

8. TLDR: < content >

9. Great news! < content >

When you don’t signpost, your message either comes across as one big blob or worse, you put your reader through a scary emotional rollercoaster.

Think about if your manager sent you this message:

❌ Manager: “Hey, need to talk to you tomorrow about your performance review.”

Immediately you’re probably like 😬 😨

Until you get a message five minutes later…

Manager: “Sorry, was in a meeting. Really excited to share some great news with you. Sit tight till tomorrow.”

Phew 😮‍💨. That “great news” was a signpost that should have been at the start of the first message.

✅ Manager: “Hey, have some great news on your performance review. Chat tomorrow?”

A case where I applied this to my manager is after I launched a new feature, I sent him a message starting with, “Great news!” and then told him about the launch. Because of that, when they read the full message, they can be rest assured that everything in there is a win to bask in.

The other places I use signposting are in my project updates, meeting notes, and announcement emails. I’ll follow a general structure like this:

TLDR: { Good or Bad } news. < 1 line summary >

Recommendation: < what I recommend >

Context: < explanation of why >

Next steps: < what we need to do next, tagging each action item owner >

Each signpost reduces cognitive load on the reader, making it easy to find what they care about the most and avoiding one giant wall of text to parse.

I don’t always include every section, but if I did, that’s the order I’d use. Always put the takeaways first, which the next framework describes in detail 😄

2) Framing: MP-CB (Main Point, Context Below)

If you’re an avid reader of the newsletter, you’ll know this as BLUF (Bottom Line Up Front), a.k.a. my favorite framework.

After years of “building up to my point” and ending with what I really want to say, I learned how wrong I was the first day after switching and seeing the results.

Wes puts her own spin on it by calling it, “Main point, context below,” but the idea is the same. Lead with what you really need people to know. Give them the context after.

Here’s an example of not using BLUF

❌ Hi team,

As we continue to strive for excellence, it's important that we regularly align on our project goals and progress. I scheduled a meeting for next Thursday to discuss the roadmap for the upcoming quarter.

To prepare for this discussion, I made a document that outlines the key points we will be covering, including the milestones we ve set and the resources we'll need to achieve them. I'd like everyone to come to the meeting with a good understanding of the content so that we can have a productive session.

Please pre-read the document here: Q1 Roadmap Planning ← what you care about

The real thing you care about people doing is pre-reading the document, which is mentioned last. By the first paragraph, you would have lost 50% of your readers, and they wouldn’t have even seen to pre-read the document.

The switch Wes recommends is to lead with your main point, then signpost your context below it.

Hi team,

Ahead of next Thursday's meeting, please review the Q1 Roadmap Planning Doc [link].

Context: It's a roadmap for our next quarter, outlining milestones, resources, and project timelines. Your insights are crucial and pre-reading this will prime us for a focused discussion.

I use this for messages to my manager, weekly project updates, meeting recaps, and 1-pagers with recommendations. This framework is one of the most broadly applicable ones you can use every day to improve your clarity instantly.

3) Framing: Anticipate the objection

You’re behind on your project and your manager comes into the project channel asking why it’s not shipped yet. How do you respond?

< Take a moment to pause and think about it >

This framework does 80% of the work for you. Below is what I wrote:

✅ Although we initially expected to be at 100 widgets by now, we came across multiple unknowns that were only possible to find after starting. We did an initial scoping and spike to try to limit this, which caught a good amount of unknowns early. However, because the nature of this project is highly ambiguous, there were others that came up along the way.

With that said, moving forward we are confident about having identified all the unknowns. You can expect us to be at 100% by [x] date. After shipping, we'll run a retro to see how we can minimize cases like this in the future.

In the second sentence, you can see how I “anticipated the objection.” The common objection someone will have to unexpected scope increases is, “What did you do to minimize that?”

So I answer that explicitly, effectively saying, “We did what you’d want us to do, but there was still more that couldn’t have been caught early.”

By anticipating the objection, I make it easy for my manager to understand why it’s delayed and communicate that upward, potentially to his manager and so on. Plus, it prevents you from losing trust and shows you weren’t just bull-rushing the project; you considered the risks and did your best to minimize them.

4) Delegation: CEDAF (Comprehension, Excitement, Derisk, Align, Feedback loop)

Delegation has always scared me. No one really teaches you how to do it, you don’t want to come across as micromanagey, and you need to put a lot of trust in who you’re delegating to.

In the past, I experimented with different approaches, but all were some version of winging it.

Wes’s framework for delegation solves these problems for me and gives me an easy way to think about it—it’s called CEDAF.

She also gave exact phrases and ways to apply each step. Here’s my annotated version:

1. Comprehension: Are you explaining in a way that's easy to understand?

   1. Tip: Break it down into high-level steps, then dive into each part individually.

2. Excitement: Are you getting the person excited?

   1. Example: “This will be great for your visibility.”

   2. Example: “<x> contributes to <y big initiative> in a positive way.”

3. Derisk: Are you derisking any obvious risks?

   1. Example: “How confident do you feel about taking this on?”

   2. Example: “What risks do you see?”

   3. Example: “How are you considering approaching it?”

4. Align: Are you giving them a chance to speak up and summarize what they heard? Do they have everything they need?

   1. Example: “Do you feel like this is doable?”

   2. Example: “What are some of your initial thoughts?”

   3. Example: “Do you feel like you have a clear picture of what ‘done’ looks like?”

5. Feedback loop: Are you creating the shortest feedback loop?

   1. Follow up as early as possible to ensure they’re good. Adjust based on that.

Since learning it, I’ve already found ways to apply each step, particularly (2) and (4), where I saw instant results.

A common theme in Wes’s frameworks is they bottle up a complex, nuanced topic into an easy-to-remember acronym that gives you confidence, and that was especially the case for this one—where I just had no clue what to do most of the time 😂

5) Influence: QBQ (Question behind the question)

In interviews, when you’re asked, “Tell me about the biggest disagreement you had,” they aren’t looking for a story where you got in a huge fight and never spoke to your coworker again.

There’s a question behind the question. They’re really wondering, “How well do you work with your coworkers, and do you approach difficult situations collaboratively?”

Wes made a framework for this called QBQ—where you look out for that same “Question behind the question” not just in interviews, but in all situations.

Another example: Your manager asks you the status of a project. Yes, they asked for the status, but what they really might be wondering is, “How much do I need to worry about this getting done?” It could also be other things, but take a moment to think about their QBQ—and you’ll know how to frame your response.

To guess at the QBQ, Wes recommends thinking about:

1. What might feel risky for them? What would make them feel safe?

2. What are their priorities based on their function and role?

3. If nothing comes to mind, you can ask directly, “What’s your top-of-mind concern?” or “Anything you’re particularly curious about?”

In the above situation with my manager, I usually give enough detail to give them confidence in where the project is, then follow up with, “Anything you’re particularly curious about?” to ensure I touched on their QBQ.

Final example: You get asked a question in a meeting but don’t know the answer. “Do you know what % of mobile users are using this feature?”

Instead of saying, “I’m not sure. Let me get back to you on that” or hacking together a half-answer, you can try to look for the question behind the question.

You can ask something like, “I’m not sure off the top of my head. Any reason you’re curious?” And see if they give you something to work with. For example, if they say, “I was wondering the impact surface area of the feature across platforms.” You might be able to answer that question now in a different way.

Like, “Oh yes! We’ve seen 20% of purchases come from mobile and 80% come from desktop.” In this case, you didn’t know the exact distribution of mobile and desktop users, but your answer was even better than that. You got to the root of what they care about—the impact.

At this point, you might wonder, “Why don’t they just ask what they’re thinking?”

Life would be simpler that way—but it’s just not how it works. Some people like to piece things together in their head, and other times, it doesn’t make sense for them to ask the QBQ. For example, in interviews, the interviewer wants to judge whether someone is a good collaborator based on their story. They don’t want to be told, “I’m a good collaborator.” They want to see it.

By the way, this interlude was another example of “Anticipate the objection” 😅 and my “Final example:” above was a signpost.

📖 TL;DR

1. Framing: Signpost your writing

   1. Reduce cognitive load by using phrases like: For example, Action items, Action needed, Next steps, Context, Recommendation, Tradeoffs, TLDR, Great news, Bad news, etc.

2. Framing: Main point, context below (MP-CB)

   1. Lead with your main point, then signpost your context below that.

   2. Use this framework as a default in your communication.

3. Framing: Anticipate the objection

   1. When explaining yourself or pushing forward proposals, call out how the common objections they’d have are already solved.

4. Delegation: Remember CEDAF when you’re delegating tasks

   1. Comprehension: Are you explaining in a way that's easy to understand?

   2. Excitement: Are you getting the person excited?

   3. Derisk: Are you derisking any obvious risks?

   4. Align: Are you giving them a chance to speak up and summarize what they heard? Do they have everything they need?

   5. Feedback loop: Are you creating the shortest feedback loop?

5. Influence: QBQ (Question behind the question)

   1. When you’re asked a question, ask yourself what the person might be really curious about. Dig into that and answer that, especially if you don’t have an answer to their surface-level question.

   2. If you’re not sure what the QBQ is or the answer to their surface question, ask them, “What’s your top-of-mind concern?”

🙏 Thank you to Wes

Before signing off, I just want to give another special thank you to Wes for her amazing course and for allowing me to share these frameworks and lessons from the course with you.

Her cohort has the “High Growth Engineer must attend” stamp of approval. You can check it out here: https://maven.com/wes-kao/executive-communication-influence.

I also recommend following Wes on LinkedIn and joining her newsletter too.

👏 Shout-outs of the week

• What finesse looks like when reading people and situations on Wes Kao's Newsletter — Quick tips on common situations that you might not realize matter

• How to become a more effective engineer on The Pragmatic Engineer — Career principles and questions to ask yourself that will make you a better engineer

• The time I became a manager on A Life Engineered — Interesting story of a tech lead turning to management and coming back to IC roles.

Thank you for being a valued supporter and helping to grow to 78k+ subscribers 🙏

Next week, we’ll feature Director at Rippling, Torsten Walbaum, who will share the most important communication framework you should know to structure your thinking and communication. He’ll share 5 use cases you can use as an engineer

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!