RF Feedback: The Sound Bite

The analysis work on the project has significant flaws. You don’t understand where the project plan came from, and you know the team can not live up to it. There are inconsistencies in the functional specification. Perhaps the test cases are inadequate; perhaps there aren’t any test cases. You aren’t sure when testing is going to be done. The list of environmental problems and system issues keeps getting longer. You need to give the boss a full briefing, and explain all the issues …

The boss does not have time for this. While you spend all your time on this single project, this single problem – or a small few – a manager has ten times that many. He only has time to hear the sound bite. If that’s not bad enough, your director is worse. And the executive who is sponsoring the project? Forget about it.

You won’t even get the chance to be in the room with the executive because there are too many people clawing for his time. If you do, you only have one opportunity, and that is to give the sound bite. That’s just the way things are.

There are some people who understand this. The term “weasels” may come to mind, but for whatever reason they understand the sound bite principle, and they know how to use it. You call them weasels because they say things that fit into a sound bite, like “It’s the other guys fault” or “It’s the vendors fault”. Maybe they just say, “Everything is fine”; that is the message they want to be associated with, so they let someone else carry the bad news.

Why is this important to you? Because if you try to explain the system of effects, people’s eyes glaze over. They don’t get it. They don’t want to get it, and you are some techno-geek that needs to go back to developer row, never to be promoted again. That’s what happens, I’m sorry. If you want to advance, you have to be able to understand and master the sound bite principle. It’s that simple.

Yet as a mathematician, I know that you can’t boil down Newton’s proof of integration into two sentences. You just can not do it. In fact, most systems problems don’t fit into a sound bite either. Some things that just need to be proven.

So keep this in mind: If and when you get the opportunity to be influential on your project, all you are going to get is the sound bite. If you don’t think about what that sound bite is, someone will influence it for you. You will get out five, six, maybe ten sentences. Someone will pick your three weakest words in a row, string them together, and say, “I can’t believe you are suggesting that.” You won’t get a chance to respond. I may be exaggerating slightly for effect, but that really is how it happens in the political games, especially if you are saying something that challenges people.

Your next step

So if you are a technical contributor, if the other person’s time is valuable, if you are not going to get a lot of other opportunities, then what you’ve got to think about before the meeting is simply this: What is my sound bite going to be?

If there is one thing I can ask this executive, one thing I can ask this leader to do for me on this project, one thing that will bring it closer to completion, what is that going to be? If there is one compromise we can make on this project to make it successful, what is that compromise going to be?

One thing.

Now, don’t let message be “The date is impossible”, throw up your hands and give up. If you have a message to send like that, it will make the boss feel out of control and defensive. Instead, let the boss figure that one out for himself. You can provide information, you can provide data, but leave the decision making to the manager. Your sound bite time is best used to change the status quo or the organization in a way that makes your project, your team lead, or your director more successful; complaining about the impossible date doesn’t do that.

Crafting your message

Before you go into that meeting, think about the sound bite you are going to give. There could be some really good sound bites out there.

- You could talk about the expected error percent. This sets the expectation that there are going to be errors. Not big ones, but there will be some, and what do we do about them. (Or make them realize the true cost of bullet-proof software)

- List the one task that is or feature that is the long pole in the tent; the single thing that could be offloaded or dumped to save the project.

- Ask for the number one feature; the one that needs to be done first. People don’t like to hear “Oh, we are going to be late”, but if you ask for one thing to turn in early to QA – that’s a positive. Ask for a second feature, a third, and a fourth.

At this point, the audience is hearing something positive. They want more than the sound bite; and when you deliver it, the customer will get all his high-priority features on time.

Think about your sound bite. In testing, it’s typically about risk management: What’s the status of the project, what features should we test first, what do you want us to do.

Allow the manager his sense of control

At the end of the sound bite, ask for direction. Not in a challenging or obnoxious way. Not “I can’t do everything, do you want the bugs fixed, the new features, or do we hit the date – you only get one.” Instead ask, “What do you want me to work on next?”

Let the customer decide, and maybe next time you’ll get more than a sound bite. That is what we are trying to do – make these little nuggets so valuable that we’ll be called into the office again and again. Eventually, you get the ear of the king and you get to give a little bit more than a sound bite. Over time, you learn how to relate with that individual so you can explain the system in a way they can receive it.

That way they can receive it is probably not going to be Newton’s proof of integration. It’s probably not going to be “If A Then B.” You are going to have to work with that individual to see how they communicate and then communicate in their language.

At that point, you’ve developed the relationship to the point that you can communicate with them, and you can move beyond the sound bite into a conversation. In the conversation, you can go into more depth and start talking about system effects, which was the real goal to start with.

Is this article ready for prime time? How should it change? And what publication should it be sent to? Does it scream "Better Software" or "Business 2.0"?

I covet your comments.