What do Aretha Franklin and Cisco Systems, Inc. (Cisco) have in common? They both innovated at a time well before the tide was perceived to be rising. Don’t think of this situation as the end of something. Turn that thinking around.

You could be at the beginning of something that will be great. The trouble is you probably can’t recognize it for what it is. These African American teenagers in Detroit were just enthusiastic about the music they loved. They may have had some idea or hope really that they would be great, but they were just trying EVERYTHING in search of something that felt good and that people (including they themselves) responded to. They couldn’t have seen how big Motown would become. Don’t worry that a lot (most?) of what you try won’t go anywhere. What’s important is to keep trying and iterating on ideas that hold the most promise; “More Like This, Less Like That.”

Around 1986, Cisco in San Francisco and Software Results Corporation (SRC) in Columbus were both working on a any-to-any protocol converter. SRC was better capitalized. It invested $1.5M in a team in Tucson, AZ to develop the product. Leonard Bosack and Sandy Lerner at Cisco were working out of their garage at the time. SRC structured the project as a big bang development project. They started with a blank sheet of paper and at the end of the development period, the team would turn over a finished product to HQ in Columbus. The Cisco team started with something that worked that had been developed at Stanford to connect campus systems together. They then iterated it, improving on it. Finishing each bit of development and then moving on to the next piece. It’s the only way they could afford to do it. They couldn’t afford a development team like SRC’s.

There are a lot of lessons in systems development in this story to be explored another time, not the least of which is the systems engineering approach from Stanford that Cisco and indeed SRC’s Columbus development team used that the Tucson team was not using. I acknowledge those factors played a role in the differential outcomes, but we’ll leave those for later.

The SRC Tucson team failed to produce a working product in the end AND it had exhausted its capital in the first big bang attempt, which cutoff the opportunity to iterate on the result or course correct. That game was over. Cisco created the inter-network router, which would become the backbone of the internet. The Cisco product wasn’t a any-to-any protocol converter really. It implemented a common protocol that any device could speak and connect to any other device. Each computer or device had to have its own interface, but once it was on the network, it could speak the common tongue and connect to any other computer on the network.

Cisco had to go this route because all the existing protocols had proprietary nuances that made them incompatible with a single network. Cisco’s approach began with the common network in mind. In the end Cisco brought an evolving product to market. SRC had nothing. SRC was a typical small start-up and as such made lots of mistakes. Probably not unlike Cisco, however, it’s hard not to contemplate what that $1.5M could have done to extend SRC’s runway and prospects for success.

As you are doing creative problem solving and working to be useful to your customers in the coming months, keep the following in mind:

More like:

Iteration
Small free or cheap batches/experiments/modules built on something that works
Interact a lot with other enthusiasts for inspiration and free problem solving (like the free choreography Aretha gave to Smokey Robinson)
Don’t quit, keep iterating even if any-to-any protocol converter is the wrong description for what is needed.

Less like:

Bet the farm and big bang implementations that only fail or succeed but don’t teach in the process
Large budgets
Isolated teams (a notable exception to this is a WELL-INTEGRATED team referred to as a skunk works… still I believe you would find lots of networking going on in a skunk works)
Quitting (note, you may quit a deadend, but don’t quit the quest).

Call to Action

Ask yourself; “What is the critical issue that needs to be solved (even if we aren’t the traditional solvers of that problem)?”

Frame the question in broad terms. It helps not to be too specific.
Avoid defining solutions or limiting options in the framing of the question.
In the initial brainstorming effort do not criticize ideas. Simply gather as many candidate ideas as you can.
Select the best 1-3 ideas for free or cheap trials. Give preferential consideration to tested building blocks that work.
Test out the ideas and iterate on the them to improve the results. Measure results and performance meticulously so you can rely on the result for decision making. Following each test identify what failed. Build on what worked and seek to minimize or eliminate the portions that failed.

If you’re interested in reading more, here’s the link to a good interview with Sandy Lerner that discusses early days at Cisco. And here’s a link to an excerpt at Delancey Place about Aretha Franklin and early days in Motown.