This series of articles is based on a video for Space Garage. Click here to view it on Youtube.

Biographies and Self Help

Biographies on the "visionary geniuses" of our time tend to top bestsellers lists. They're fun reads but instead of acting as a case study for how to run a successful project they're more often used as a justification for waddling around in a turtleneck and treating your employees like garbage.

Are you sick of short form content on how to manifest success and the morning routines of entrepreneurs? What if project success has less to do with the amount of time CEO spent picking out their outfit and way more to do with the processes and culture within an organization? In this article we'll move past the aesthetics of success and explore a tried and true method that embraces failure, acknowledges luck and equips you with tools to solve problems at any level of any sized organization.

By the way if you're here for my takes on AI or the hypothetical problem solving machine stick around. Because while lots of things can be automated this is the stuff that AI isn't particularly good at yet. I think this is where human operators will remain for a long time.

Napoleon Hill spent his entire life trying to identify the common traits of some of the most successful innovators of all time.

He claims that with the support of Andrew Carnegie he gained access to people like Thomas Edison Henry Ford j. P. Morgan and many others. (This claim is heavily criticized as false)

With that sort of access you'd think he'd be able to pinpoint a common thread and devise a solid formula for innovation. Instead, his books and many watered down successors in the self help genre (e.g. The Secret) have little nuggets of valuable information... but when they try to put together a unifying theory for success, they end up pontificating about some pseudoscientific theory that these people have a mystical alignment with the universe.

That's because there is no unifying theory. There's just a messy pursuit and countless variables that cloud the causal factors.

Parsing success stories

When looking at successful innovators we have to be aware of the survivorship bias that comes from looking at successful projects and trying to identify common traits retroactively. This bias can lead to false conclusions about what actually contributes to success. In reality most people fail regardless of what they do and many successful people are the beneficiaries of luck.

What if these people were successful despite a lot of their eccentricities? What if they were in the right place at the right time? For every success story there are hundreds of people who worked just as hard, made the best decisions, based on the best information available and they failed anyway.

Many others achieve success by completely different and less glamorous metrics. Innovation especially in large organizations is a team effort, with great ideas coming from every direction. That's why the person at the top can be lauded by some and seen as a complete idiot or monster to others.

These people are often treated like they're divinely ordained to their tech fiefdoms, In reality they're fallible contributors to a messy process. The best ones to work with know that.

So I think at this point we can move past the lionization of these figures. While it's important to recognize that luck and failure play a role in the process not everything is completely random and there are things we can learn.

Maybe we don't have to promote sociopathic behavior as a reality distortion field but we can recognize when somebody's able to identify a problem synthesize it an facilitate a really solid execution.

There is a way to catalyze creativity, reduce risk, and improve your odds of success in a project.

This framework focuses on solving real world problems. Michelangelo believed that the true form of a sculpture was already present within the stone. His job, as he saw, it was to remove the excess material and reveal the masterpiece within.

In much the same way, effective problem solvers look at problems as puzzles to be solved not blank canvases to be filled. They operate as facilitators and curators in the process of uncovering a problem and then assembling a collection of ideas to solve it.

Most of us are already familiar with a tried and true process for solving puzzles. Various disciplines within technology companies use different terms but all of them have a process that stems from the scientific method.

Here's a short breakdown in how it translates to tech and then we'll look at some examples

Observe:

• Identify a problem and seek to understand its full scope.

• What is a user trying to accomplish?

Question:

• Here, you synthesize the problem into something that can be clearly articulated and investigated empirically.

• What are we trying to learn?

Hypothesize:

• Develop a testable and falsifiable hypothesis.

• Here's what we think and how we can find out if it works.

Experiment:

• After diverging on various ideas and weighing different options the project is formed into a testable structure.

Analyze:

• Review the results of the test see if it was successful

• See what other questions came from the data

Report:

• Communicate the results of the process to an stakeholders.

• This information can be used to express the value of your solution (e.g. case studies)

• It can also be used to improve the process next time because the next step is to...

Rinse and Repeat

• Figure out if the solution is repeatable at scale and if you can further improve it.

• Here you can start back at observation.

Note: The steps might be less linear and more recursive than outlined here. You can adjust depending on the situation.

In Part II we'll start to look at some examples of this process applied. Starting with Gwyneth Paltrow's Goop... Just kidding…

Click here to learn about Dyson ->