You can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something — your gut, destiny, life, karma, whatever.
About a month ago the Huffington Post published a widely shared article: "Steve Jobs' 1983 Speech Makes Uncanny Predictions About The Future," hinting at the fact that in addition to being a marketing, design, technology and otherwise genius, he was a modern day Nostradamus to boot.
But read the article. Steve Jobs in no way shape or form predicted the future. He envisioned how wireless connectivity should work, how technology could become a deeply integral part of every part of daily life, and made it happen over the course of decades (and a good number of failures). Steve Jobs did NOT predict the future, he invented it.
Why does this matter to you, who are neither Jack Kennedy nor Steve Jobs?
Because it is becoming increasingly impossible to predict the future but diminishingly effective to look at the competition and engage in checkbox-wars-faux-innovation. It is increasingly easy to make a business case for or against nearly any approach to any problem, and the interconnectedness and complexity of nearly everything renders traditional 12 month planning cycles barely useful, and increasingly time consuming.
But do not despair! This may look like a paralytic situation, but it is the perfect time to tweak the rules and reframe the question. It is a liberation.
Rather than spend the majority of time and effort trying to predict and account for external factors, the near collapse of this model gives us license, permission and imperative to focus on internal ones.
The Simple Way Forward
1. You must decide what really matters, and use that as your primary guide.
This has traditionally been an overlooked discussion in business (with a few notable exceptions). The discussion of why has exploded (thank you Simon Sinek) (though few know how to do it, but this is another discussion).
Understanding what really matters — the outcome you want to deliver — is now the only meaningful, durable, criteria for decision-making. It is the future. What do you want it to look like? What do you feel in your bones? What do you believe in?
Without this, decisions are random, reactionary, political and rapidly remade, and unmade if they are made at all. This is what Mr Jobs was referring to when he says “you have to believe in something.” It's your only viable guide (and while I applaud and wear Toms shoes, when I talk about a purpose-driven company it is this that I mean, not that).
2. This is not an excuse not to think, but an invitation to think harder.
The great remaining benefit of planning is that, when properly done, it thinks through the problem rigorously and unpacks the foreseeable details. To avoid this is simple laziness.
3. HOWEVER: we know that reality will intervene in unpredictable ways.
Our responsibility, therefore, is to build resilience into our work. That is to say, establish times, places and mechanisms to understand and acknowledge reality and respond accordingly.
This can take many forms. The simplest is to work in short phases. That is, rather than planning a year long project, break it into pieces.
4. But business is planning, right?
Planning assumes that you can predict the future. We grade our performance based on how well we predicted the future (metrics). We think we can look at the metrics, use them to improve our predictive capabilities.
So if we accept that we can’t predict the future, are metrics still useful? Yes! Metrics become guideposts and diagnostics. They help us to understand where we are and how well we understand cause and effect. They are not goals, and they are not meaningful in and of themselves. If something isn’t working, your metrics are your way to get deeper insight into what is not working. If it is working, metrics can help you recognize that.
Planning itself needs a new approach. Engineers began to figure this out about a decade ago. In counterpoint to the traditional waterfall method, they chose agile and agile-ish methodologies for software. Software engineers adopted agile, because waterfall (design intensely, build a schedule based on design, execute) methodologies turned out to be such appallingly bad predictors of success. (I look forward to any takers on the Agile debate — its effectiveness, whether and when its actually used, blah, blah, the point is it was a significant attempt to change the game that was interesting enough to go mainstream-ish.)
- Are You Too Old to Work in Tech? IT's Midlife Crisis
- If Hadoop Disappears, Will the Label on Your Distro Matter?
- Inside Acquia's Gartner Ascension, Web CMS' Next Road Trip
- Customer Success is a Failure
- SharePoint is Already Legacy
- Has Google Just Reinvented Gmail?
- Wake-Up IBM: OpenText Offers Lessons on Cloud Computing