Field Notes Inside an Integrated Communications Agency

A "disruptive technology" is a breakthrough that radically changes the way that people and organizations get things done.  They often destroy or alter existing markets while creating opportunities for ordinary people to do things which had previously required special skills or a lot of money.  Digital photography is a good example of a disruptive technology.

The time has come for a disruptive technology to allow non-traditional gamers to express themselves and solve problems through their own video games.  Conventional wisdom has embraced the concept of the serious video game and well-respected people and institutions are now upgrading their graphics cards.  Sandra Day O'Conner is leveraging her name recognition to produce an educational game.  Fortune-500 companies are hiring development firms to write elaborate simulation games to solve real-world problems.

But what if you want to make a serious game yet you aren't a former Supreme Court justice and you don't have a team of application developers living in your basement?  Fortunately, there are a few new (and free) products on the horizon.  We are still in the early days of this movement so the tools are still primitive, but encouraging nevertheless.

• Microsoft Popfly (currently in alpha).  This is brand new and fun to work with.  It's shows some promise to bring real-time information into the game world, mash-up style.
• Second Life.  You've already heard of this one.  Its in-game crafting system lets you make games that can be played by other Second Life players.
• Many others.  There is a plethora of options, ranging from very limited map editors to sophisticated game engines with steep learning curves.  Wikipedia keeps a list.

Communicating complicated ideas with others can present a lot of challenges - especially when you don’t share a common language to build on. In my role as a technologist at Capstrat, I can assure you that the toughest part of my work isn’t doing technical stuff, but rather creating understanding between technologists and non-technologists. You have to be able to communicate about technology so you can communicate with technology.

But how do you do that without all the techo-jargon mumbo jumbo? Should you even try? In my work, I’ve stumbled across a common bear-trap which I call the French Menu Syndrome. It goes something like this:

Suppose you run a fancy French restaurant. You’re going for discerning diners and elegant haute cuisine. You hire classically trained French chefs from Paris, and give them the equipment and ingredients they need so you can offer the best in fine French dining. Authenticity is the key.

The French chefs construct a painstakingly-crafted menu of carefully chosen, wonderfully creative and enticing dishes. The menu is like poetry; a sonnet sung in honor of fine French cooking. You welcome your guests and proudly present them with the menu your chefs have so lovingly authored. There are some raves, but you’re surprised when the majority of your guests aren’t as impressed as you thought they’d be.

Your fancy French chefs composed their opus in French (naturellement). But it turns out there are lots of folks who like French cooking and fancy French restaurants who don’t actually know any actual French. No problem - we’ll just translate our menu into English, and that way people will know what to order.

Except that most of the French dishes have proper names that don’t translate into English.

OK, no problem again. We’ll just include a little description of the dish in English alongside the name, and all will be well.

Except now, your guests are just as confused by all the cooking jargon, and some of the ingredients don’t translate cleanly either. Turns out that around here, not everyone knows the difference between a bechamel and a bearnaise.

In an effort to embrace your full audience, you eliminate anything that could potentially be confusing. Before you know it, you’ve changed the name of your restaurant from “Chez Jacques” to “Jack’s Place” and your menu reads like, “Beef cooked French-style in a creamy sauce with veggies. Yum!”

Hold on a sec, wasn’t the whole idea here to be fancy and authentic? Didn’t someone mention discerning diners? Come to think of it, those rave reviews have dried up and the discerning diners don’t seem to come around any more. Not only that, but now your fancy French chefs shout curses at you (at least you think they’re curses) whenever you get near the kitchen.

Even at a strategic communications agency, we get caught in this same paradox when we’re not careful. Our government relations, graphic design, PR, video production and technology teams have all occasionally had our respective varieties of jargon end up in front of people who need our services, but only understand those services in layman’s terms. Even worse, we sometimes create communications in broad, general terms that leave our clients’ in-house experts (like their internal IT teams) with too many questions - not least of which is, “do these guys have the chops to do the work”.

So where’d we go wrong with our fancy French restaurant? At what point do we stop looking for baseline common denominators? How do we satisfy our discerning diners who expect authenticity without narrowing down our clientele to just a few fickle foodies?

If you’re running a fancy French restaurant and you’re not in Paris, how about this: throw away the menus. Hire chefs who can also come out of the kitchen and meet guests. Invest in some really fancy, really talented, super-knowledgeable fancy French waiters. Don’t compromise on authenticity, but realize that the biggest part of your task isn’t being authentic, it’s helping your guests experience and appreciate the joy of fine dining. You may not win over the Golden Corral crowd that way, but c’est la vie.

The point is that there’s no shortcut. There’s no menu in the world that can connect with each guest and gauge their respective comfort levels with french and cooking jargon like a person can - any more than a single proposal, project plan or statement of work can serve as a one-size-fits-all channel for communicating an idea or a solution that has some kind of specialized expertise behind it. That’s why when you work with Capstrat, you’ll probably end up face-to-face with the graphic designers, user experience designers, web developers and other specialists who’ll be working on your project.

And they’ll speak English.

Many years ago I was traveling in the UK, and found myself in a little pub in Wales making friends with some locals. Wales is an awesome place to visit, but if you don’t know any Welsh, the place-names can be tough to work out. They look like unpronounceable jumbles of consonants - some of them might as well be in Chinese. After a few drinks, I built up the courage to ask my new Welsh friends, “so what’s up with the way y’all spell stuff?”

The answer, they told me, was that centuries ago it made it a lot harder on English invaders when they couldn’t actually say the names of the places they intended to invade and occupy. Basically, they were telling me, they spelled stuff that way to intentionally screw with English-speakers. And it’s a plan that clearly works on modern-day invaders as well.

I’m not sure whether that’s actually true or just what they tell tourists in the pubs. But I’m reminded of this because I’ve been reminded so often recently of how difficult it can be sometimes to communicate with clients and colleagues about technology.

I belong to the technologist tribe. I spend at least a little time out of every day doing technical stuff, writing computer programming code, and discussing technology with fellow tribespeople. At the risk of dating myself, I’ll just say I’ve been at this for quite a while. So if you’ll take my word for it, I’ll let you in on a little tribal secret. All this technology stuff isn’t even a tenth as complicated as you think it is. No really, it’s not that hard. What’s hard is talking about it.

Everything hard about technology is in the language: learning about technology from manuals and experts, describing it to people who are unfamiliar with it, asking for what you want, understanding what you’re being asked for - all of it really, really hard.

As someone who’s been in the tribe for a while, I can tell you that becoming a productive technologist is a lot less about the ones and zeroes than it is about simply learning how to communicate with fellow technologists, especially when it comes to teaching it to those who know less than you and learning about it from those who know more than you.

Communicating with people who don’t know any of the ones and zeroes stuff is an even bigger challenge. They need technologists to build technology for them, but they don’t have the language to ask for what they want in a concise way. Sometimes they have a hard time describing what they want in a vague way. How big a problem is that? Try this experiment: think of a popular song. Now find someone who knows how to play guitar or piano. Describe the melody, but don’t tell them anything else about the song you’re thinking of. Do it without reciting lyrics, humming or using any musical jargon. Unless you can get creative about how you communicate with your friend, then it’s not a question of whether you’ll succeed, but who’ll be first to get too frustrated to continue.

With that same kind of barrier between technologists and non-technologists, it’s not surprising that folks who are decidedly not in the technologist tribe can often get frightened, confused, frustrated and even a little pissed off when confronted with Klingon-sounding technical jargon. There might even be the slightest suspicion it’s not Klingon, but Welsh: that technologists’ language is intentionally obfuscated and dense, crafted to keep the magic within the tribe.

For the most part, that’s not true. But what is true is that both technologists and non-technologists are complicit in perpetuating a communication barrier that extends beyond just acronyms and technical terms. You have to be patient (and creative) if you’re going to get your ideas across that barrier. Understanding how and why the miscommunications happen, and how we’re each complicit in making them happen is key to getting there.

So why do technologists use so much jargon? Wasn’t the word “blog” jargon just a short while back? How and when do we get ourselves into these language-barrier predicaments, and how do we get ourselves out of them? In the next couple of articles, I’ll discuss some of the specific challenges we technologists face in discussing technology with our colleagues, our clients and each other, and how to overcome the urge to reject anything and everything that sounds like Klingon (or Welsh).

One of our most important goals at Capstrat is to be a step ahead. To a senior developer, part of being a step ahead is knowing what the tools are capable of. As we craft a story, some of us are constantly looking forward to how an idea will be built. While limitations of technology may close down some ideas, the capabilities of technology open up new ones. The ideas and the technology often play off each other and drive ideas forward in exciting and new ways.

Adobe, Apple, and the open source community are out there creating tools for this new media landscape. This software allows "creatives" to develop innovative communications. Good tools have been, and always needs to be, a step ahead of the people who are a step ahead. They allow us to be creative, make promises, dream big, innovate, and deliver.