The key habits of starting up
Reid Hoffman said it once starting up is like jumping off a cliff and trying to assemble an airplane on the way down. In order to deal with uncertainties, we must first have the right habits. Oftentimes in starting up, we focus frantically on building, but not enough on testing, code review, or organization. Stephen Covey spoke about the seven habits and Charles Duhigg brought up the concept of anchoring habits. The same holds true for starting up. If we want to be ready for any uncertainty, we need to be certain by having the right set of habits.
Nothing matters but habits!
Key habits is one of those things that are not often talked about in Silicon Valley. It is one of those implicit assumptions that every engineer must already know. In starting up, before product-market fit and before product, the only thing that matters is pace. None of the other things like idea, product, or market really matters until we are able to get to a certain speed. Without the proper airspeed, nothing will ever take off even with the best vision in mind.
Based on my experience from working with some of the best engineers from Transmeta, Linux, Stanford engineering graduate school, and StartX community, we know when we are working with an Elon Musk or Jack Dorsey type. There is something intense about their personality and the way they work. We can certainly learn a lot from these great entrepreneurs and their habits.
When it comes to habits, I am not referring to the Type A alpha male personality epitomized by Harvard MBAs. Myer Friedman did an interesting study on Type A personality back in the 1950s. As a cardiologist, he was noticing Type A is more prone to heart disease than Type B and got him thinking whether Type A is a necessary condition for success. From his findings, Type B is not necessary less intelligent or less ambitious. In fact, Type B also has a considerable amount of drive, but the way they look at life gives them confidence and security, instead of being irritated or infuriated as projected by Type A personality.
If there is one lesson we can learn from the Alibaba story with 18 cofounders, anyone with any background can become the ultimate startup team. The founders are not necessary superhumans as projected by the stereotype. If anything, thinking we are superhumans is precisely the problem that creates the fixed mindset. Instead, we are ordinary people that can grow to develop extraordinary skills. And, I surmise that there is a set of habits that we can cultivate, as individuals and as a team. While everyone tends to focus on building products right away, I think it is more important to focus on preparation as the first step of the entrepreneurial journey.
How do we help ordinary people to develop extraordinary habits? Dave Logan stated it eloquently in his book called Tribal Leadership. One of the keys behind successful organizations is to help move people from stage 3 to stage 4 and beyond. The superhuman founders of the past is the stereotypical Type A personality with stage 3 characteristics. Everything they do is about “me”. We now know how limiting this type of founder could be as the organization grows. Stage 3 entrepreneurs tend to be competitive, non-collaborative, and non-giving. Ironically, stage 3 entrepreneurs often feel like everyone owns them. They are the takers who would squeeze and borrow from everyone around them for their own goods. Whereas stage 4 is about “we”. It is about learning, collaboration, and sharing. If you hear someone often uses the word “I” instead of “we”, that saids it all.
With this in mind, let’s start with the right habits now.
Continuous learning and improvement
“Knowing is not enough; we must apply. Willing is not enough; we must do.” Bruce Lee
We need to be learning at every level. From a company perspective, are we making improvements to the process and infrastructure every week? From a product perspective, are we making incremental improvements weekly? From an individual perspective, are we learning something valuable every week? If we can spend one day out of the week for learning something new and if we can spend time weekly on cross training, the resulting output over time would be enormous.
Building for iterating speed
From our own experience in starting up, we learned a few painful lessons in going super fast without the proper infrastructure in place. The code would break every time we tried rushing out to the market.
We recently came across a very useful blog by Edmond Lau, a former lead engineer at Quora and Google, which summarizes this problem the best. Optimizing for iteration speed means:
Building out continuous deployment with a fast deployment process.
High test coverage to reduce build and site breakages.
Fast unit tests.
Fast and incremental compiles and reloads to reduce development time.
Automate wherever we can
While it might feel like we are saving time by not developing automated tests, we actually end up spending more time and energy doing more manual testing. I know this might sound obvious. But, in a startup environment when everyone feels the pressure to ship rapidly, it is very tempting to take shortcuts at the expense of others. Automated testing is a must for making continuous deployment as different people work on the same codebase.
Testing should be done by the original code authors when the code is still fresh in minds. Otherwise, it would take enormous amount of time for someone else to test and validate months later without knowing the logic behind it. Each coder needs to be responsible for validating his/her code through strong unit testing. When this happens, this encourages good engineering practice since it is ultimately the responsibility of the code authors to write quality code.
Code review and documentation
From the perspective of continuous learning, we should encourage code review and documentation. It is perhaps one of the best ways to learn from others by exchanging best coding practice. In addition, it would help us reduce the technical debt incurred from quick hacks and untested codes. Code review forces us to have the discipline to pay off the technical debt periodically before it becomes unmaintainable.
We need to write Pseudo code and use it for our code documentation. We need to have an internal wiki and document design processes (system level, backend, frontend, how to write css, how to handle exceptions, how to make database schema changes, etc).
Improve Code Quality and Organization
We must have a clear organization of models, common methods operating on models, business logic, presentations, etc. For example, looking at one url on the site, we know exactly where to look for views and tests.
We must have high standards code to increase maintainability by different people.
We must have unit tests for common and essential codes, crud operations on models, and business logic.
Open Discussion
By no means this is meant to be a comprehensive list of successful habits. Instead, we hope this helps to get people thinking about it in preparation for starting up.
This was written in collaboration with Michael Zhang. We invite you to share your thoughts about habits and starting up.