I build software for a living. I started out in quality assurance in the 80s and now I’m responsible for a reasonably large engineering organization tasked with developing four very different products. This week, the team sat down with the executives at the company and basically asked for several million dollars to finance the development of out product.

They said yes.

I’m assuming the process is similar at various large-ish companies. The engineering and marketing teams put together the goals for the next release, they throw together some designs and some pretty slides, and then take the dog and pony show to the execs who nod a lot, ask a few questions, but ultimately trust the team to do what is best.

Sounds easy, right? Want to know the hardest part? It’s not finding good workers, thinking up innovative ideas, or even the laborious bureaucracy? it’s simple communication.

Before I explain, let me first confess that my prior gig was a start-up. Getting product approval involved getting the CEO, the CFO, the VP of Marketing, and myself in the same room for half-a-day and, viola, we had a one year product roadmap. I am used to having complete access to the decision makers, so big company development processes is terra incognito for me. The good news is that I’m pretty much done with a full design cycle and they only big surprise was how much confusion (and subsequent extra work) was caused by a single poorly defined word.

The product in question is mostly irrelevant, but one thing that is does involves file synchronization. For those of you who aren’t computer science majors, file synchronization is really, really hard. The basic idea is trivial: I’ve got one version of a file on my portable or PDA and another version on a server/desktop. File synch tools attempt to compare the two file, determine which is newer, and copy the newest version to the right place. (I.e. if the server is new, we copy to the portable device and vice versa).

Simple, right? Just compare file modification dates and you’re ready to go. What if BOTH files have been modified in BOTH locations? By different people? Yuck. File synchronization goes from being a mouthful to being darned near impossible depending on what you ask of it. It doesn’t help that it turns out that most people don’t have a clue what it means.

In order to get my product built, I had to present to five different groups of people. There was my immediate team of engineers, my product managers, my marketing folks, my senior management, and the executive management. My presentation had a good statement of direction, some slick architectural slides, and an aggressive schedule. I included a bunch of statements by customers who claimed our product would solve all their problems? I thought I was very well prepared.

The problem was I did not define synchronization in terms of the product I am planning on building and not a single person asked. This meant that everyone who walked out my presentation had their own personal definition of what synchronization meant. Some thought it was just backing up files, others thought it was the basic single user case I described above, while others thought it was the sophisticated multi-user case. No one, except me, really knew how we were tackling synchronization.

Here’s what happened. People from the engineering meeting met with people from the marketing meeting and the marketing folks said, “Hey, did you hear about the cool product Rands team is building? It does multi-user full file synchronization!” The engineer types — who had the best idea of what we were planning — would look at the marketing types like they were crazy, “No he’s not, he’s doing the simple case because the multi-user case is damned near impossible.” “WHAT?! That’s not what he said in his presentation! We can’t market simple synchronization!”

And so on…

By the time I got to the executive review, the hub-bub about the synchronization vagaries had bubbled up to various VPs along with the usual grapevine signal to noise degradation. The rumor that my head was deeply implanted in my ass regarding this particular product was firmly entrenched in various powerful brains which meant I got asked some fairly tough questions mostly in the realm of, can you guess, synchronization.

Fortunately, I actually knew what we were doing with regarding to synchronization and that we would be developing a compelling product with that strategy. When it became clear to everyone else that I had a clue, they recommended that I circle back with the various product fiefdoms to “make sure everyone is goal aligned”. What should have been five meetings turned into ten and that doesn’t include the time reworking multiple presentations and specifications to carefully describe our synchronization strategy.

It’s easy to blame the word synchronization in this story because it’s so ripe for misinterpretation, but that is not really the point. Big companies are big because THEY HAVE LOTS AND LOTS OF PEOPLE. In my prior start-up life, the synchronization confusion would have never had a chance to grow out of control because I saw everyone responsible for getting product out the door every single day. Hallway conversation does wonders to contain viral rumors.

I’d like to give some good advice here to others facing large company communication problems, but so much depends on what you’re trying to trying build, who you need to ask permission of, and what’s the relative aptitude of those influencers and decision makers.

Perhaps the best advice is to carefully look for those blank stares when you’re presenting especially if it’s on the face of your VP of Engineering. Blank stares indicate confusion and confusion means more meetings.