[Leadership laws] The innovation law of the Babel fish

You are only done scoping work when everyone involved downstream could – barely – understand what you are talking about.

[Leadership laws] The innovation law of the Babel fish
Be understandable to all ... from the start

The innovation law of the Babel fish

You are only done scoping and ready to start projects
when everyone who'll be involved downstream
could – barely – understand what you are talking about
and in theory start acting on aspects that relate to them now.

Quick description

In the classic science fiction story The Hitchhiker's Guide to the Galaxy by Douglas Adams the novel's hero manages to travel the universe in part because he can understand all the aliens he meets. How does he understand them all? He has a "Babel fish." As the story describes:

"The Babel fish is small, yellow and leech-like, and probably the oddest thing in the Universe. It feeds on brainwave energy received not from its own carrier, but from those around it. It absorbs all unconscious mental frequencies from this brainwave energy to nourish itself with. It then excretes into the mind of its carrier a telepathic matrix formed by combining the conscious thought frequencies with nerve signals picked up from the speech centres of the brain which has supplied them. The practical upshot of all this is that if you stick a Babel fish in your ear you can instantly understand anything said to you in any form of language."

Just like the babel fish acts as a universal translator, so must your team have something that makes your work instantly understandable. Only then can you productively engage the “greater universe” of your organization and have any hope that people will understand what you are talking about.

Litmus test

You only have an understandable description of your work if everyone whom it affects now or in the future can understand the outline of it.

To be explicit: Normal "project charters" are normally not enough and do not "comply with" the law of the Babel fish!

Not only are those documents often written in such a politically careful way that they have lost most real meaning, in an effort to appease all and offend none. But also, they are usually written specifically for the needs of a small group of executives–a "steering committee," "advisory team," "stakeholder group," or whatever term you happen to use.

In the end though, your work must be understandable to way more people: Collaborators who will do later work on the project, business teams that will take over once you have proven it all out and it's ready to scale, partner teams who have to support your efforts like Finance or HR, and more. Many if not most of them will need more and other "things" than a project charter truly to understand your work.

But isn’t it enough to inform them later? No, it isn’t. for one thing, you will surprise them. Few people like that. For another thing, if you never considered their perspective, you are unlikely to have accommodated it, even if it would have been easy early on.

How to do it

Show a charter, early design, or other description of the work that you will do to trusted people experienced in every discipline needed to bring your idea to life.

(Note, you will need to tailor this to the audience. E.g., you will need something very different when talking to a Design team vs. a Finance team. You might even need to use different media: Documents, slides images, physical prototypes, numbers, or more.)

Ask them:

  • “Let's say my team were to work on this.
  • What 3 topics will decide the success or failure of this, in your mind?
  • What 3 things would your team would do first, to bring this to life, as it relates to you?”

If they can't answer both questions, you have not yet described your work in ways that they can understand. Go back and change how you introduce your work until you see understanding in the other person's eyes and specific, meaningful answers out of their mouth.

Mind you, their answers could be "this will surely fail because it's a terrible idea" and "my team would do nothing to bring this to life because this should not come to life." That's actually ok. At this stage we only care about their ability to understand what you propose.

But you can get value from the content of their answer too, of course. Just treat their answer in the spirit of a design researcher, who does not care whether a user likes an early solution prototype or note. The prototype can evolve. They mainly care about the reasons for why a user did or did not like the prototype. Those reasons give the researcher insights into the users needs and unsolved problems. So you might follow up with something like:

  • "Oh, this is a [terrible/ great] idea, you say? Thank you for sharing that. This is just an early prototype. I don't care about it. I care about your perspective on it. Tell me more: What about it makes it so [terrible/ great]?"


During an innovation project in the Retail industry, my team and I created physical experiences that shoppers might eventually experience in stores.

It was important to us that store team leaders would approve the experiences being put into their stores. And we knew that they would ask their Safety & Risk Mitigation team whether the experience would cause any safety concerns to employees or customers.

So we asked members of that Safety & Risk Mitigation team to come and see a prototype of what we were creating. The prototype was very early and crude, like the set on a theater stage, not anything like a production-ready solution for a store.

But even so, the Safety expert understood what kind of thing we were planning, sufficiently so to be able to make judgement calls about it based on their expertise in a matter of seconds. Their overall take:

"Got it. I understand what you are doing here.

It's different from what we've done before. So there'll need to be some work to make this work in all our stores.

But that's 'just work.' I don't see anything here that concerns me. No real risks. Simply make sure you [tackle this one issue over here], and we can deal with the rest when we get to it."

The whole meeting lasted maybe 15 minutes, including all introduction and follow-up. And even so, it helped us know early on that we were heading in a direction that others could understand and act on when the time came.



As mentioned, the concept of (and quote about) the Babel fish stems from the Hitchhiker's Guide to the Galaxy. Current edition:

Adams, D. (1997). The Hitchhiker’s Guide to the Galaxy. National Geographic Books. http://books.google.com/books?id=CgeNEAAAQBAJ&hl=&source=gbs_api