👋 Hey, it’s Wes. Welcome to my weekly newsletter on managing up, career growth, and standing out as a high-performer.

✨ Announcement: I’m thrilled to share that I’m building a course. Since launching this newsletter last fall, and working with 1:1 coaching clients earlier this year, I’ve gotten many requests from folks asking about opportunities to learn directly from me and go deeper into the meaty topics I cover here. I want to build the most action-packed, high-value course possible for you. This first cohort will be smaller, and an excellent opportunity to shape the course for all future students. If you’re interested in learning more and sharing feedback, please fill out this form.

In this week’s newsletter, you’ll learn about common mistakes when sharing details, and how to increase the likelihood you share the right amount of context.

• Part I: Being too detailed in the wrong ways

  • Example 1: Too many numbers

  • Example 2: Jumping straight into details

  • Example 3: Too much technical detail

  • Example 4: Failing to include details necessary for the decision

  • Example 5: Misreading the task at hand

• Part II: How to decide what details to include

Read time: 10 minutes

“This is too detailed.”

You’ve likely heard this from a manager or executive you were presenting to.

When you heard that, you might have come to this (mistaken) conclusion: Details are bad, and I should be as high-level as possible all the time because people don’t have time for or want to hear details.

That’s a dangerous over-simplification.

A detail is simply a fact, data point, words, or piece of information. By itself, it is neutral. It’s not good or bad.

Details aren’t the problem. The problem is too many of the wrong details.

Too detailed in the wrong way, not detailed enough in the right way is highly situational. A detail in a certain context might be too much. But change the setting, and that same detail could become appropriate.

Why does being detailed in the right way matter? Because every detail adds cognitive load. Cognitive load means friction. And friction prevents people from doing what you want them to do.

The wrong details slow you down and create confusion. The right details advance the conversation, create deeper understanding, and lead to more productive discussions.

When we talk about something being too detailed in the wrong way, we’re talking about a mismatch between your goal, audience, situation, and the level and type of details you’re sharing.

This is why if I see a random memo without context, it’s really hard for me to tell if it’s too detailed or not. I don’t know how much the original audience knew, or what the setting for that conversation was. 

Given how context-dependent this is, I believe the best way to show you this concept is to share a bunch of examples. This way, you can train your eye to notice patterns. Notice what these notes do or don’t do, and the underlying principles, so you can apply it to your own work.

A note: It’s extremely hard to find examples that still make sense after anonymizing and redacting. Some of these examples are of more tactical topics where I can share the content openly, but this framework applies to strategic writing (like investor updates, quarterly strategy docs, proposals) and verbal communication (explaining your ideas in a 1:1, team meeting, group discussion).

Let’s dive in.

Part I: Being too detailed in the wrong ways

Example 1: Too many numbers

In my post on “How I give the right amount of context (in any situation)” I share this example:

Let’s say a customer asked why they got fewer students from the second cohort of their course. You could say this:

🚫 “Consider extending the enrollment period. For cohort 1, your course was announced on May 13, providing 6 weeks to accept students, up until the August 1 start date. For cohort 2, you announced the course on October 7 and only accepted for the following 10 days.” ← This is confusing.

✅ “Consider extending your enrollment period. For your first cohort, you had 6 weeks to fill the cohort. But for your second cohort, you only had a little over 1 week. So next time, I recommend giving students more time to sign up.”

Notice how too many numbers are distracting: cohort 1, May 13, 6 weeks, August 1, cohort 2, October 7, 10 days.

Numbers attract the eye, but too many of them add cognitive load—it’s hard to tell what numbers to pay attention to.

The numbers above were dates, but you’ve probably seen this with metrics too. 

Often, junior folks will present updates and name EVERY metric without any narrative arc. There’s no connective tissue. There’s no meaning to the numbers. It’s simply rattling off numbers to cover their bases.

🚫 “This quarter, we generated 5,000 MQLs, which was up 13% from our forecast of X,000, but less than X,000 MQLs (up 23%) from this time last year and flat to the previous quarter. We generated 403 SQLs, which was 25% percentage points higher than our goal of 350 SQLs, and represented an 8% conversion from MQL to SQL. This is lower than our average in the last 3 quarters…”

✅ [Mention a few key metrics and share a narrative of what’s happening]

Your ultimate goal is to help your audience make sense of information. This means picking and choosing which numbers to share, based on what you’re noticing in the business and the story you want to tell.

Example 2: Jumping straight into details

This note was shared with me by my client who is Head of Operations at a healthcare tech startup. It’s a note from their former direct report, a talent lead:

My client said:

“This Slack message includes detailed raw notes but no clear highlights or takeaways—it's an extra mental load on me to process all of it and try to figure out the most impactful parts for the business, and there still doesn't seem to be an actual point. It’s just notes.”

My take: The note jumped straight into the details without providing any context. My client got this random message and didn’t know what it was for.

I had to read it multiple times to try to make sense of it, which is a bad sign. This is a classic example of notes that are meant for the note-taker vs meant to be read by others. (This is a pet peeve of mine.)

Just offering notes can be totally fine—for example, if you’re taking notes for team members who couldn’t attend a meeting. But you need to write with intention.

Here’s how I would rewrite this:

“FYI I met with a LinkedIn representative about their LinkedIn Recruiter tool. The next step is to discuss the ROI and whether we want to renew our subscription. Let’s decide at the talent sync this Friday. For context, the below are meeting notes from the kick-off call.”

Notice how a simple few lines make those details seem more relevant and purposeful. You show you’re focused on next steps, and offer a timeline. When you frame upfront, your audience is able to better digest (and appreciate) the details you share.

Another thought: Usually, sharing only notes is not that helpful, especially with AI tools that now do much of this. It’s more valuable to share notes AND your takeaways, analysis, and insights.

Example 3: Too much technical detail

My client write the note above, and said: 

I was asked to give an update to the leadership team on the progress of an ongoing project we were doing with a group of data consultants (REDACTED). I didn't clearly indicate whether the project was going well or not, but I did include too much technical information that wasn't helpful for the leadership team to know, nor easily understandable by most people. I didn't explain why the things I was talking about mattered to the business nor explain their impact in simple terms.

I think their self-analysis is spot on. I redacted most of the technical tools for their privacy, but basically they mentioned lots of technical aspects without mentioning what it means.

When you read this, it’s full of information…but you don’t get a clear sense of how the project is going, or the impact of any of the decisions above. There aren’t many insights on potential risks or learnings. There’s not much to react to, period.

Don’t skimp on the meaty stuff that helps your reader make meaning and comprehend the situation.

Example 4: Failing to include details necessary for the decision

This is a note from an HR agency we used at Maven. The note is decent. The screenshot is on mobile, so it’s concise and dense with useful information—it just looks longer because of the narrower form factor of mobile.

But it’s lacking one important “detail”... We (the brand/client) can’t make a decision about whether to change healthcare plans unless we see the plans.

So the next obvious question was: “Can we see the tier comparisons?” 

The person should have included this information to begin with. It would have saved one cycle of follow-up, and allowed us to move faster.

Proactively give people what they need to make a decision.

Example 5: Misreading the task at hand

I was doing a Maven lightning talk a few months ago, and asked my former direct report to help suggest ideas for the scope of my talk. My title was “Stand out as a high-performing individual contributor,” and I wanted a thought partner to figure out what to focus on in my 30-minute slot.

They sent the below email over:

I didn’t need a minute-by-minute breakdown, or general ideas on interactivity. Nothing in this note is specific to my topic, which makes it less relevant and valuable.

Make sure you understand the assignment before you dive into it. If you write the best run-of-show agenda for someone who doesn’t need that, then you missed the mark regardless of how good your execution was.

Which brings me to an important point…

We are ALL susceptible to being too detailed in the wrong ways sometimes.

No one is immune. No one is exempt.

The operator above is usually very good at giving the right level of detail. I’ve seen it across dozens of interactions with internal and external stakeholders.

But she was still too detailed in the wrong way for this particular situation.

It’s happened to me many times.

It’s likely happened to you in the past, and will likely happen in the future—although hopefully less now that you are aware of this concept. Don’t beat yourself up about it. In my experience, you can’t completely prevent this from happening.

Be grateful that you realized it or someone pointed it out to you, update your mental model, and keep moving forward.

Part II: How to decide what details to include

By now, you might have realized that sharing the right amount of detail actually takes an enormous amount of judgment.

It requires you to accurately read a situation, assert the level of existing knowledge your stakeholders have, assess whether this is the right time and place to share various pieces of information—all in real-time.

No wonder this takes practice. 

To get you started, here are questions to ask yourself:

• What is your main point and why is this important?

• What is your goal in sharing this information?

• What action do you want your recipient to take?

• Are you really answering the question they’re asking?

• How much does your audience already know?

Over time, you develop muscle memory—and I believe you can begin to develop it and start seeing results rather quickly. One day, you’ll realize that it’s second nature to share certain details but not others. You’ll be able to sense what’s needed and respond well intuitively.

A few other thoughts to keep in mind:

• Consider what the person needs to know vs what’s secondary. Every detail adds cognitive load for your audience because they need to discern what’s important. When you stack rank and force yourself to get clear on what’s most important, you’ll be able to share more valuable details and cut down the fluff.

• You're not always going to get it right. I still misread situations, and that’s normal. Even the strongest operators, founders, and leaders I’ve worked with struggle with this sometimes. The goal is to try to increase your hit rate. Try to increase the chances that you read a situation accurately and can react appropriately. The more skilled you are at this, the more likely you are to achieve the outcomes you aim for.

• If you think your audience might think you’re being too detailed, mention why those details are important to include. Say, “I’m sharing this because…” or “These details matter because…” Basically, you don’t want others to diminish or discredit what you’re saying by labeling it as “too detailed” if you believe those details are actually relevant to the conversation. It’s on you to explain why so you’re in control of the narrative.

• When you catch yourself sharing too many details as you’re speaking in real-time, gracefully finish your sentence and bring it back to your main point. There’s no need to call yourself out. You can, but I find it better to avoid being overly self-deprecating. If you say, “Oh geez, I’m getting too detailed again aren’t I?”, this is incepting a negative idea and allowing people to label you as someone who is not a clear thinker.

Now that you have the shared vocabulary of “too detailed in the wrong ways, not detailed enough in the right ways,” you can point this out in your own work and for your peers.

Keep your eye out for it, and let me know how it goes.

Have you ever been too detailed in the wrong way? Have you read memos from others that were like this? Hit reply because I’d love to hear from you.

Thanks for being here, and I’ll see you next Wednesday at 8am ET.

Wes

PS Here are more ways to connect:

1. Follow me on Twitter or LinkedIn for insights during the week (free).

2. Check my availability to do a keynote talk for your team.

3. Work with me for 1:1 executive coaching. I find it extremely rewarding to give personalized guidance to ambitious operators. My current clients include leaders at startups funded by Sequoia, Accel, Bessemer, SV Angel, Kleiner Perkins, etc.

4. Share feedback and help to shape my upcoming course :]