Posts

Three tools to help think clearly

Image
Part of our job at a research lab is to clarify an ambiguous area and create a clear path to navigate it. To do this effectively, we need to dedicate significant time to think. I've found Mental Models , or tools for thinking, to be extremely useful during this process. I'd like to share three that I use quite often, in the hopes that others might also find them beneficial. Thought Exercise While there are numerous well-known exercises, the one I've found most useful involves hypothetical scenarios, or "what ifs". The basic idea is that you construct a hypothetical scenario which differs from the current reality. Then, you explore the problem within this alternative reality. Here are a few examples: What if I could discard the current system and rebuild it from scratch? What would I do differently? What if I could, hypothetically speaking, "fire" the entire current team, regain the headcount, and rehire one by one? Who would I want on the new team? What...

Feedback Loop

Image
Over the past few weeks, I've been reading "Thinking in Systems" by Donella Meadows . One of the mental models that I've reflected on is about feedback loops and how it is relevant to our work.  The concept of a feedback loop in systems is fairly simple, as in the attached photo: you do something, measure the outcome, analyze what leads to the outcome, correct the mistakes, then repeat the action. The biggest problem to deal with is system delay: when there's a significant delay between the first action, the first measurement, and the updated action, oscillation happens. We either commit too little action or too much, which both lead to undesirable results. An analogy and a concrete example can help to understand this. Analogy : Imagine you are taking a shower and you want the perfect temperature for the water. But your hot-cold water mixer is quite far away from the showerhead. What's going to happen is that there will be a few seconds' delay after you tu...

Risk vs. Uncertainty

Image
It's the planning season, "Risk" is one of the most discussed topics during this time. But when we say "Risk" we might mean different things. Therefore I took some time to reflect on the two most common confusions that we might have when talking about "Risk", that is Risk vs Uncertainty. I took a lot of inspiration from this note and I'm sharing some of my own thoughts and realization that might be useful. What is risk? Risks are bad things that can negatively impact the outcome, so we don't want them to happen. Risks are certain, therefore usually measurable / quantifiable. Given the nature of its certainty, we can usually mitigate them using tools like insurance, contingency and parallel paths etc. In the context of R&D, dealing with risks ultimately leads to solving a trade-off problem: you put in more effort, spend more money, extend the timeline or compromise the feature set, etc. An intuitive example : You are on the roof of a 20 flo...

The four horsemen in R&D (and how to defeat them)

Image
Recently I've been reading the book The Art of Thinking Clearly . The book examined most of the common faults in reasoning, and I've been reflecting on their correlation and application in our R&D work. Among the list, I picked 4 of the most relevant pitfalls that I have observed over the years, and I gave them a catchy name: The 4 horsemen in R&D (CAOS). Yes, they do cause Chaos! What are they? Confirmation bias : We cherry-pick evidence to support our existing beliefs and ignore the rest. Action bias : We feel compelled to do something, particularly in new or shaky circumstances, even if we have made things worse by acting too quickly or too often. Omission bias : We tend to prefer inaction when inaction leads to guaranteed bad outcome, but action has uncertain outcome. Sunk cost fallacy : We consider the costs incurred to date instead of the future costs in our decision-making. How to spot them? Confirmation bias is the mother of all sins, and the most dire one of th...

Effortless Impact vs. Impactless Effort

Image
I have been thinking about this topic in my notes for a while, but due to various reasons, I never got the time to write it down until today. The thoughts from this note is inspired by the book Effortless by Greg McKeown, the same author that wrote Essentialism . The two books discussed how to identify the most essential things to do, then how to most effectively achieve them. This topic is quite relevant under the context of the more intense environment and that our company will be focusing a lot more on efficiency in the foreseeable future. There isn't a silver-bullet to the question of how to be more efficient, but here are a few points that I had reflected on, and I felt they might be useful to share. Again, I'm partitioning the space into 4 quadrants using the " Teasing apart tool " "Waste of time" This is the quadrant of Low-Effort and Low-Impact, it seems obvious that anyone would avoid doing work in this quadrant. But actually, you'll be surpris...

Strong opinion, weakly held

Image
I enjoy having very interesting, but at the same time, very heated technical discussions with people. These discussions made me reflect on two feedback that I was given throughout my career: Carl, your opinion is too strong, it's not possible to convince you. Carl, you change your mind too quickly, what you are suggesting now contradicts what you were suggesting before. These two feedback are not wrong, they both reflect real scenarios where I was either holding a very strong opinion or I was changing my opinion very rapidly. But they might sound contradicting to each other, since how can a strong-minded person change their ideas all the time. You might have heard about the very catchy phrase: " Strong opinion, weakly held ", this framework of thinking will lead to exactly the phenomenon that people describe me in the above feedback. The idea of the Strong opinion, weakly held framework is very simple: when we are making decisions for new things, we are effectively doing ...

Sufficient vs. Necessary

Image
  When reflecting on all the past successful and failed projects that our team had invested in. I wanted to find some common patterns, some framework for me to reason about the success and the failures, such that I can establish some principles to determine how to invest in a project in the future. Then the very simple concept of necessity vs sufficiency came to my mind. Using plain English, if we have a Goal A, where A can be very concrete things like launching a product or hitting a KPI. It can also be abstract concepts like "enable contextualized AI for all humans". If X is Necessary for Goal A, then A can not be achieved without X. If X is Sufficient for Goal A, then if X is achieved, Goal A is guaranteed to be achieved. If we use them to divide the space into the 4 quadrants (a method that I described in this note ), I can map some of our past work into them. Through this process I have had some very interesting reflections that I thought might be useful to share. Suff...