The Message Delivery Audit: Why Sharing Information Isn't Leading

I thought I was being clear.

We needed our QA team to shift their approach. Stop waiting until features were complete to start testing. Get involved earlier. Test continuously throughout development, not just at the end.

I explained it in a team meeting. I sent follow-up emails. I talked about it in one-on-ones. Everyone nodded. Everyone said they understood.

Three months later, they were still testing the same way they always had.

The problem wasn't that they didn't want to change. The problem wasn't that I hadn't communicated the change. The problem was that I had shared information without ensuring they actually heard it.

There's a massive difference between those two things.

What Your Team Actually Hears

Here's what I learned from that QA situation: your team isn't hearing your current message. They're hearing your current message filtered through every past experience they've had with leadership.

The QA team had spent years being told their job was to find bugs. Every performance review, every priority conversation, every crisis meeting reinforced this. Test thoroughly. Catch defects. Don't let broken features ship.

So when I told them to start testing before features were complete, their past experiences translated my message into something completely different. What they heard was: "Find bugs faster" or "Test incomplete work AND complete work" or "Add more to your workload."

What I actually needed them to hear was: "Your job is changing. You're moving from quality assurance to quality communication. Your role is to tell us continuously whether quality is good enough to keep building, not just to verify quality at the end."

That's a fundamental mindset shift. And fundamental mindset shifts don't happen because you explained something once in a meeting.

The Scar Tissue Problem

Every leader who ever disappointed your team member left scar tissue. Every time a previous boss said one thing and did another. Every time priorities shifted without explanation. Every time transparency turned out to be selective.

That scar tissue doesn't go away just because you're a different leader.

When you announce a new initiative, some of your team is hearing the last three "new initiatives" that launched with fanfare and died quietly. When you talk about work-life balance, someone is remembering the boss who said that right before crunch time hit. When you emphasize collaboration, others are recalling when "collaboration" meant their ideas got ignored.

You're not just competing with your own clarity. You're competing with years of other people's broken promises.

With my QA team, the scar tissue was thick. They'd been pulled into projects late, blamed for quality issues they had no chance to prevent, and told repeatedly that their value was measured by defects found. Years of that experience created a filter that distorted every message about changing their approach.

I could say "your job is communication" all I wanted. What they heard through their filter was "find problems faster and tell us about them sooner." Close, but fundamentally different. One is about testing cadence. The other is about redefining their entire role.

Sharing Information vs Ensuring Understanding

Most leaders think communication works like this: I have information. I share the information. The information is now communicated.

That's not communication. That's transmission.

Real communication requires confirmation that the message landed correctly. Not that people heard words. That they understood the meaning, integrated it with what they already know, and can act on it.

Here's how you know the difference:

Sharing information looks like: "I told them in the all-hands." "It's in the email I sent." "We talked about it in our one-on-one."

Ensuring understanding looks like: "They started asking different questions." "I saw them make a decision that reflected the new approach." "They explained it to someone else accurately."

With the QA team, I was definitely sharing information. I explained the new approach multiple times. I answered questions. I thought I was being crystal clear.

But ensuring understanding would have looked different. I would have asked them to explain back to me what they thought was changing. I would have tested whether they could describe their new role to someone else. I would have watched for whether their daily decisions reflected the shift.

I did none of that. I just kept explaining and assumed eventually it would click.

The Message Delivery Audit

After the QA experience, I developed what I now call the Message Delivery Audit. It's based on a simple marketing principle: people need to encounter a message seven times, delivered seven different ways, before it actually registers.

Seven touches. Seven methods.

Not because people are stupid. Because competing with scar tissue, existing mental models, and daily workflow demands requires repetition and variety.

Here's what the audit looks like:

The Seven Touches

Count how many times your team has encountered this message. Not how many times you've said it. How many times they've heard it, seen it, or engaged with it.

If you're under seven, you haven't communicated it yet. You've started to communicate it.

With QA, I thought three months of mentions was enough. But when I actually counted discrete encounters with the message, it was maybe ten times spread across the entire team. For a fundamental mindset shift affecting eight people's daily work? Nowhere near enough.

The Seven Methods

This is where most leaders fail. They use the same channel repeatedly and think they're communicating.

I kept talking about the QA shift in meetings and one-on-ones. Same method. Same context. Same format.

What actually worked was changing how the message was delivered:

1. Planning Sessions We started doing QA planning at the beginning of each project, not the end. They had to articulate what quality meant for this specific feature before development started. This forced them to think about their role differently—they were defining quality standards, not just verifying against them.

2. Status Updates with On Track/Off Track We changed the status update format. Instead of "found 12 bugs," the updates became "quality is On Track" or "quality is Off Track for shipping on Friday." This shifted the conversation from bug counting to quality judgment. They had to communicate about readiness, not just problems.

3. Game Discussions We included QA in early game design conversations. Not to test anything yet. To understand what quality would mean for player experience. This reinforced that their expertise was about understanding quality, not just executing test cases.

4. Decision Authority We gave QA the authority to call whether quality was good enough to ship. Not just report findings—make the call. This forced them to own the communication role, not just execute the testing role. When you're responsible for the decision, you can't just be the messenger.

5. Recognition and Feedback When someone on the QA team communicated about quality well—"we're off track for Friday but on track for Monday if we adjust scope"—I called it out specifically. I reinforced the behavior I wanted with recognition. Different method again.

6. Documentation Updates We rewrote the QA process documentation together. They had to articulate the new approach in writing. Seeing their own words describe the change made it more real than hearing my words.

7. Teaching Others I had the QA lead explain the new approach to a different team. Teaching forces clarity. You can't explain something you don't truly understand. This was the confirmation that the message had finally landed.

Notice what happened: the same core message got delivered through planning formats, status structures, meeting inclusion, decision authority, recognition patterns, documentation, and teaching opportunities.

That's seven different ways. Each one reinforced the others.

What the Audit Reveals

When you run a Message Delivery Audit on an important message, you'll usually discover two things:

First, you've barely started communicating. You think you've mentioned something repeatedly because it feels repetitive to you. But you've encountered your own message dozens of times while preparing it, thinking about it, and delivering it. Your team has encountered it maybe twice.

Second, you're using one or two methods at most. Usually talking and email. Maybe a Slack message. You're not varying the delivery mechanism enough to break through the noise and competing priorities.

The audit forces you to get specific:

• What exactly is the message?
• How many times has each team member actually encountered it?
• How many different methods have I used?
• Have I created opportunities for them to engage with it, not just hear it?
• What evidence do I have that understanding occurred?

With my QA team, running this audit (after the fact, unfortunately) showed me I'd delivered the message maybe four times, using two methods (talking and email). No wonder it hadn't landed.

The Mindset Shift That Matters

The QA experience taught me something crucial about leadership communication: your job isn't to share information. Your job is to ensure understanding.

Those require completely different approaches.

Sharing information is efficient. You say it once. Maybe twice. You move on. Your calendar is clear.

Ensuring understanding is inefficient. You say it multiple ways. You watch for comprehension signals. You adjust when signals aren't there. You create structures that force engagement with the idea. Your calendar fills up with communication activities that feel redundant.

But only one of those approaches is actually leading.

Leaders who just share information end up frustrated. "I told them this months ago. Why aren't they doing it?" The answer: because you told them, but they didn't hear you. Not really. Not through their scar tissue. Not integrated with their existing understanding of their role.

Leaders who ensure understanding invest time upfront in varied communication. They feel like they're being repetitive. They worry they're over-communicating. But their teams actually change behavior because the message landed.

What Good Looks Like

You'll know your message actually landed when you see three things:

1. They explain it to others accurately. Not in your words. In their words. Using their own examples. When my QA lead explained the new approach to another team and got it right, I knew the message had integrated with his understanding.

2. They make decisions aligned with the message without you there. The real test: what do they do when you're not in the room? When QA started saying "we're on track" instead of "we found bugs," I knew they'd internalized the shift. They were making the right judgment calls independently.

3. They ask different questions. When people truly understand something new, their questions change. Early on, my QA team asked, "When should we start testing?" Later, they asked, "What does quality mean for this feature?" The question shift showed the mindset shift.

If you're not seeing these three things, you haven't communicated yet. You've transmitted. The message is still sitting in the outbox.

Your Monday Morning Audit

Here's how to use this immediately:

Pick one important message you need your team to understand. Not ten things. One. The strategic shift, the priority change, the new expectation that really matters.

Run the audit:

1. Write down exactly what you need them to understand (not just what you want them to do)
2. Count how many times each team member has encountered this message
3. List the methods you've used to deliver it
4. Identify evidence that understanding occurred (or didn't)

If you're under seven touches through at least five different methods, you're not done communicating.

Design your next seven touches:

• Where can you build this into existing structures? (planning, status updates, reviews)
• What decision authority could reinforce it?
• Who could teach it to someone else?
• What decisions would confirm they understand it?
• How will you recognize the behavior you want?

Then commit to the repetition. It will feel redundant. You'll think "I've already said this." You'll worry about over-communicating.

Do it anyway.

Because the alternative is what I did with my QA team: assume clarity happened the first time, get frustrated when behavior doesn't change, and waste months wondering why smart people aren't getting it.

They were getting it. I just hadn't actually delivered it yet.

What messages have you been trying to communicate that aren't landing? What methods have worked for you when repetition alone hasn't? Share your experience in the comments.

---

You're great at the work. Let's make it visible.

If you're struggling to get important messages to land with your team, or you're tired of feeling like you're not being heard, let's talk about how you can move from sharing information to ensuring understanding.

Contact me here