Marketing vs. Spin

I’m going to get a bit up on one of my soapboxes today so be warned. Flame on!

Maybe it’s the engineer in me, but I get extremely frustrated with bad marketing. Specifically, bad marketing that passes itself off as good marketing. And worst of all is bad marketing passing itself off as good marketing to people who can’t tell the difference. This is a blatant case of people marketing themselves successfully even though they aren’t really marketing their products successfully. And you might well wonder how someone can market themselves and not their product. Directed incompetence? Laziness? I have no idea but when we really look at the situation it’s not exactly marketing of themselves, but more like just spin. So…it’s about people that can’t market successfully but can spin themselves successfully. And the people that are foolish enough to believe them.

Sales has very clear metrics for success. Either you sell something or you don’t. Engineering has pretty clear targets too, although less clear than you might think. Yes, you can measure whether a product works and is delivered on time but there are many second level issues such as supportability, ease-of-use, reliability, etc. that are fuzzier and harder to measure. These are the areas that separate a good engineer from a merely adequate one.

But marketing is this big fuzzy blob of stuff. And as the old saying goes, “ Yes, you are doing things right, but are you doing the right things?”

What do I mean? Let’s take a simple example. You are responsible for your company’s appearance at the yearly industry trade show. You have a great booth with excellent messages, knowledgeable staffers, good positioning…and free cappuccino and sandwiches, giveaways, a magician giving a show with key messages sprinkled in and, if your industry is male dominated, a few of the always popular Booth Babes to rope passerby’s in. The show is a huge success with swarms of people at your booth every day. You collect 2000 leads out of the 2500 people at the show and have overflowing attendance at every presentation. You return home a hero after making sure everyone in the company gets a copy of your show report. You are promoted and receive a huge bonus.

Long after everyone has forgotten and moved on it turns out that out of your 2000 leads only 2 people were actually interested in your product, and while receiving a quote neither of them actually purchase anything. But everyone has moved on, no one is measuring these leads all the way through. So that big budget extravaganza that you were widely lauded for? A financial disaster – more so if you consider the opportunity cost of wasting all that money and the peoples time to prepare and staff the event. The real customers? They were driven away by the crowds of people waiting for the next show.

Or…another favorite of mine is the universal camper. Also known as seagull team members. They sit in on a few meetings, send out some emails with information they got from someone else, and write it all up in their status reports. So in the end they get credit as being part of the team and having done the work when, actually, they just pitched their tent in the middle of the team once all the real work had been done by others. And while the team members know what really happened, everyone else gets the impression that they were actually part of the team and contributed to the effort.

Both of these are examples of spin – misdirecting people’s attention to the wrong metrics, or implied association, or even outright failure that is touted as success when the actual results won’t be seen for several quarters (and again forgotten by then). And then people wonder why, with all this wonderful marketing, sales aren’t skyrocketing. And marketing looks bad.

There is enough blame to go around here. First and foremost, of course, is the bogus marketing manager who pulls these shenanigans in the first place. Next in line is their manager who takes the easy path of bolstering the claims and, in the process, making themselves look good as well. Finally, it’s the executives who either don’t know enough about marketing or can’t be bothered to pay attention to the difference between spin and meaningful results. And, of course, who also have their own vested interest in claiming success. So in the end, no one wants to point out that the emperor actually has no clothes on.

And that’s my rant for today. .

I am a hammer: Confessions of a verification engineer

Hello, my name is John, and I am a hammer.

There is an old saying that when you are a hammer everything looks like a nail to you. And that makes a certain amount of sense. You have a specific set of thoughts, ideas and attitudes that you use when you look at the world around you. You will try to place things into a context that you are familiar with and, being the creatures of habit and patterns that we are, that means trying to relate new and unknown things in terms of what is known to us from previous experience. And that means that if all of our lives we have been dealing with nails, our first question is not going to be, “what is this”, but rather, “what kind of nail is this?”

So with that excuse for looking at the world with a specific frame of reference, I must confess that I see the world largely as a series of verification challenges. Is it done? Does it work? Is it right? Are we complete? These are the questions that provide insight into whether something is ready to rock and roll. Ready to be used. Ready for life in the big city. But even that is really not verification, not real verification, because asking if something works is just not enough. Not by a long shot. Asking if it works under a certain set of circumstances is interesting but not actually useful. Asking if it will work once is usually not enough to provide real comfort. Deciding that it looks right from one view point is likewise merely a data point, not an answer.
Verification, real verification, is about asking when it won’t work. When it is not right. When it doesn’t look complete. That is the key to understanding something. Will it work under all situations? In all settings? From all viewpoints? That is verification. So let’s not ask if it’s done, let’s ask if all the parts of it are done. Let’s not ask if it works, let’s ask if it works under all circumstances. Let’s not ask if it’s right, let’s ask if it’s right for all the people that will be using it. Those are the key questions. Unfortunately, those are also the ones that are usually impossible to answer.

I’ve been keeping this deliberately broad in scope so far in my discussion because verification applies to everything. From making dinner to designing a new processor chip. But I should probably take a minute to explain a little of why I am such a hammer. I started out in life developing hardware and software. When you write some code or design some hardware the first thing you want to find out is if it works. So you write some test code – a test harness – or you build up a test environment and see if your design works. Sometimes you actually try it out in a real end user environment (although not so much if you just designed a pacemaker or a satellite) and see if it works. And I became fascinated with that aspect of the development process. Because making something that works under a specific set of circumstances is easy. Making something that works under all sets of circumstances is harder. Proving that something works under all sets of circumstances is even harder. Harder to the point of being impossible. And what is more interesting than solving the impossible?

Now of course if you have a small design then yes, you can actually prove that it works under all circumstances. You can prove it mathematically. But who cares? We are trying to solve real world problems, and they usually tend to be fairly large. Do you have any idea of how complicated a modern processor chip is? Or an operating system? Well, yes, if you are an engineer you probably do but suffice it to say they are really really big. And so where we might be able to test something small by subjecting it to every possible set of stimuli that it could ever encounter, and validate the results, that’s a little harder to with some as big and general purpose as a processor.

And by now the non-engineers are scratching their head and wondering why they read this far since this obviously has nothing to do with them. But it does! A chip or program is merely the implementation of a process. Some things will happen, we will act on them, and there will be results. A chip does that. A program does that. But so does a marketing program. So does a McDonalds restaurant. And verification is really all about trying to figure out what could go wrong. When something unexpected happens, will this thing still work? And that applies to anything. If my data rate doubles, which of course will never happen, will my buffer overflow? If the user doesn’t reboot the system for 3 months, which of course will never happen, will it crash because one of my processes had a small slow memory leak? If your call-to-action is to call your company’s 800 number and you forget to stagger the emails will 1,000 people all try to call your 2 operators at the same time? If three soccer teams converge on the McDonalds after a tournament will the line get so big it will block the doors and prevent people from leaving because the doors are right next to the counter where people order?

It’s all about thinking of the corner cases – the things that “will never happen so we don’t have to worry about them”. Because those are exactly the things that you need to worry about, not so much the things that happen when everything goes right.  And yes, you will make trade-offs when you perform your verification. Some conditions can be prevented by significant additional expense or delay and you will simply decide to take that risk. But at least know that you are doing so and won’t be surprised if the unexpected does happen. It’s one thing to explain that something bad happened because you took a calculated risk, it’s another to explain that you just didn’t think of that. And you will trade off consequences with cost too. If an umbrella breaks, that’s an inconvenience. If a pacemaker fails that’s a dead patient.

So yes, it’s nice to come up with clever ideas – we need more of those. But the real trick is to come up with fool proof clever ideas (which is rare), or to at least come up with contingencies to handle the unexpected, and to be aware of what your exposure is and make a decision based on knowledge and not ignorance. That’s the tricky part. That’s the interesting part. That’s the nail in my world. And I am a hammer.