The founder/CEO of famo.us is Steve Newcomb. He’s been the brains behind several other successful startups. He’s also published several essays, the most famous of which is Cult Creation. I started reading it late one night, and got sucked in quickly. Much of the advice he gives is pure gold.
I’m a big believer in learning from the trial and error of others so you can skip ahead to what works. I try to read things from the most successful people I know. If successful people are willing to share their advice, it is worth listening to.
Cult Creation is a really great essay. Steve has seen what works, and what doesn’t work. The advice he gives in the essay is clear and actionable, but needs to be taken with a grain of salt. When people write essays like this, blindly taking their advice is the wrong approach.
Each person that has ever lived has their own specific set of life experiences. No two people have the exact same experiences through the course of their life. Understanding that is critical to thinking about the context behind advice.
When someone gives advice, it is necessary to first understand the context in which they are giving the advice. A person who is adverse to risk may advise against founding a startup, but a person who can tolerate risk may say to found as many startups as possible. The advise is contradictory, so the context in which they give the advice needs to be taken into consideration.
Steve’s essay is a perfect example of context making all the difference. Many things he says in Cult Creation can’t and shouldn’t be applied to a Fortune 500 company with hundreds of thousands of employees. Steve’s advise is coming from the context of starting a small, nimble startup. The things that work in that setting may fall flat on their face in a large, monolithic company.
Understanding the context behind Cult Creation makes it possible to take the principles behind the advice and apply them to a team of any size. The following are a list of the things I’ve used in different teams that can be applied at any level of an organization.
Suspend Disbelief, then Think Backwards - from Bill Keating.
When you approach a problem, there are generally two ways to solving it. You can either work from where you’re at to where you think you need to go, or start at the solution and figure out each step backwards until you get to where you’re at. The first approach is what most people do, and it can really get you into trouble. The second approach is what I’ve seen all successful people do, and it really works.
In order to succeed in both life and business, you need a clear vision of your goal. This is the founding principle of Goal Driven Development. Think of an archer trying to aim without a bullseye. Knowing where you are is not enough. Knowing where you want to go is everything.
When I approach a problem, the first thing I think about is the solution. If I can clearly state what the solution should look and feel like, then I know I can think about the step right before I get to the solution. If I can clearly articulate that, then I go to the step before that one. I use this approach until I realize there is no path from my solution back to my start, or I figure out a way to implement the path.
Hire Slowly, Fire Quickly - fromPeter Thiel.
This reminds me of a core principle that I learned in a computer networking class in college. I learned that one of the reasons behind TCP being a popular protocol is that it has a holistic approach to network congestion. When you start sending packets over a TCP connection, it increases the bandwidth slowly. As soon as it detects that there is network congestion, it decreases the bandwidth very quickly. This is known as AIMD, which stands for additive increase/multiplicative decrease.
It’s easy to see why the principle behind it is popular and applicable to many different situations. Quickly identifying mistakes is necessary to mitigate damage. Growing slowly allows for deliberate, careful planning. This advice is something I’ve heard come from managers, business owners, and even software architects.
Super A = a(a), a=a, super B=c(c),b=c and c=0 – Various sources but probably mostly Peter Thiel and alittle bit of Luke Nosek.
The formula is very esoteric, but once you understand it the idea makes sense. Programmers can be roughly divided into one of three categories. The top-tier, rockstar programmers are A’s. Below them are the B’s, which do enough just to get by. Below them are the C’s, which are major sources of entropy.
With that in mind, this is what the formula means. A’s want to work with other A’s. They enjoy challenges, and only want to work with the best. B’s want to work with C’s so that the B’s look better. C’s don’t want to do anything.
I enjoy my job the most when I’m being challenged. The challenge can come from a difficult problem to solve, trying to motivate a team, or when someone challenges me to be a better programmer. I try to work with people better than I am as much as possible. It elevates my game far beyond what complacency ever could.
I’ll continue in the next few days talking about different pieces of advise from his essay.
The post Steve Newcomb’s Cult Creation appeared first on Zach Gardner's Blog.