Many years ago I saw a great cartoon that completely encapsulated the leap of faith that is a crucial part of every entrepreneur’s dream. The drawing showed a guy standing under a series of thought bubbles reflecting the development of his great new business idea – each one stepping sequentially from its creation thru its development and on to its commercialization – and right smack in the middle of the chain was a modest little bubble which read “miracle happens here”. For me, that simple illustration said everything there was to say about how critical faith and perseverance are to the success of a startup. And how sometimes - to get from here to there – it’s not about seeing; it’s about believing. You have to believe it first; concretely envision it next; and then, ultimately, you can convince others to see it as well.
But, in addition to that initial take-away, what I have retained all these years later is a completely different thought about that critical link in the process which has helped me to understand and formulate inexpensive, practical and rapid solutions in many cases for small and large businesses which can help to move things forward without asking anyone to bet the farm. This isn’t a new concept in some respects – we’ve all heard the idea of “try it before you buy it” for years. And I used to remind my MBA students that you never wanted to test the depth of a puddle by jumping in with both feet. Making cheap mistakes and getting over them is an art form.
But this simple concept continues to be a major challenge for large businesses who want to introduce new ideas and innovations to their businesses, but who are also are trying to deal with the need to deploy enterprise-wide solutions and manage the spaghetti code of decades-old legacy systems. They long for the speed, flexibility and low costs of the startup world, but they’re stuck in an environment where the passage of time and the prior investment of millions of dollars makes it harder and harder to change or abandon the constraints of business as usual. They need an approach which will let them investigate and iterate before they invest and integrate the new solutions into their core operating code. And they need a buffer to be sure that – while they’re trying and testing the new tools – they aren’t infecting or disrupting the ongoing business. This is actually easier to accomplish than it sounds, but – by and large – it’s got to be done in partnership with outsiders who can take a fresh look at the situation and create solutions which – very frankly – the people who got you to the breaking point are the least likely to come up with. The people who built and created the problems aren't going to be the ones who fix them.
My solution – which I call “sneakernet” - isn’t ground-breaking or revolutionary – it’s just the absolute heart and soul of how startups think about these things – and it’s also something that these big businesses just can’t seem to independently arrive at as an efficient approach to solving their problems. They need our help to get over that first hurdle of “good enough” where you’re just doing something – quick and dirty – with duct tape galore – in order to get the ball rolling and to get things going. It won’t be pretty – it certainly won’t be perfect – but if you wait until it is, you’ll never even get started.
As with everything, we start with a definition. It turns out that - in the real world - properly defining the problem gets you more than halfway to the solution. And, as often as not, the solution that you need to get the ball rolling is something that’s painfully obvious and sitting right in front of you. Very often, it’s not a step or two forward; it’s a look backwards at how things used to work and how they were done before all those ponderous and sclerotic systems and expensive computers got in the way.
So what exactly is a sneakernet?
It’s a solution that doesn’t try to solve 100% of the problem on Day One or create a comprehensive and complete, stem-to-stern, process that will cost too much and take too long and which will - most likely - never see the light of day.
It’s an approach that says: if I was starting from scratch and just had to get the thing from here to there, how would I do it? And we all know that you wouldn’t try to do it (while you still weren’t even sure that it would work) by trying to directly connect it to your main operating systems – even if you could.
It’s a back-to-basics perspective that recognizes that sometimes shoe leather and sneakers are better system connectors than 6 months of re-engineering, thousands of wasted man hours, and unending attempts to get two separate systems to talk effectively to each other.
When we couldn’t solve things the hard way, we took a much shorter and simpler path and just walked the data from one system over to the next. And even when we had to re-enter critical information and notwithstanding the redundancies, the truth is that we got the job and the tests done and we actually saved time, money and a lot of sleepless and sweaty nights.
If you can’t breach the four walls of an enterprise or legacy system and get your job done directly, the next best attack is to step back and do things the old-fashioned way for a while – especially when you’re just trying something new.
For example, if you can’t readily or inexpensively integrate a new mobile ordering system with your old payment system (and you know you absolutely can’t), then do it the easy way. Capture the orders quickly and easily from the new mobile system (thereby making your customers a lot happier), print them out, and then quickly walk them over and re-enter them into the payment system which will take it from there. That’s a classic sneakernet approach.
It won’t scale, but who really cares? For the moment, you’re just trying to see if the dogs like the new dog food. It doesn’t need to be industrial strength – it just needs to get the job done – and no one really needs to know what’s or who’s behind the curtain. It’s really not important how or who moves the critical information; it’s just critical that the information move.
It’s smart because you limit your investment and your dedicated resources while you are still able to effectively test the consumer’s interest and appetite in the new approach.
It’s secure because there are none of the data issues that a real-time connection might entail and which would give your IT people ulcers for sure.
It’s swift because it is supplementary and additive to everything you are now doing and can be immediately implemented without any material changes or integration into your current operations. To those ancient and immovable legacy systems, it looks exactly like the “same old, same old” but you’re actually appending new solutions to the system.
It’s a sneaky sneakernet.
PS: “You Get What You Work for, Not What You Wish for”
