If you are in the startup scene, you will often hear sentences like “Do things that don’t scale,” “Psychological safety is the key to performance,” “You just need to introduce OKR,” and “Even Airbnb said they don’t experiment anymore.” Some words are cool as copy, while others sound like they should be applied to our organization right away.

The problem is that these words are often quoted without context and premise. To some, this is a phrase that appeared at a specific time, for a specific company, to solve a specific problem, but we often bring it up without knowing the background, saying, “We heard a successful company did it, so let’s do it too.”

However, when choosing a methodology or technology, rather than blindly trusting it, you should first look at why it came into existence and whether it operates only under a certain survival bias.

Google

• Through the ‘Aristotle’ project, Google revealed the five secrets of high-performing teams within the company, and the most important of them was ‘psychological safety.’ It's important for team members to feel safe about taking risks and being vulnerable in front of other team members. So, domestic startups also attempted to apply this learning led by HR people.
• However, in the early 2010s, Google was home to some of the best talent in the world and had very high hiring/evaluation standards. It was an environment where strong peer pressure was naturally created. In a situation where top talent competed, securing ‘psychological safety’ was one big puzzle piece that led to high performance. However, efforts to secure psychological safety in an environment where this was not the case often resulted in greater side effects.

YCombinator

• YCombinator is famous for emphasizing the mantra “Make something people want.” However, this can be said because the team's product building capabilities can already be confirmed during the investment screening process. You can't ask a team that doesn't have the ability to create something to create something that people want.
• Paradoxically, the reason why we can emphasize “Do things that don’t scale” is because we confirmed that it was an expandable market and invested in it. In other words, it is closer to advice given to teams that have already been reviewed and survived during the YCombinator review. It is difficult to attract seed investment in a market or item that cannot grow ten or hundred times no matter what you do.

OKR

• Before OKR there was KPI, and before KPI there was MBO. These are all good tools. However, because KPI was a system centered on achieving numerical values, unlike existing industries, the tech industry, where 10x performance was possible, needed a tool that could accommodate this. That's why OKR was introduced and was effective.
• In software-based tech, a single feature improvement can be instantly deployed to millions of users around the world and increase revenue exponentially with virtually no increase in fixed costs. In an environment with such “economies of scale + network effects,” aiming for 10x performance is a realistic strategy, and OKR targeting this may be a good fit.
• So, it is a good tool in the software-based tech industry where it is possible to aim big and achieve big things like 10x results, but it may not be very useful in places where it is not possible. In fact, most of the widely known success stories in Korea are focused on the software/tech industry.

Airbnb

• Since last year, Brian Chesky, founder of Airbnb, has been presenting a counterargument to existing startup management practices, calling it Founder Mode. Among them, what I remember is, "Don't experiment with A/B testing by changing a single button color or text. Only conduct necessary experiments based on hypotheses, and make responsible decisions about the rest with a sense of design and customers."
• This is because some people cited this and said that there was no need to conduct an experiment. What's interesting is that Airbnb has been considered one of the organizations in Silicon Valley that does the most A/B testing and is best at it. An organization that has pushed through A/B testing to the end and goes through a process of consensus is somewhat different from an organization that avoids A/B testing based on “Airbnb also reduced its testing” without proper experience in conducting experiments.

Now, let’s re-evaluate and approach the things we have ignorantly said or heard – “Do things that don’t scale”, “Psychological safety is the most important”, “Introducing OKR will solve the problem”, “Airbnb is no longer experimenting either”.

Agile, which may be an object of love and hate for some people now, came out to escape from the pain of waterfall, and Java Spring is also a fairy compared to J2EE. Then, if we go beyond the blind adoption/hate of Agile and love/hate of Java and understand how the situation we are in matches the problem they were trying to solve, we can make a more appropriate choice.

In the flow of time, we are currently at a certain point of growing pains, so it is good to think about how we can overcome this point and successfully meet the next one. This is because the introduction of a single methodology or technology will never solve any problem 100% or forever.

Thank you.