Reinventing Hackathons (Part 1): Why Top-Down Never Works

The hackathon is a mainstay of tech company culture, but what is its actual value and how can we maximize its considerable potential?

For many companies, the hackathon is a kind of tax levied by engineers in return for spending most of their time doing what they’re told. It is an event implicitly defined as a sort of seasonal rebellion against top-down planning and control as any product manager knows who has tried to hitch them to a business agenda; the result is usually a stern rebuke from the team’s most talented engineers. This is what Hackathons were like at if(we) and other companies for which I have worked whose core business is relatively mature.

A few months ago, we took a step back and reconsidered hackathons from a very different perspective, resulting in our making fundamental and sizable changes.

The Truth About Innovation

Innovation is the lifeblood of new business opportunities in tech, but it is surprisingly difficult to plan predictably for innovation. Over 80% of all startups fail outright in their first few years. This makes innovation a game governed by the playing of very low odds.

Normal, efficient business operations are geared around optimization problems (goals take the form of things like “increase subscriptions by 10%”). This makes businesses (a) totally ill-equipped to tolerate the level of ambiguity, uncertainty, and luck needed for successful innovation, and (b) necessarily opposed to it to protect the company from losses (or at least, they should be, if the right people are running the business).

Still, businesses are faced with the unquestionable need to innovate, and when they are, they tend to try what they know: some form of planning involving top-down brainstorming, market research, estimating, and business case evaluation, all ahead of permitting engineering to work on an idea.

What could be more rational? In fact, this process is the definition of being rational: start with the end in mind, and work your way down the ladder through objectives, goals, and subgoals that make up the solution, to reach that end. If any rung on the ladder is faulty, the project risks and costs will escalate, so it behooves all responsible parties to do a rigorous job of defining and validating each step as they move from top to bottom. This is how companies are organized. It is what every good course on project management and planning teaches, and it works for most ordinary business problems. Innovation, however, is not one of them.

There are many reasons this top-down approach almost never succeeds in the context of the hackathon. Here are a few of them:

1. Too many ideas are vetoed before they can be iterated upon.
2. Most of the best ideas aren’t even revealed in a top-down process, because they arise while working on other ideas. When you compare the quality (variety, practicality, ingenuousness) of ideas that arise from considering problems and goals in the abstract to ideas that arise when grappling with solutions to the same goals and problems in the concrete, the latter is nearly always better. As Picasso once said, “Inspiration exists, but it has to find you working.”
3. Many great ideas (as much as we scoff at this) are really solutions-in-search-of-a-problem, which are innately bottom-up. The top-down process is committed to identifying problems first, evaluating their importance, and only then moving onto solution if the problem is well enough defined and important enough. Engineers, on the other hand, tend to come up with solutions first and look for applications second (this is what “cool” means in tech). This is not permitted in a top-down process; in fact, the process is extremely biased against it.
4. The company fails to achieve sufficient leverage of opportunities adjacent to its current capabilities — the ‘adjacent possible’ (a hallmark of successful innovation). Many top-down ideas fail because they are too far away from the resources and opportunities that the business has ready at hand.
5. It is too hard to predict potential product/market fit from a business plan or prototype because of the astronomical uncertainty that even the best ideas will succeed. This is euphemistically called “model error”. Bullshit is the more technical term for it.
6. There isn’t enough tolerance of failure because so many ideas come from staff at the top of the organization, most of whom have egos, reputations, and, like the Pope, find it necessary to maintain a certain air of infallibility.
7. 80% of development should happen after the MVP (Minimum Viable Product) is identified, but top-down planning tends to require that far too much product is built with over-reaching involvement from PR and marketing departments interested in polish.
8. There often exists a false expectation that initial results after launch will decide whether the product should be killed or continued. The reality is that launching is just the beginning, and as few resources should be put into it as possible. The majority of resources should be invested in finding out what customers want with the product, stumbling on insights, and iterating based on those findings.
9. In a top-down approach, ideas are foisted upon employees to execute on behalf of established leaders rather than leaders emerging organically as champions of ideas they believe can change the world and make them rich.
10. The innovation team is too big and specialized to be efficient and cost-effective. This happens because the company cannot help but reproduce its departmental structure within the new team, resulting in a bloated collection of product managers, QA, design, front-end and back-end engineers. Instead, a successful new product team can consist of a couple of people with great general skills and a few deep areas of knowledge relevant to that particular idea.

You may not be convinced of the truth of these statements because such pitfalls aren’t included in the stories of how many successful products or companies became great, or how they won funding. Further, efforts an inventor pours into developing the wrong idea before any customer or investor ever hears of it are often masked by that company’s prehistory. But, consider some recent statistics:

• Only 0.003% of startups achieve >$1B in annual sales (cf. FB at $2B)
• Over 80% of startups fail outright within the first few years (Bush Institute, 2012 and Litan, 2013)

If these figures sound abstract, imagine if routine medical procedures had these success rates; one would have to conclude that doctors are criminally insane. As in scientific discoveries, which follow a similar pattern, there is a taboo about admitting how much chance is involved in success. It is revealed only in interviews and biographies long after the event. I refer the reader to numerous great books on this subject: The Halo Effect by Phil Rosenzweig, Where Good Ideas Come From by Steven Johnson, Happy Accidents by Morton Meyers, The Structure of Scientific Revolutions by Thomas Kuhn, Against Method by Paul Feyerabend, Antifragile by Nassim Taleb. The list of serendipitous discoveries is long, but some famous examples include antibiotics, x-rays, organic chemistry, DNA, chemotherapy, VX gas, Teflon, Viagra, and Rogaine.

Another way to put it is that successful innovation is a statistical “tail” event. The problem with statistical tail events is that, by definition, almost nothing is known about them (as their frequency diminishes, so does our ability to know about them).

If you now feel that it is hopeless to try to create a business process that will predictably generate successful innovation, then you have probably understood my point correctly.

But what if we could create a process that is both unpredictable *and* a reliable source of good business opportunities? Read Part 2.