Stop looking for answers, just think!

What is your first action when someone asks you: "How much calories does a banana provide?", I bet many of us will pull out a phone the same way a samurai pulls out their sword in a fight, and get an instant answer from search engines like google in a few seconds. This works great for daily and simple questions that has no ambiguity or innovative element to it.

But, we are doing it too much, to the level that out brain developed some "muscle" memory that always tell you that the quickest and the most accurate way to get an answer is to "Search or Read a book".

This gives us the illusion that everything has an answer, until we start solving real problems, filled with nothing but ambiguity with massive complexity. That's when we realize that the answers do not exist, and you have to follow every tiny leads to come up with one.

If you are one of the ones who at least try to come up with an answer yourself, then congratulations since you are still considered innovative or having critical thinking. In worse cases, people follow their brain's "muscle memory", search for an answer online or in books, then just copy/paste them directly as the answer. This brings more harm than good, as I will demonstrate during a few stories below:

Story 1: SRE Book is a historical book, rather than the god's words

Ever since the SRE Book was published, a lot of companies takes this as the words of god and follow the practices blindly. This consequently reduce innovation in SRE space, and made one of the author very disappointed.

SLO is one of the things that get adopted a lot, but SLO itself has it's own weaknesses, but people did not think about this and just copy/paste this model into their workflow. By doing this, they do not necessarily solve the actual problem that they are having about reliability, and introduce unnecessarily burden on the engineering team (e.g. invest in this random methodology that is copied/pasted from a book).

Luckily, there are a few places which do not follow the book blindly, and came up with their own way of doing SRE, one of them is the idea of Product Reliability Engineering. The idea is that the customers do not care if your system runs 99.999% of the time as long as they can get their tasks done. As a result, people can get away with SLO, and build an entire different monitoring system that revolves around maximizing the pleasure of customer journeys on the platform.

Another idea was not having SRE altogether, because for one company, the customers do not have any other options to switch to if their system goes down, so why bother investing in SRE if it does not make any dent in the company?

Story 2: How Apple stays on top of the game?

How do you think Apple designs their iPhones? Do they search Google for "How to design a phone camera"? Of course not. What they do instead is talking to customers, doing research, conduct experiments, gather ideas with the teams. This is exactly how they lead the market, by stop looking for answers, and start thinking. Once Apple releases their new iPhones, other brands start "looking for answers" by just copying Apple and think "this is the answer".

These companies will never be able to compete with Apple, even if one day they suddenly own all the Apple's designs and source codes. Why? Because what's most valuable is the thought process and understanding of clients, the designs and the trade-offs made. As such, companies who gets the codes or formula of the product will always lag behind the original's company innovation on each new version of the product.

Story 3: Takes your leads' words with a pinch of salt

I once worked on this project which sits between 2 different teams, each having their own Tech Lead. As I'm approaching the project launch, each Tech Lead raised their own concerns based on their perspective, and they are conflicting, meaning that I cannot proceed because if I implement something following one's comment, the other one won't approve my change because it's against their wish.

This happens for a while, until I realize that their comments are not the "answers", but "alternatives" and "ideas". What I did was looking for the answer myself:

• Reaching out to each stakeholder to understand them.
• Creating a design doc suggesting my own solution, doing the balance act between both perspectives to satisfy all and explain one side to the other.

The project eventually lands successfully, not because I got better answers or smarter, but because I started to find my own answers.

So, what should I do instead?

I think what should happen is always treat every answer you get as an alternative, or a perspective, or an idea (instead of the truth). Then, combine all these, plus the extra context you know about your own situation, and others' situations, to come up with a unique answer that tightly fit the problem at hand.