Carl's Reflections

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...

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...

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...

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...

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...

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 ...

  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...

This reflection comes from reading the book The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt . Towards the end of the book, the author suggested that a manager needs to have the ability to answer three simple questions: What needs to be changed? What do we want to achieve? How do you cause the change? In the context of the book, manager == leader since the story happened in a production plant. In our workplace, a leader can also be individual technical leads that are responsible for leading projects without being a people manager. These 3 questions resonated with me very deeply, especially during the current tough time. I've observed first handedly leaders suffering from pressure from all directions (myself included). Skepticism and criticism like " Why are you working on this? " " Why isn't your team delivering? " " Why don't you take the team to work on X instead? " are the most common things that leaders hear on a daily basi...

This reflection comes from my personal life instead of from work: my wife had a pretty terrible experience with the kid sports club that our son goes to, and she was quite irritated, therefore she decided to write an email to escalate the issue to their management chain. We worked together to revise the email a few times such that structured critical feedback was being provided, and that email was responded to promptly by the club's management team, and our issue addressed. This made me reflect on similar situation at work, when people want to escalate an issue or pitch an idea, quite often due to various reasons (urgency, excitement etc.) people might present the story in a black & white form, and overlook the importance of addressing the matter in a structured, nuanced form. This short note is about the 3 most common frameworks that I use to elaborate (both verbally and in writing) an issue or an opportunity, such that it's easy to digest from the receiving end. The 4 qua...

This reflection came from a discussion with my team about the value of brainstorming. Some think a lot of the time brainstorming can be a waste of time, since within the limited time, the discussion is usually very shallow and the ideas rather trivial. This discussion made me reflect on the subtle differences between "simple ideas" and "trivial ideas". On paper, they both mean an idea that can be explained to people very easily, but to be more specific, trivial ideas refer to shallow ideas , things that seem obvious on the surface, but had not been thought through. They are often generated by over simplification of complex problems. For example, someone is having a high fever and asks for help, without any examination, if someone suggests that "why don't you take some Tylenol?" This is a trivial idea. Trivial ideas are a subset of simple ideas, that means: all trivial ideas are simple ideas, but not all simple ideas are trivial ideas. Some simple ideas...

I had this reflection when I finished the book Effortless: Make It Easier to Do What Matters Most , which brought up a different perspective to the concept of "Sleep on it" that I used to think about. In Adam Grant's book Think Again , he encouraged people to always "be lazy" and sleep on big ideas, since this gives people the mind space to rethink and reflect on the decision. In Effortless , the author's view was related but subtly different: he asked people to think about whether they are spending too much effort either solving the non-essential problem, or trying to solve the essential problem in an unproductive way. At Meta, Moving Fast is one of the key values of our company, so "Sleep on it" sounds a little against that core value. However, what matters in the end is not the action of "moving fast", what really matter is that we are making rapid progress towards the right goal in the future. Under this interpretation, it's not o...

There is a common anti-pattern in communication: trying to answer a question too quickly. The symptom of this anti-pattern should be quite familiar to people: in a review / meeting, someone asked a question, then one or several people jumped on to answer the question immediately. But after a few rounds of "answering", the person who asked the question, or the audience didn't really get a clear answer and might feel more confused. I was having this anti-pattern myself a couple of years ago when leading a project. Back then, since I was running the project, I had the sense of ownership and impulse to answer any and every question regarding to the project immediately with lengthy explanations, otherwise my implicit fear is that I will be seen as incompetent.  My boss back then pointed out to me his observation of my behavior and told me: " Carl, don't react to the question, reflect on it first! ". That was when I started to have consciousness about this anti-pa...

This reflection came from one of the questions that I had to address in our team's Q&A, the question was:" What areas do you wish we could be more effective as a team? " The thought that I had was mostly from my experience running incubation projects (projects that spans from early research proof of concept to a relatively mature and reproducible state): the S-curve in innovation . An S-curve has 3 segments: a slow start followed by a rapid growth, then finally hit plateau. This curve not only applies to the broader macro environment of innovation, but also the micro environment like our team. We should be more aware of this pattern, and apply different operating principles in the 3 different phases on the curve. I'm listing a few DOs and DON'Ts for each phase that I thought was useful to me. THE SLOW START This is the exploration phase of a project, things seem to move slower since there are both known unknown and unknown unknowns. DOs Rapid prototyping and a...