I’ve often observed engineers who are reluctant to ask for help. When they encounter a problem, they try hard to solve the problem themselves. Here I’d like to share some thoughts on why that’s the case, and how to break out of it.

Why we don’t ask for help

When we grew up, our education system taught us to solve problems independently. Majority of our tests require us to solve problems individually and without help (from books / notes / other people). We learned to strive in such an environment, and we pride ourselves for being able to solve problems independently.

Then we enter the workplace, and we carry over the same habit. We want to prove to our teammates, and maybe to ourselves too, “I’m a capable engineer”. So if I run into a problem, I’ll just spend a few more hours trying to solve it.

Another common reason for not asking for help is “my teammates are all busy, and I don’t want to bother them with my trivial issue”.

Why we should ask for help

What’s the worst if I don’t ask for help? “It’s only affecting me because I need to spend more time figuring out the problem”, right?

If it’s only affecting the individual, then it’s probably okay to spend more time on this. However that’s normally not the only issue.

The bigger issue is the team is getting slowed down. For the problem I’m investigating, chances are, others are waiting for it too, and being blocked for not knowing the solution. They might not have said it, but they’ve been quietly waiting for your solution, and if the situation doesn’t improve, that quiet waiting eventually turns into vocal questioning. Now the pressure becomes high, and I feel my competency being judged, and I further want to solve the problem by myself.

This is a bad spiral.

When we should ask for help

The criteria are: Are we blocking others? Are we slowing down the team? If not, will it become that way in the near future?

If the answer is yes, then be mindful to set a time limit for how long I’ll individually solve the problem. Beyond that, it’s time to ask for help.

The key balance here is how much individual effort is made before asking for help.

• We don’t want to ask too early before we make an individual effort first.

• We don’t want to ask too late either. Do it before it becomes an issue that blocks the team.

Sometimes we might even realize we are not the best person to tackle the problem, and there is someone else who we should ask to take over. Ultimately, remember the tradeoff between individual excellence and team excellence.

This weekend, I was home all by myself, since my wife took our daughter to Vancouver for the Taylor Swift Eras Tour concert. While looking in the fridge for something to feed myself, I saw some smoked salmon from Costco, which reminded me of the following article I published in 2023 within Meta.

There is a famous book called “Predictably Irrational” that describes human behaviors. In short, we are irrational, and our irrationality follows patterns and is predictable. Thus the title.

I recommend anyone working on consumer products to read the book. It helps understand users and identify what products resonate with users.

Smoked Salmon Example

What I want to share today is one direct example of how we behave this way, even if we are aware of this.

• Before COVID, FB cafes served smoked salmon in breakfast every Friday. I always went for them.

• After COVID, when I first went back to office in 2022, I noticed smoked salmon was gone from Friday breakfast. Oh well, sort of understandable, given back-to-office was still a test and very few people were actually in office.

• A few months later, when more people were back in office, and when cafes began to serve more regularly, I checked again, still no smoked salmon. Somewhat disappointed, but still felt understandable since Meta post COVID was not the same as FB before COVID. Gradually I stopped thinking about smoked salmon.

• A few months later, one Friday morning, I saw someone else's plate with smoked salmon. I immediately asked, "where did you get the smoked salmon?" and he pointed me to the condiment rows next to the sandwich station. I grabbed a few and was so happy!

  • I was immediately aware how irrational I was. It's not like I couldn't afford smoked salmon myself; it's also not like I didn't have smoked salmon at home. But for whatever reason, I was very excited to see smoked salmon offered at Meta cafe on Friday breakfast!

  • I laughed at myself while grabbing the smoked salmon.

  • I told my family that night, and laughed at myself again.

• Next Fri, and the next Fri again, I went to office with better mood and went to look for smoked salmon. It was not offered again.

  • It was very clear how that disappointed me, even though I fully knew I shouldn't expect this to be a recurring thing.

  • I noted myself again as being Predictably Irrational.

  • I again told my family that.

  • My wife started to put smoked salmon in the fridge on the eyeball-level shelf.

• This morning, I saw the smoked salmon in fridge, laughed, and grabbed a few.

  • I told myself, “okay, stop being Predictably Irrational on smoked salmon; instead write about Predictably Irrational”.

More Examples

Here are a short list of Predictably Irrational behaviors we are familiar with:

• Procrastinate

  • When we procrastinate something, it keeps occupying our mindshare until it’s eventually done. In other words, if the task takes the same amount of time to complete, it’s much more rational to finish it early so that it doesn’t occupy our mindshare.

  • Knowing that, most of us still procrastinate, under the (likely false) notion that if I do it last minute, I’ll do it more efficiently.

• Prioritize urgent tasks over important tasks

  • It’s a well-known issue that while we know we should prioritize important tasks over urgent but unimportant tasks, but our behavior is predictably to handle urgent tasks first.

• Chase instant small gratification over challenging but bigger gratification

  • This is the natural extension of the last point. When we have 2 tasks where A takes 5 min with small gratification, and B takes one week with much bigger gratification, we handle A first.

• Focus on what we don't have instead of leveraging what we already have

  • We don’t appreciate enough what we already have. Instead, we ignore them, but focus on what we don’t have yet.

  • One such example is instead of a product spending resources in better serving its existing 1M user base, it spends most focus in acquiring the next 1K users.

• Repeat a failed approach, just with more force

  • When our approach to solve a problem fails, it’s rational to consider alternative approaches.

  • But we often repeat the same approach, just with more effort, expecting to get a different outcome.

Last week I talked about how leaders handle mistakes by their team. This time I’ll continue on this topic, but with a slight difference, which is how to handle mistakes by their peers.

All the things in the last article still apply here: help the mistake maker, and take the opportunity to improve the system. But there are significant differences which are worth a dedicated deep dive.

Mentality - Sense of Responsibility

This is the biggest difference between how most people treat mistakes made by their own team and mistakes made by their peers: the leader feels a different sense of responsibility.

When my team makes a mistake, I might be upset that the mistake was made, but I definitely also feel the responsibility that any mistake made by my team is my mistake too. If others question the mistake or the person who made the mistake, a good leader will step up, protect the team, and own up the mistake.

A similar analogy is in the sports world. Whenever a team player makes a mistake and costs their team a game, we almost never see the coach publicly blame the player. Instead, the coach will own up the mistake as their own mistake in public, even though inside the locker room, there might be stern messages from the coach to the player.

Good leaders don’t throw their team “in front of a bus”.

This mentality or sense of responsibility is drastically different when the mistake is made by a peer. For most people, the instinct is “that’s not my responsibility”.

Coming from this “not my responsibility” mentality, actions can be:

• When others are asking, point to the peer who made the mistake, and say “go talk to <them>”.

• Or be silent and don’t say anything.

Both of these are bad behaviors; which is worse is case by case. Normally pointing out who made the mistake is worse, but there are also cases where silence is actually worse.

Empathy and Shared Responsibility

Good leaders take shared responsibility for such mistakes.

In fact, this is not different from how good leaders treat mistakes by their own team. It’s a shared responsibility in both situations. It’s just that most people instinctively feel the shared responsibility for mistakes made by their team, but need extra mental power to feel the shared responsibility for mistakes made by their peers.

What extra mental power is needed? Empathy.

I’ll share a personal story about how I learned about this the hard way.

I used to be part of this peer group where one specific person (I’ll refer to him as “Bob” here) who’s always slightly out of sync with the rest of us. We would have a scheduled meeting to discuss a predetermined topic, and during the meeting, Bob would make out-of-context comments. Everyone was frustrated: Bob felt not being heard, and the rest of us felt we were slowed down by Bob.

Eventually I decided to own up the shared responsibility and talk to Bob in 1:1. Despite my effort trying to understand Bob, it didn’t go well, and eventually I told Bob “you are slowing down everyone, and I’m trying to help here; if you don’t think I’m helping, I’ll stop here, and we can leave it at that”.

Our relationship became polite from there. We were in good terms on personal front, just not on the project front. Rest of the peer group together ignored Bob for the most part and continued to push forward. This lasted for another year. In my mind, I did a great job of managing the tough situation: the “low performer” in the peer group was no longer affecting the rest of the peer group.

Then my perspective changed completely one day.

Post COVID, Bob for the first time took a business trip to Bay Area, and we had lunch together. During lunch, he needed to figure out where to meet his next peer, and he pulled out his phone. He pulled the phone no more than 3 inches away from his left eye, and said “I can’t find it”. I offered to help, and he gave me his phone. I was surprised the font size on his phone was huge, and the room info was right in the center of the screen. I read it to him, and since he’s not familiar with the building, I also offered to take him to the conference room.

On the way walking there, I asked “I noticed the font on your phone was very big, and you were looking at your phone very close to your eyes, but still couldn’t find the room info?” Bob said, “yes, I’m completely blind on my right eye, and nearly blind on my left”. I was so shocked, and asked “I had no idea! Did anyone else know?” Bob said, “no, other than my manager and HR, I never told anyone in this company. Please keep it to yourself, and don’t share it with the rest of the team”.

Later we had a closer conversation about the situation. It turned out Bob grew up with this situation, and learned not to make it an excuse. He’s managed to handle this in his entire life. Everywhere he went, it’s very obvious to see, so it became well-known very quickly. He spent extra hours reading context before meetings, and had a close friend sitting right next to him during meetings. Every time Bob is making off-the-topic comments and getting weird looks from other meeting attendees, his close friend would kick him under the table and then Bob would stop talking.

But joining a new company during COVID made it much harder. He didn’t want to share with anyone else he works with, because that might be perceived as finding excuses. With everything being remote and in front of computers, for years no one knew, and no one was serving as his social cue buddy.

Bob still preferred not to tell others, so he and I developed a “kick under the table” protocol. During meetings, he’d always keep his chat with me on screen, and every time he started to make out-of-context comments, I’d message him “your comment is off topic”, and then he’d stop. He and I would also have a 15-min daily call, where I’d give him the latest context verbally.

As I was doing this to help Bob, I also started to realize once Bob had the right context, he offered tremendous wisdom on his domain expertise. Previously his being out of context, and our stopping listening made him sidelined. Once I started filling him in on context and listening to his suggestions, it completely changed my view on his contribution. I started seeking his input during our daily calls.

I did keep my promise to Bob not to tell anyone in the team. This was kept between him and me; eventually Bob decided to leave the company. In fact I haven’t told anyone until today I’m writing this article. (I did receive permission from Bob to publish this article.)

The reason I’m sharing this today is not trying to brag “see how I helped my peer Bob”. Instead, it’s a reminder for myself: “see how I was completely blind to my colleague’s situation?” I thought my colleague Bob was making a mistake, instead it was me making a mistake not to understand what led to Bob behaving that way.

Empathy to understand “what led to this person making this mistake” could change the perspective whether this is even a mistake in the first place.

I talked about how great leaders do during either war time or peace time before. The next topic is orthogonal to this dimension, and it deals with mistakes.

Everyone makes mistakes. That’s just human nature. How to handle mistakes though shows a lot about a person’s character.

For a leader, there are 4 types of mistake handling:

• Their team made a mistake

• They themselves made a mistake

• Their peers made a mistake

• Their leadership made a mistake

Today, I’ll focus on the first situation: when their team made a mistake.

Worst leaders: Don’t care

This might be a surprise, but I definitely consider those don’t-care leaders as the worst. These leaders don’t say anything, and treat it as if nothing has happened. They might be doing so with the intention of “showing empathy, and providing a safe environment for making mistakes”, but the reality is this type of leaders create an untrustworthy environment, because people can get away with whatever they do. One bad apple in such an environment will destroy all the good apples, and good people will leave.

Bad leaders: Act punitively

These leaders will take notice, and will call out the situation and take action to make sure it doesn’t happen again. This is good.

But they do so by punishing the team member who made the mistake.

There are many forms of “punishment”.

• Most obvious is the action of yelling at the person who made the mistake in front of everyone else, or physical violence (even if it’s not towards the person, like throwing something at the wall).

• Bad performance rating or rejection of promotion is also a clear form of punishment.

• Other subtle forms of punishment exist too, and some of them might even be unintended. For example, no longer giving the person challenging tasks could be perceived as punishment too.

The intricacy of what's considered as punishment is it’s purely determined from the viewpoint of the recipient of the treatment.

You might ask, why is this bad? Isn’t it justifiable if someone made a mistake, they pay for the consequences?

The problem is this can create an environment where people are afraid. Psychological safety is a critical component for high performing teams. Leaders acting punitively puts hugh risk on psychological safety.

Good leaders: Help the mistake maker

A good leader cares about their team, and when their team makes a mistake, they offer help. They call out the mistake so that everyone is aware, but they show empathy to the person who made the mistake. They help the person to stand up and grow from the mistake.

Note that this could mean that the person who made the mistake still needs to face the consequences, but the consequences must be perceived as fair from the person and the team. This is the key to preserve the psychological safety, so that the team is not afraid of taking any risks in the future.

Good leaders bring an environment where it’s recognized that everyone makes mistakes, and while we try to avoid them, we understand mistakes are inevitable to happen, and will be handled with fairness and dignity.

Best leaders: Treat mistakes as opportunities to improve the system

The best leaders take one step even further. They anticipate mistakes, and treat them as opportunities.

They recognize the occurrence of mistakes is foremost due to systems being not good enough to prevent such mistakes, and while such imperfection exists, anyone could be tripped up and make such mistakes. Therefore the best leaders take mistakes as opportunities to discover how to strengthen the system. They de-focus on the people who ran into the problem, but primarily focus on the problem itself.

These leaders create an environment where people are encouraged to consistently improve the system, with psychological safety. It’s a joy to be in such an environment.

Since the publication of State of Copilot 2 months ago, we’ve had more interactions with copilot, and this gave me some new insights.

2 recent events

Let me first describe 2 events that happened in the past 2 weeks.

Server deployment failure

One day one of the team members discovered that our Python Strawberry GraphQL server deployment has been failing. We looked into the deployment log, and determined that it’s due to a deployment script change we made requires Docker BuildKit to be enabled, but the cloud deployment machine by default doesn’t have this.

It took me 5 attempts to fix this.

• First, I used Gemini suggestions, directly from the GCP logs. GCP server, GCP log, GCP Gemini suggestion. This must work, right? Nope, the Gemini suggested fix didn’t work.

• Then I used Cursor small model suggested fix. Nope, that didn’t work.

• Then I used OpenAI suggested fix. Nope, that didn’t work.

• Then I used Anthropic Claude suggested fix. Nope, that didn’t work.

• Finally, I went to read Google Cloud Build YAML documentation, and made the change. That worked.

AI : Human = 4 failures : 1 success.

What’s more interesting is, the 4 AI suggestions were all different, and they were equally invalid.

Mobile app crash

The following week, we encountered a mobile app crash. After debugging, we nailed it down to this line in our React Native code:

import { Easing } from "react-native/Libraries/Animated/Easing";

This import is incorrect, and makes Easing as undefined at run time, which crashes our app when being accessed.

The correct way should be

import { Easing } from "react-native";

How was the bogus import line added in the first place? AI suggested auto-completion.

Insights / Hypothesis

These 2 events (along with many other past observations) gave me the following hypothesis:

• GenAI’s code completion intelligence mostly comes from pattern matching from existing available code.

What’s “existing available code”? 2 parts: public open source code base trained in foundation models, and private code through RAG.

What works great? Repetitive patterns in these 2 corpora.

• Repetitive patterns in public open source code base include application code using widely adopted open source packages.

• Repetitive patterns in private code include the same logic used in multiple places, and test code.

What tends to not work well? 

• DevOps code in general is much lower volume than business logic eng code, thus less likely to work well for LLM suggestions. (My worst personal experiences were all copilot suggestions in the DevOps realm.)

• Application code using less popular open source packages.

• Rare logic which you only use in one place.

In the end, it makes sense to double check the auto-suggested code to make sure it does what you want, and doesn’t bring errors, or worse, unintended irreversible outcomes, like my last time where the server was deleted altogether and couldn’t be recovered.

The key takeaway is, even if GenAI suggests code that works, it still doesn’t know why it works, yet. At the moment, to understand “why” is still human intelligence.

For the majority of my professional life, work communication has always been a combination of email + chat. (Another long list of tools also exist, like video calls, docs, designs, project management, etc; but they are at least one order of magnitude less frequent than text based communication tools like email and chat, so won’t be a focus of this article.)

Email + Chat

My first job was in Microsoft in 2003, and the email service was provided by Microsoft Outlook. My team was in the MSN org, and therefore our primary chat tool was MSN Messenger. Now thinking back, I realize we didn’t differentiate between work and personal chats back then. They were all mixed together.

Then I joined Google in 2006. Email was Gmail, which was and still is superior to Microsoft Outlook. The chat tool went through so many different generations, and I lost count of their names too. (There is a running joke in the industry that Google just keeps trying and failing at making chat tools, but I digress.)

10 years later, I left Google and entered the startup world. Gmail + Slack was and continues to be the dominant combination.

After I sold my startup to Facebook/Meta, I re-entered the big tech corp, and here the combination is Microsoft Outlook for email and Meta Workplace for chat. Both of these deserve more explanations.

• When Facebook first started, it used Gmail for email just like the majority of startup companies. Then Google announced the plan to develop Google+ in 2010/2011-ish, and Facebook was so upset that it switched from Gmail to Microsoft Outlook.

• Meta Workplace Chat is actually a very decent product. It just suffered a significant lack of attention from company leadership for a long time, and the plug was eventually pulled earlier this year to shut down externally, and only keep it for internal use.

Now I’m back in the startup world, I’m back in the Gmail + Slack combination, which is, no surprise, my preferred combination.

Email vs. Chat

All the history above is only the teaser. The real discussion point today is the difference between email and chat. Both are text-heavy communication tools, and both are important, but there are some interesting differences.

Different companies have different focuses

Google is an email-first company. Employees spend a huge portion of their time reading / writing emails. Chat is secondary to email.

• Mailing lists are critical in such environments, since discussions happen over emails. So each team needs at least one mailing list so that they can have discussions (more often than not, they will have multiple mailing lists, each for slightly different purposes.) I remember Google once announced “there are more mailing lists than employees”.

• One funny outcome of this mailing list frenzy is the situation when a person gets subscribed to a mailing list, and doesn’t care about the topic, but couldn’t figure out how to unsubscribe, since it’s very likely it’s a mailing list A that the person actually cares about gets subscribed to a mailing list B the person doesn’t care about, but the person also can’t just unsubscribe the entire mailing list A from mailing list B. What happens often is the person who’s so upset about being spammed will reply all and say “unsubscribe me”, while spamming everyone on mailing list B. And that normally triggers a huge flood of reply-alls for more “unsubscribe me too”. (But no one actually is being unsubscribed by doing so. Irony.)

Meta is a chat-first company. Employees spend a huge portion of their time reading / writing chats. Email is far secondary to chat.

• Let me explain more. It is a legit excuse for a Meta employee to say “I don’t read emails” if you ask them “what’s your opinion about the question I asked in my email last week?”.

• At Meta, if something is important, the announcement is in a Workplace post, and then people repeat it in various group chats.

Google and Meta might be extremes. Most companies I’ve seen have a healthy balance between emails and chats.

Email and chat are suited for different needs

Chat is for timely discussions, which is indeed the majority of work communication. A bursty round of back-n-forth in a few minutes can clarify a lot of things, and unblock people from moving forward. This is why chat is super important.

But chat is not a good tool for lengthy articulation of complex thoughts. Many people probably have seen the “<the other person> is typing…” message in most of the chat tools. If that message stays there for longer than a few seconds, you start to wonder what the other person is trying to type, and anxiety shoots up - “I don’t know what it is, but this can’t be good”.

For the person who’s typing the long message in chat, it also wasn’t a good experience. While thought is developing, you might figure out a better way of organizing the thoughts, and need to adjust some of the early points typed up earlier. But it’s hard to do that in chat UI.

After you type up a long message in chat, make it perfect and send it out, suddenly you experience silence from everyone else in the chat group. That’s because it’s a long message and it has complex thought, and each person needs to take time to read and to think. Now it’s the message sender’s turn to have anxiety. “What do people think about this idea? Why am I not getting any responses?”

Email (or doc) is much better suited for such lengthy articulation of complex thoughts. Take time to draft it, adjust how to present it, polish it. Afterwards leverage chats for quick discussions and clarifications of the email (or doc) content. That’s the best combination.

Access control

Email and chat also have different access control implications.

Emails can be easily forwarded. That’s a double-edged sword. On the positive side, easily forwarding an email relieves the reader from the risk of accidentally misrepresenting the author when paraphrasing. On the negative side, confidentiality is nearly impossible to achieve in emails.

Chat provides a slightly higher level of confidentiality, since it needs copy-n-paste or screenshot to share beyond the original audience, and it has more friction. On the down side, chat tends to raise a lot more “he says, she says” type of communication challenges.

Authenticity

Another key observation I want to point out here is email and chat provide different levels of authenticity in communication.

Emails tend to be more formal and more polished; chats tend to be more informal, and in fact quite common to be completely lowercase, without proper spelling and punctuation.

This allows people to both act and be perceived as more authentic over chat, and this is a huge factor in building trust relationships in the work environment.

Generational shift

One last point, I’ve noticed that younger generations tend not to have the habit of reading emails. It will be interesting to see how this changes the work culture going forward.

Flow State, according to wikipedia, is defined as the mental state in which a person performing some activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. It is considered the ideal positive psychological state.

Recently I found myself being in this state regularly, and it brought me a lot of peace and joy. This made me think, what are the factors that led me to this flow state?

Reason #1: Time is spent on things I enjoy

This is the surface level reason. Lately I’m spending a lot of time coding the MVP of our startup product, and every day I implement some new features, fix some bugs, or make things more sustainable. Day by day, I can first hand observe how things are improving and coming together. Progress being visible is an amazing state to be in.

But this reason alone doesn’t fully explain my flow state. In the past I’ve also worked on things I enjoy, but I haven’t felt this flow state so frequently. So what’s different this time?

Reason #2: I have uninterrupted time

Then I realized another key difference this time. I have uninterrupted time. Each day, I can spend several hours without interruption in coding. This is a luxury I haven’t had in years.

In my last few big tech jobs, my days were broken into 30-min slots, and I was just running from meeting to meeting. Each 30-min went like: context switch in, discussions, then context switch out. This pattern repeated from arrival in office to leaving for home. This is common for many people; that’s part of the job responsibility for anyone with leadership roles.

This is why many companies implement no-meeting-day or no-meeting-week. However, a running joke was, even though we call it “no meeting day”, in reality it became “other meetings day”. This is because all regular-cadence-meetings were canceled on a “no meeting day”, then it’s easier to schedule other one-off meetings on such days. Very quickly, calendar gets filled on “no meeting days”, and uninterrupted time is still non-existent.

Okay, I can explain why I didn’t have uninterrupted time at big tech, but it’s still interesting that in my last startup Leap.ai, even though I had uninterrupted time, I didn’t experience flow state this much.

So what’s unique this time?

Reason #3: I have rhythm

Then I realized another thing I have now but not before. My daily schedule now is extremely predictable.

At the moment, here’s my typical day:

• Morning

  • Get up and walk dog

  • Get daughter ready for school, drop her off, and then drive to the co-work space

  • Get a cup of coffee and some snacks, and quickly think through what I need to do for the day

  • Have 15-min 1:1s with every engineer

  • Sync with my co-founder on any company related topics (could be product, marketing, funding, hiring, etc). On Tue / Thu, this sync happens during our gym workout session.

• Have lunch, and drive home afterwards

• Afternoon

  • Coding session #1

  • Daily eng team sync

  • Pick up daughter from school

  • Coding session #2

  • Walk dog

• Dinner & evening, family time

  • Sometimes need to do coding work if unfinished during the day

It’s this rhythm that truly enables me to enter flow state often. It provides higher efficiency for the uninterrupted time.

I’m pretty certain once MVP is built, and we enter the public launch stage, this rhythm will be broken. I just remind myself that I need to make extra effort to create a new rhythm which fits that new stage.

My conclusion: Rhythm amplifies uninterrupted time, which gets spent on things I enjoy, and this is why I have a higher chance of entering flow state.

Hope everyone can establish their rhythm.

Last time we talked about when shit happens, good leaders roll up their sleeves and be ready to jump in to help. Today I’ll talk about one aspect for good leaders at peace time.

What’s peace time? This is when things are humming along, no time crunch, no looming disasters. In the ideal situation, teams should operate in this mode for the majority of the time. Sadly there’s not enough ideal situations in the tech industry, so in reality this is probably a minority. But still, they do exist.

What do great leaders do in such a time?

The typical wisdom is to delegate. The great leaders must have some solid lieutenants that they rely on, and peace time is when the great leaders delegate to the solid lieutenants to drive.

I agree with this, but I’d push for one further step. Great leaders don’t just delegate; they follow the delegate.

What’s the subtle but critical difference between a) “to delegate” and b) “to follow the delegate”?

For someone to be a great leader, they know when to lead, and when not to lead. When they are not leading, they are great followers too. It’s normal for anyone to follow their manager (or other org leaders above them), it’s also common for anyone to follow their peer (or a leader in another sibling org), but it’s exceptional to follow someone’s reports (or other people under their direct command).

For a leader to follow their delegate, it implies this leader demonstrates humble servant style leadership.

• To show the contrast, a dictator can delegate, but never follow their delegate; a dictator always illustrates their power in front of their delegates. A dictator’s delegate tends to guess what the dictator wants, and acts on behalf of the dictator. A dictator’s org is more likely to be a stifling environment.

• A great leader does not hold such dictating ego; they truly empowers the delegate, by following the delegate’s leadership. A great leader’s delegate can come up with innovative approaches by themselves, and such surprises are welcomed by the great leader. A humble servant leader’s org is more likely to be a prospecting environment.

Is your manager a dictator leader, or a humble servant leader?

P.S., It’s worth calling out that peace time can turn into war time any moment, and the great leader’s mode of operation can change immediately when that happens.

Shit happens. What do you do when it does?

For a long time in my career, I have been fascinated by the topic of what makes someone a good leader. By no means there’s a single definition. In fact, it’s very situational, and no matter what the attribute we identify, it’s guaranteed that we can find counterexamples where some leader did the exact opposite and was also successful. However I did develop a series of observations on what best leaders tend to behave, and will gradually cover these.

Today is the first topic I want to cover, which involves what a leader does when shit happens.

Early in my career at Microsoft / Google, I first hand observed how top leaders jumped in whenever outages happened. I clearly remembered one Sunday at 3am, on the live call debugging a server outage, I heard the eng VP suggesting the team to check on some dependency to verify whether that’s also broken. In fact, he’s been listening on the call for a while, without saying much. But when he noticed the team missed some information, he voiced it on the call, and indeed that was the root cause. Once we mitigated the root cause, and resolved the outage, he said “good night everyone; take good rest and we’ll follow up Monday morning” before we ended the call.

I’ve also observed eng leaders who never joined live debugging discussions, since in their minds, they trusted wholeheartedly that their delegates were capable of handling the emergencies.

I debated in my head which approach would be better. In the end, my personal preference is towards leaders who roll up their sleeves when things are tough.

It’s not that these roll-up-sleeves leaders don’t trust their delegates. They do, but they are still ready to hands-on lead when it’s needed.

Going back to the above example I gave. The moment I heard the VP’s voice suggesting we check on the specific dependency, I immediately felt a sense of relief and certainty. I knew everyone on the call got a morale boost right then; I knew we’d have any resources needed to tackle the problem quickly. The team got stronger because the VP was there. The following Monday, when we were chatting about the issue, everyone commented how much they respected the VP being there.

One thing to note though, the VP didn’t start to call the shots from the moment he joined the call. I’ve seen those leaders too, who are eager to join live debugging but will take over shotcalling the moment they get involved. I personally don’t think this is the best approach, since it tips too much towards top-down culture.

When shit happens, good leaders roll up their sleeves, pick up a shovel, stand by to observe the situation and how the team handles the situation, and jump in to serve or lead the moment it becomes necessary.

From 2006 to 2012, I worked as the eng lead in Google Ads Trust & Safety area, and had many PM partners. Most of them didn't stay for too long and were constantly rotating in and out. Except the last one. He stayed for years, and we had a great collaborating relationship.

I learned 2 things from him.

1. The understanding of what's a partner.

2. The phrase "Strong Opinions, Loosely Held", and why that's a good thing.

True Partnership

For the first several years of my role, I was very frustrated about the lack of stability of PM support. There were a lot of PM changes: a new PM joined the team, we spent time training the new PM up, then the new PM left, and we were given another new PM. This went on for a few years.

I asked the PM leadership why this was happening, and was told it'd be very hard to find a PM who'd be interested in this role, and even harder for some PM to remain interested in this role. I got the following advice: maybe I should become that anchor, just expecting frequent PM shuffles. I took that advice to heart, and started acting as the PM for the team.

Interestingly, this made the situation worse. New PMs rotated even faster, since they didn't see their path to success while their eng counterpart just acted as PM. I didn't realize this though. I was simply trying my best to be the acting PM, ignoring my rotating PM partnership, and using that PM rotation as further evidence that me being the acting PM was the right decision.

Until this new PM partner arrived.

Right from the beginning, he said to me, "I'm not your PM". (In fact he still said that to me years later.) He did things that I wasn't even aware that I needed to do. He was able to bring alignment at sales leadership level which changed the landscape of the project significantly. He was able to inject himself into conversation and foster relationship so that our views were properly represented when tough tradeoffs were needed.

He refused to acknowledge he was my PM, but yet he was able to deliver the most impactful PM contribution for me and my team. He taught me, without saying it directly, that the right partnership is to recognize each other's unique strengths, and let each person handle what they are naturally better to handle. The fact that I was treating the previous PMs as I had to teach them what to do was limiting to them and therefore in turn limiting to my team and myself.

Strong Opinions, Loosely Held

During one of the "I'm not your PM" conversations, he told me, "Before I took this role, people warned me that you are hard to work with. What I observed though is 4 words, Strong Opinions, Loosely Held. From the quick outside look, that Loosely Held part wasn't obvious, which is why you have this reputation of being hard to work with. But getting to know you more and debate with you, I actually find it really enjoyable."

That conversation struck me, and it stayed with me for 10+ years now.

• Before that, I didn't even know that I was this type. Even myself thought I was "Strong Opinions".

• Even though I actually was “Loosely Held”, I wasn’t self-aware of it, and I definitely didn’t make any effort to show to others that I’m “Loosely Held”. When my opinion changed, I changed it silently.

• From that day on, I intentionally showed more of my "Loosely Held" part. I called out when I changed my opinion based on others’ input / feedback / opinions, and I also explained with more details when my opinion wasn’t changed.

• This significantly helped me to become more likable and more trusted.

I also tested others with "Strong Opinions" to see whether they "Loosely Held". I found out that:

• "Strong Opinions, Tightly Held" are the hardest people to work with.

• "Strong Opinions, Loosely Held" are the best people to work with.

Why is "Strong Opinions, Loosely Held" the best to work with?

• They have opinions, and they are willing to share and argue. You can pick the best of their ideas.

• They also are willing to listen to pushbacks, and consider alternatives. This leads to effective brainstorming, towards a collaborative better end result.

• The best relationship is formed when both parties feel the other person makes me better.

My suggestions

• If you don't have strong opinions, please push yourself to form strong opinions. It’s important to learn how to articulate your rationale behind your opinions.

• If you do have strong opinions, please be mindful to be loosely held. Allow yourself to be convinced by others, and even better, proactively seek opposite views. Take the right pieces from different people, and combine them into the best joint ideas.

• If you have strong opinions, and they are loosely held, be mindful to show others when you change your opinions. No one else can read your mind. If you don’t tell others when you change your opinion, it’s not easy for others to tell, and that hurts your reputation.

• If you have strong opinions and they are loosely held, identify others in a similar mindset. They are your best potential partners, and together you can go far.

P.S., That PM who helped me realize all these? He’s now my cofounder of Gaida, and Gene happily acknowledges he’s my PM now. :)

Last week I talked about “do you know what you truly want”, and a natural progression of this topic is “do you know what you truly are good at”.

You might think, well this is easier to figure out. But it’s actually more nuanced than what it seems at first glance.

Level 1: basic understanding

When I ask a junior engineer what they are good at, the answers I normally get are like:

• I’m good at solving problems

• I’m good at debugging issues

• I’m good at delivering solutions

These are a solid foundation to build upon.

I was like that in the first few years of my career.

Level 2: surprise understanding

A few years later, someone once said to me: “you are good at teaching others”, and I was completely shocked and asked back “what do you mean?”

A little about me: when I was a kid, I really didn’t like to explain homework problems to other students. Subconsciously I was thinking “how can you not know this already?” and I don’t think my facial expression was hiding it either. As time went by, I knew myself as “I don’t like teaching others”.

In fact, the first time I heard of “you are good at teaching others” was from my PhD advisor during my grad school years, but I dismissed it right away, and never thought more about it.

It was the 2nd time hearing it, in the work environment, that made me take notice.

Level 3: intentional understanding

Each surprise understanding is a great self-diagnosis opportunity. I took on this “you are good at teaching others” opportunity and did some self-diagnosis.

What is the contrast between me helping classmates on homework and me helping teammates on work tasks? Clearly I treated them differently and got different results.

I listed down the differences I could think of, and quickly ruled out most of them. The standing out item was: My attitude.

• Helping classmates on homework was perceived as a burden for me.

• Helping team members on work tasks was perceived as part of my responsibility.

Apparently in a work environment where I was TL, I needed to delegate certain tasks to other team members. To aim for better results, I would spend extra time thinking about what would be the best illustrating examples to show others. What I didn’t know was, that unintentional action of figuring out the best illustrating examples had great outcome, and thus gained my reputation of “you are good at teaching others”.

In other words, that attitude difference changed everything. I was more patient in helping team members, I spent more time observing where they were stuck, and thinking what’s the best way to help them, etc. Once I put in the thought, people were happily learning from me, and I also felt my own deep joy when others learned new skills.

At this point, my self-understanding has changed from “I don’t like teaching others” to “If I want to, I can be good at teaching others, and I enjoy it too”.

Then the journey begins for me to think “where else I can apply this ‘if I want to’ aspect?” That became wide eye-opening.

Level 4: true understanding

Now let me share my definition of “what you are truly good at”. This phrase, in my definition, refers to things that without intentional effort, you are doing it better than average, with outside 1-sigma deviation.

The key phrases are “without intentional effort” and “outside 1-sigma deviation”.

Outside 1-sigma deviation.

We all know everything is a Normal distribution, and every Normal distribution is a bell curve. When it comes to people, pick any dimension, we can draw a Normal distribution. “Coding ability” distribution? That’s a Normal bell curve. “Doc writing ability” distribution? That’s a Normal bell curve.

Self-assess yourself in the bell curve. For most things, you are in the middle (by definition a Normal distribution has the middle 70% within 1-sigma). For some things, you’d be outside of the left 1-sigma (meaning you are worse than average); it’s okay, everyone has these; we just avoid them and life is all good.

For some things, you’d be outside of the right 1-sigma (meaning you are top 15%). This is where you should focus.

Without intentional effort

For all the things you are outside of the right 1-sigma, assess your effort level. Are you working very hard to maintain that top-15% level, or this top-15% level comes at ease?

Top-15% without intentional effort -> these are your true strengths. You are born much better than others on this. This is God’s gift to you.

In the example I gave earlier, in the work environment, I wasn’t putting intentional effort to get better at teaching others. The moment my attitude was “this is my responsibility”, I was naturally good at teaching others.

Natural talent + effort == non-stoppable

By following this process (which starts from others’ genuine surprise praise to you), if you’ve identified an area where you are outside of right 1-sigma deviation without intentional effort, congratulations! You’ve identified one of your natural talents.

Now start to put effort to this. You’ll soon find yourself outside of 2-sigma in this dimension (top 5%) and then 3-sigma (top 1%).

Natural talent + effort == non-stoppable.

What if I can’t find any “outside 1-sigma deviation without intentional effort”?

This is a common question I hear.

The answer is simple, to combine multiple dimensions together. If on dimension A, you are at top 40%, and on dimension B, you are at top 40%. Chances are at dimension A&B, you are at top 15%.

Illustrating example: say one engineer is slightly above average for infra development, at top 40%. Say this engineer is also slightly above average for mobile app development, at top 40%. Now for a product that needs both strong infra and mobile app development, this engineer likely is a top 15% candidate.

It’s my strong belief that everyone can find their “outside 1-sigma deviation without intentional effort” areas. The challenge is to find such areas that matter. (But hey, be open-minded. Even if I put “software engineer” and “sweeping floors” dimensions together, I could become a top-1% talent at iRobot.)

Enjoy this individualized journey to identify what you truly are good at!

In Founding Engineers, Part I, I mentioned that “I don’t know what I want yet” would be a great future topic. This week, I had a few conversations that made this a top of mind, so it’s a perfect time to get to it.

Let me first reveal the high level summary:

• I believe it’s important for everyone to figure out what truly matters to them, and this comes from internally self diagnosing emotions and rationales, and externally understanding different culture systems.

• This is not an easy task, and likely will take years to get there. But once that has been figured out, happiness will jump tremendously.

How did I come to these? Let me first go through my own career journey to illustrate the challenge and the progression.

Stage 1, I had no idea what I wanted

When I was a kid, my STEM grades were great, and that was the only thing I knew. I got accepted by Tsinghua University, but I had no idea what majors to pursue - in fact, I didn’t even know what each major meant. My parents picked the choices for me, and fate determined that I got enrolled into the Department of Automation.

Graduating from Tsinghua, the only thing I knew was I’d apply to US grad school. I had no idea how grad schools in the US work. Through fate again, I got to Drexel University studying for a PhD in Computer Networks (which I didn’t actually apply to).

Stage 2, I thought I knew what I wanted, but I was wrong and it’s obvious to detect

During my PhD, I enjoyed the journey of doing theoretical research and publishing papers. I thought that’s what I wanted to do for the rest of my life. When graduating, I only had eyes on faculty positions, and applied to all open academic positions.

But the economy wasn’t good that year, and I didn’t get any academic interviews. The only interview I got through that entire year was from Microsoft, and I received an entry level software engineer offer. I accepted it only because I had no other choice. In my mind, this was purely a temporary solution; I’d be back in academia in no time.

I worked on payments. We were building the payment solution behind MSN, Xbox, Bing, etc. I was so surprised by how much I enjoyed building real user facing products.

I thought I wanted to do research, but I was wrong, and it only took me a few months of product development to detect this.

Stage 3, I thought I knew what I wanted, but I was wrong and it’s not clear that I was wrong

Now that I knew I wanted to build real products, I poured my heart and soul into it.

I was quickly rewarded by good performance ratings, fast promotions, larger scope, etc. Every time I got an excellent performance rating, or a promotion, or a larger scope, I was so happy. Every time I got a normal performance rating, or promotion being delayed, or someone else got a larger scope, I was so upset.

Clearly “good performance / promotion / larger scope” was what I wanted. I had my own genuine emotional reactions as evidence. And I could observe everyone else around me was also behaving the same way.

Unfortunately I was wrong about what I truly wanted, and what’s worse, I couldn’t detect that for years.

The problem was, the entire system around me acted as a mask hiding the true me. People around me, we were speaking the same career language, and had similar desired career goals. I was easily influenced to believe the entire world would be the same.

My unhappiness gradually grew, though I still associated my unhappiness with the fact that I wasn’t getting what I wanted, without realizing there were deeper issues. That growing unhappiness led me to the final decision to leave big tech and jumped into the startup world.

Fortunately for me, that changed my viewpoint for the better.

Stage 4, I truly knew what I wanted

I was suddenly immersed into a world where I didn’t need to worry about my performance, or my promotion, or my scope. I just needed to worry about building products that users love.

I finally experienced true happiness for myself. Building products that users love, and helping people grow; doing these two things without the need to worry about my own performance or promotion or scope; that is what I truly wanted.

Looking back, now I understood why I was unhappy before. I thought I wanted better performance rating, promotion, bigger scope, and while chasing those, I had to make some decisions that were not best for our user experience. My unhappiness came from the fact that deep down I didn’t like the decisions I had to make, and I was disappointed at myself for making those decisions.

How to figure out what you want?

I strongly believe it’s important for everyone to figure out what they truly want (and the answers will vary per person).

The question is: how to figure out?

Looking at my own journey, I think there are 2 key aspects:

• When you feel happy, keep asking yourself “why am I happy now?” Vice versa for when unhappy. Don’t settle for surface answers; must go deep here.

• Understand different company environments and how they affect you.

Go deep on “Why am I happy now?”

When you get a promotion, you’ll be happy. That’s well expected. However, it’s worth digging deeper on what’s the real reason beneath the promotion that makes you happy.

Maybe it’s because now you will get paid more. If so, you should ask “at what point, more money doesn’t bring extra happiness for me?” And “what are the alternative approaches for me to get to that financial point?”

Maybe it’s because you feel your new title reflects your skill growth. If so, you should ask “what other skills do I want to grow next?” In general, a title is only a proxy, and not an accurate reflection of a person’s ability.

Maybe it’s because you feel you finally get recognition. If so, you should ask “do I need extrinsic validation, or intrinsic validation?” And “are there faster ways to get the validation?” Promotion normally isn’t the fastest path for such validation.

There are other reasons too. The point is, be honest with yourself, and whatever the reason is, it reveals something about yourself. This is a great opportunity to self-diagnose what’s the root reason that you care deeply about. Focus your energy on the root reason.

Understand different environments

Every company is a different environment. Culturally what it promotes and what it discourages can be very different. You need to understand a few of these cultural systems to understand what resonates with you and what doesn’t.

If you have worked for different companies, then you probably have a better sense.

If you have only worked for one company, and you happen to thrive in that one company, this is where the most misunderstanding happens. As time goes, you’ll subconsciously perceive how this company operates is how every company operates, and you’ll unintentionally build muscle memory of how you operate based on how the company operates.

To truly break out of this, you need to eventually switch companies. And I know that’s not easy to do. So short of that, you should try to talk to people from different companies, and learn as much as you can how each company is different, and how they reward different types of behaviors.

Summary

It’s important for everyone to figure out what truly matters to them, beyond the surface answers. And this comes from internally self diagnosing emotions and rationales, and externally understanding different culture systems.

This is not an easy task, and likely will take years to get there. But once that has been figured out, your happiness will jump tremendously. I wish everyone to enter that realm soon.

The Pragmatic Engineer newsletter recently did a survey on AI dev tooling, and out of 216 responses, 40% positive, 30% neutral and 20% negative. This inspired me to share my own experience.

Personal history of editor choices

Let’s first quickly go over my history of editor tools.

• My undergrad was in China, and back then we were using DOS / Win3.1 machines. Notepad was the main editor when I started programming. I still remember the day I opened Borland C++ 3.1, and was blown away by what an IDE could do.

• Coming to the US for grad school, all development work was on Unix, and Emacs became my editor.

• My first job was Microsoft, so I went back to Windows machines, and Visual Studio was the chosen IDE.

• At Google, I switched to Mac laptop (and stayed that way ever since). Development was on Linux, so I learned to do all coding using Emacs on the SSH terminal.

• Leaving Google, I re-entered the IDE world. I tried a lot of different tools, and eventually landed on Atom.

• After selling Leap.ai to Facebook, I was happy that I could continue to use Atom (since Atom was built by GitHub and Facebook), but I was soon surprised that Facebook internally primarily used VS Code. I continued to use Atom for a while, but eventually switched to VS Code as well.

• In Gaida, we started with VS Code, but recently all switched to Cursor.

Why did we pick Cursor?

Honestly Cursor is just like VS Code. UI is the same, all configs / extensions can work as is. This made the initial adoption low friction.

The built-in Copilot is quite good for the free version.

• Git commands are overly complex, and hard to remember. I used to have a git cheatsheet tab open in my browser and check regularly. Now using Cursor, I just use human language to describe what I want, and Cursor can translate it to the actual command. This was very helpful.

• We spend a lot of time in running build commands or tests, and when they fail, we debug what the problems are. Cursor offers insights on the errors, and suggests potential fixes. When it works, it’s amazing.

• During debugging, we often need to add extra logging to help identify the problems. Now I just type “add some logs” in Cursor, and let Cursor suggest the logging code change.

• During coding, we often have similar logic, e.g., we did something to ‘foo’, and now need something similar to ‘bar’. In the old days, copy-n-paste, and then replace foo with bar. Now Cursor will automatically generate the code for bar.

• Cursor copilot is also very good in writing tests, thus truly enabling TDD (Test Driven Development) mode.

If I have to summarize Cursor copilot, I would say it’s as if Stack Exchange has been directly integrated and applied to your local code context.

Limitation of Copilot

Improvements are more on tactical level

There seems to be a phenomenon that hands-on eng consider AI tools to positively improve productivity but eng leadership is much more neutral on this.

My rationale is that AI tools provide improvements on tactical tasks (all the examples above fall into this category). It makes engineers’ lives simpler (less time spent on tedious and repetitive tasks).

However copilot doesn’t help much on strategic tasks yet, like product direction, prioritization, business logic, etc, and these strategic tasks are the dominant factors in overall development speed (which eng leadership has more focus on).

Hallucination

Also, this article won’t be complete without a mention of when copilot does the wrong thing and leads to a disastrous outcome.

Wed night, after finishing a key functionality, I was so excited that I decided to also handle one task that I’ve punted for a while - to turn down the integration test service after integration test finishes. I typed a human command “bring down the service at the end”, and Cursor translated this to a command in github workflow config. I test ran it. Instead of stopping the integration test service, it deleted the service completely. I had to spend 2 hours recovering the deleted service.

Yes, it’s my fault for not noticing the command it translated to is “delete”. A lesson learned. Don’t forget LLM can hallucinate, and copilot output still needs to be double checked by the human.

If you are in the startup and VC world (or in tech world in general), chances are you’ve heard a lot of discussions on the topic of Founder Mode vs Manager Mode, based on Paul Graham’s post.

High level, the gist is that Airbnb CEO Brian Chesky shared that traditional wisdom of “letting professional managers help you scale your company” didn’t actually work for him, and this point was echoed by many successful YC founders.

In other words, the thesis is “if you are a founder, you better run your company in founder mode”.

This gets immediate bi-modal reactions.

• Strong acknowledgement, especially from successful founders. This also leads to some doubts for current non-founder CEOs.

• Strong criticisms that this could legitimize founders’ micromanaging or other jerky behaviors as founder mode.

I have been a professional manager many times (sometimes with founders as CEO and sometimes not), and I’ve been a founder twice. I have seen many variations, and I don’t think this is a black-n-white case. I felt something was missing, but I couldn’t clearly articulate it. Until a conversation with my wife over this weekend helped me crystalize my thoughts.

I call this “Cascading Founder Mode”.

Difference between a founder and a professional manager

I want to start by stating that I agree with Paul that there are clear differences between a founder and a professional manager.

• Vision

  • Founders have specific vision for the product and the company, and have deep understanding where the product should go.

  • Professional managers by definition inherit and work on founders’ vision. They might adjust / extend the visions, but the original direction was set by the founders already.

• Commitment

  • Good founders have the mental commitment to solve whatever problems that come in the way. Quitting individually isn’t an option.

  • For professional managers, it’s well known and accepted advice that “if you don’t get along with your manager, you should consider leaving”. Quitting individually is part of the toolkit.

• People skills

  • Founders without good people skills might still be effective founders.

  • Professional managers without good people skills rarely stay as professional managers.

• Need to manage up

  • There’s nearly no need for founders to manage up. Yes, founders need to be accountable for investors, board, and if successful, eventually shareholders, that’s not the same as “managing up”.

  • Professional managers have been learning about how to manage up for the majority of their career, and normally are very good at it.

• Reward for risk taking

  • Founders have a bigger safety net for risk taking.

  • Professional managers might lose their position for risk taking.

Put it simply, for professional managers, they are working for a job, while for founders, it’s their life.

One famous example

It has been well publicized that when Yahoo offered $1B to acquire Facebook in June 2006, Zuck rejected the offer. All the professional managers around him, including investors (who have been founders before), thought this was a great deal, and Facebook should sell.

Zuck thought differently. He was deeply passionate about people connections and had a long vision about this specific direction. He argued that no one at Yahoo would have this vision, and they wouldn’t build such products / features after acquisition. Therefore this $1B offer way undervalued their business.

This is probably the most famous example where a founder mode decision ended up drastically different from a manager mode decision, and we now all agree that the founder mode decision worked out much better for the company, for the professional managers, and for the investors as well.

Decision differences

My personal experience is that decisions like this actually happen all the time, where a different decision would be made depending on whether it’s founder mode or manager mode. It’s just that most of these decisions are at a much smaller scale or impact, and thus harder to tell.

I list some imaginary examples here where founder mode and manager mode decisions could differ:

• When we launch this product, do we pick logo color A or B?

• Do we prioritize feature C or D?

• Do we hire this person X?

• Do we open a new office in location Y?

• When do we set up a formal performance review process?

Each of these decisions might have a small difference, but as time goes, the difference could accumulate to something that truly changes the company course. It’s just not easy to measure when and how much.

In an ideal situation, a founder learns to be a good professional manager, and keeps that founder mode. Or a professional manager picks up the founder mode (early era of Eric Schmidt in Google comes to mind as an example). Both of these combine the best of both worlds.

So should we just let founders micro-manage to make sure only founder mode decisions are made?

Cascading Founder Mode

The fact is even micro-managing by founders doesn’t actually work.

Ultimately the challenge is that the number of founders in any company is a small fixed number. If the company is successful, the company size grows, more layers are added, and it gets harder for the small fixed number of founders to have direct understanding on the ground. When their feet are no longer on the ground, their micro-managing ability and effectiveness reaches limit, “managing up” becomes more and more prevalent, and miscommunication (intentionally or unintentionally) occurs.

How to solve this inevitable problem that comes with company success? This is what I call “Cascading Founder Mode”.

Before a new layer is added, carefully assess whether the manager candidate can operate with founders’ mindset. We can’t change the fact that they are not founders, and they will have a “I’m working for a job” mindset to some degree. But they can still be closer to founders mindset than “I’m working for a job” mindset.

By taking precautions only, it won’t prevent “I’m working for a job” mindset from showing up. Course correction is also important. If some manager recently hired or converted shows more “I’m working for a job” mindset, the issue needs to be dealt with quickly. Letting it linger will result in it spreading like a cancer, and deteriorating quickly.

Once this is done right, effective delegation will naturally emerge, and micro-managing becomes a non-issue.

Not touched here

It’s worth calling out that I didn’t touch the topic of how to make sure we don’t legitimize founders’ jerky behavior as founder mode. While everyone agrees with this statement, it’s much harder to figure out what behavior crosses the line to become jerky. It’s probably a good topic for another day.

It’s now September 2024, and it’s been slightly more than 3 months since I started full time on Gaida. This long weekend served as a perfect time for a 3-month reflection.

The key phrase that jumped to my mind is “Move Fast”.

Move Fast

This is Meta’s culture #1. It used to be “Move Fast and Break Things”, and when the company became big, the “break things” part no longer made sense and got dropped. “Move fast” stayed as the culture.

When I first joined Meta, I was so thrilled by this culture statement, since it perfectly matched the startup mentality I enjoyed. Everyday, I observed first hand how such a big company could keep moving fast. Have a new idea? Create a diff and the experiment starts within hours; within a few days, metrics show up on the dashboard. Iteration speed was truly amazing.

However, as time went by, I started to notice downsides. Many people were not pausing to learn from past mistakes, or handling edge cases. Instead, oftentimes it’s whatever made metrics good was treated gold.

When I stepped back and looked at the bigger picture, I noticed the team often ended up in a circle: a) having a hypothesis about what would move a metric, b) jumping all in and hacking things up, c) observing metric didn’t move, d) jumping all out and completely abandoning the previous effort.

This is when I realized a key question: “Move fast, in terms of speed or velocity?”

Physics Refresher: Speed vs. Velocity

High school Physics class was the first time I encountered the concept of scalar vs. vector values, and the difference between speed and velocity.

• Speed is a scalar value, measuring how fast an object is moving at any given moment

• Velocity is a vector value, and it has a direction attached to it.

Normally in terms of the absolute value, speed and velocity don’t differ that much, since velocity can be interpreted as speed with a direction.

But in certain cases, they can be drastically different. One such contrasting example is when an object spins in a circle. It moves constantly at high speed, but each time it circles back to the original starting spot, the average velocity would be zero.

Move Fast, in Speed or in Velocity?

Let’s go back to the previous example: a) having a hypothesis about what would move a metric, b) jumping all in and hacking things up, c) observing metric didn’t move, d) jumping all out and completely abandoning the previous effort.

Throughout the entire time, everyone was actively moving. Lots of motion. But when the effort was abandoned, velocity was zero.

If we kept the learnings and applied that for the future, I’d still consider that as a positive outcome. However, more often than not, the learnings were not properly summarized, nor properly shared. In other words, it just ended without much splash.

Never confuse motion for progress.

Consistent Direction and Steady Pace

In the story of “The Tortoise and the Hare”, the tortoise won the race. Why? It’s the combination of consistent direction and steady pace.

Consistent Direction: Be clear about the north star, and from time to time step back to check whether we are getting closer to our north star.

Steady Pace: The tortoise taking a slow but steady pace beats the hare sprinting and then napping. The finish line might seem far away, but the attitude of one step at a time towards the finish line can quickly accumulate a lot of progress.

Move Fast, in Velocity.

Last week one of my previous colleagues asked me, “How did you decide whether an idea is worth committing to for your startup?” I said, “Ah, I figured that out before my first startup!”

In 2015, I left Google, and joined Sumo Logic to learn how to do startup. Instead of identifying an idea first, I took an engineering approach to establish an evaluation framework first - if I had an idea, how would I evaluate whether the idea would be worthwhile pursuing?

I came up with 4 criteria:

1. General Demand

2. Social Good

3. Monetizability

4. Personal Passion

I want to clarify these are my personal choices, and they’ve stood the test of time for me. These are not golden rules for everyone, but hopefully useful for many future entrepreneurs.

#1. General Demand

It could be a 2C or 2B product; if 2C, (almost) every consumer needs a product like this; if 2B, (almost) every company needs a product like this.

Key phrase 1: 2C or 2B

Back then, I haven't developed a strong preference between 2C and 2B yet. I was open to both. In fact, I did my first startup Leap.ai as a hybrid, which had both 2C (helping consumers develop career success) and 2B (helping companies hire talent) components.

After Leap.ai got acquired by Facebook, and worked in Facebook / Meta for 5 years, I now have much stronger interest in 2C. The complex distribution among consumer preferences is more intriguing to me personally.

Key phrase 2: (almost) every

When I was at Google, my naive thinking was it would be easier for me to pick a niche market, and build a dominating product in that niche market.

The top lesson Sumo Logic leaders taught me was, it should be the opposite. Go chase a large market. The key is the overall pie needs to be big. When the overall pie is big, even if my initial slice is small, I can always work to increase my slice. If I go after a niche market, there’s no more growth after I am the dominant player.

VCs always look for “market size” in pitch deck, for exactly this reason.

Key phrase 3: needs

Elementary schools in the US teach the concept of “need” vs. “want” early on. When my daughter first learned about it, it was an eye-opening moment for me. Growing up, I never learned or was made aware of the subtle but critical difference.

“Needs” are must-have; “wants” are at best nice-to-have.

Silly example: food is must-have, and ice cream is nice-to-have. Complication: is coffee must-have or nice-to-have? For some people, coffee is must-have to keep their energy, and for some it’s nice-to-have.

More interesting complication: it can change too. Grocery delivery was nice-to-have, but then became must-have during COVID, and post-COVID, is it now must-have or nice-to-have?

#2. Social Good

The product of my startup, if done right, should bring value to humanity.

There has always been lots of controversy around Google’s “Don’t be evil” motto, but I always felt strongly connected to the underlying theme that technology should help humanity and do the right thing.

There are many areas which have strong demand, and can make lots of money too, but I personally wouldn’t want to be involved since I can’t justify whether they are overall good for humanity.

Note that I’m not saying technology has no down side. I believe everything has 2 sides of the same coin; nothing is purely good nor purely bad. It’s the overall tradeoff that determines.

#3. Monetizability

The company needs to make money.

When I first developed this framework in 2015 / 2016, it was common for startups to only chase user growth, with a statement of “we’ll figure out monetization later”. But I preferred it differently. For any company to do social good, the more money it makes, the bigger potential it can contribute to social good. Therefore I insisted on checking monetizability from day 1.

Granted, I wasn’t saying the startup needed to be profitable from day 1; almost no one met that bar. I just didn’t want the monetization plan to be handwavily postponed as an afterthought.

It just happens that VC trend since COVID years has also moved towards this direction. Nowadays monetizability / profitability becomes a tablestake for VC investments. So this is no longer a controversial point any more.

#4. Personal Passion

I must personally feel passionate about the domain.

Entrepreneurship is a long grind, and requires grit and perseverance. If the founders don’t have personal passion for the product, it’s much more likely along the way some event triggers the thought of give-up, and once that thought comes up, it likely only grows.

Therefore if I don’t have passion for a certain domain, I shouldn’t pick that domain for my startup.

Test Cases

1st startup: Leap.ai

Back in 2015 / 2016, I got lots of feedback whether the criteria were too restrictive, and people were suggesting to me that maybe 3 out of 4 would be good enough to consider.

Then Richard pitched to me the idea of Leap.ai, and I found out all 4 criteria were met, and for the first criterion, instead of EITHER-OR, it even met AND.

• General Demand

  • Leap.ai has both 2C and 2B components. Every consumer needs some service to help them succeed in their careers, AND every company needs some service to help them hire the right talent.

• Social Good

  • If Leap.ai were to succeed, it would improve overall society efficiency by helping people better find employment opportunities, vice versa.

• Monetizability

  • It’s common practice for companies to pay headhunter commission fees, thus it’s easy to monetize Leap.ai product.

• Personal Passion

  • I have intrinsic joy mentoring people / helping people grow and succeed.

2nd startup: Gaida

Now in 2024, the idea Gene and I are pursuing also passes all the criteria. I’ll update this section once the idea is more broadly announced.

Conclusion

I have high confidence this criteria set serves me well to guide me to narrow down what to work on. It doesn’t have any correlation to whether the idea works in the end. That is left to execution (and luck too), and the uncertainty is the exciting part.

Onwards…

Last week, when discussing interview candidates of different experience levels, my co-founder Gene asked me, “any thoughts about the biggest learning leaps between year 3 and year 10?” This made me think…

I worked 3 years at Microsoft, followed by 10 years at Google. So between year 3 and year 10 for me would squarely be my early Google years. What did I learn the most during that time?

I grew from a L4 eng to a L7 eng; I led more projects; I became a manager, and team size grew; I had more achievements under my belt; I moved from Pittsburgh to Mountain View and took on a brand new initiative. I became a father and had 2 daughters. A lot happened in those years, but what would I consider as the biggest learning leap?

Then it hit me, it’s the understanding of “Individual Excellence vs. Team Excellence”.

It starts with individual being excellent

Throughout our early education, we understand the individual excellence component. Individually we strive for better knowledge, better grades, better experiences. Of course we were taught of the “teamwork” concept, and there were team projects throughout the journey. But still, for the most part, we are evaluated as individuals.

• Applying to college? We are being assessed as an individual.

• Graduating from college, and going through a job interview? We are being assessed as an individual.

• Got a job and going through performance review? We are being assessed as an individual.

It is an environment of “I need to be excellent”.

Team excellence == sum of individual excellence, maybe?

Then I became a tech lead, and then a manager. I was responsible for the team’s and the product’s success. At this point, “team excellence” became clearly an important aspect for me.

How did I tackle the team excellence challenge? By making sure every individual in the team was excellent.

I hired the best individuals into my team (meaning competing with other hiring managers from the same talent pool); I rewarded my high performing team members with bigger scope and promotions; I managed out low performers.

My teams were always high performing teams. Because I always made sure every team member was excellent individually. I cracked that nut!

Until the Action Ads project.

I briefly mentioned the before-launch moment of the Action Ads project in my tribute to Susan Wojcicki last week. Here I’ll talk about the conception moment.

My team started as a Knowledge Ads project, with the charter of figuring out how to use Knowledge Graph in ads. The original idea was on infra and targeting, and therefore I built the entire team with infra and ML experts.

Action Ads was to build movie streaming ads in the Movie Knowledge Panel. It had a very aggressive launch timeline, and therefore the original proposal by leadership was to ask Google Shopping team to use their existing technology to hack up something. After learning about this, I volunteered my team to build it, truly using the Knowledge Graph technology. I was told we had to hit the original launch timeline, and I took the bet.

The team was really excited, but we realized one issue. No one on the team knew how to make UI changes, and this project needed to make UI changes on google.com knowledge panels.

A team of excellent infra and ML experts can’t make simple UI changes - quite obvious.

I first tried to borrow UI engineers from other teams, but was rejected. We had to be self-sufficient.

I assessed everyone on the team, and made my guess who were more likely to succeed in taking on UI responsibilities. I then talked to them in private, and convinced them to give it a try, with a promise that I would focus on hiring UI engineers if this became an ongoing need.

It worked. 3 months of heavy engineering later, we were technically ready, thus enabling that before-launch moment of beach walk.

True team excellence == individuals do what makes team better

Those 2 infra and ML expert engineers who took on the challenge to tackle UI? They went on to become successful all-around eng leads. They suffered extra burden and uncertainty during the first few months, but it paid off in the long run.

I took away a key lesson as well, building a solid team does not mean building a team of solid people of the same skills.

Change is the only unchanged nature of our business, and diversity and open-mindedness are the most critical components to defend against unknown future change.

As a leader, it’s my responsibility to assess what my team’s weakness will be in the event of unknown future changes, and work on mitigation plans accordingly.

It should be an environment of “Together, we need to be excellent.”

What would you do for your team to maximize team excellence?

Some time around new year of 2014, at Seascape Beach Resort in Santa Cruz, I was attending Google Ads Leadership Summit. This was organized by Susan Wojcicki, then SVP of Google Ads org. After the dinner, we had a bonfire on the beach, and Susan joined us.

At that time, my team was working on a project called Action Ads (which was later reported publicly by Search Engine Land and many other media). The idea was straightforward. For a movie, we’d offer streaming service providers a chance to bid to show themselves on movie Knowledge Panels, and this would be a brand new ad format.

We built all the technology needed to launch this, but it hit a wall.

Back then Google was organized into different Product Areas (PAs), each led by one SVP, and this project stirred up conflict among multiple PAs. Search (which owned Knowledge Panels), Ads (which Susan led, and my team was part of), YouTube (which offered these movies to be streamed), Android (which offered Google Play where these movies could be bought), all had opinions on what this Action Ads product should be.

My team was caught in between. We worked heads-down for 3 months to get the product ready, and then were put in a holding pen to wait for leadership decisions. I was full of uncertainty on that summit day.

Susan noticed, and grabbed me for a walk. We had a long walk on the beach. I unloaded my frustration on the situation. Susan mostly listened, occasionally asked for clarification questions or my opinions on tradeoffs, but didn’t offer much of her own opinions. At the end, she told me “I’ll talk to Larry [Page] tomorrow”.

Susan then worked her magic to align with the entire L-team (Larry Page’s leadership team was called L-team). Lots of negotiations later, we got a launch approval, signed off by the entire L-team. It was a compromise product decision, best illustrated by the Search Engine Land’s article:

Google Play is featured first with a sort of enhanced listing that includes the brand icon and “Watch” call-to-action. An “Also available from” ad listing appears below the featured ad spot on several results. Amazon is the only streaming services included in the “Also available from” that we’ve spotted at this point. … Update: Hulu Plus is showing on some results.

This product decision wasn’t the ideal our team was hoping for, but it allowed us to launch to the public, and that put us through the moon.

This was Susan’s super power. In an environment where leadership is often defined as aggressively dictating the outcome, Susan demonstrated a different type of effective leadership. She brought humanity, she understood where people came from, and she communicated effectively to bring people into a common understanding and agreement, thus move forward. I learned from Susan what Humane Leadership is.

According to Google GenAI search result,

Humane leadership is a style of leadership that focuses on people, ethics, and culture. It's about putting people first, recognizing their value, and treating them with respect and dignity. Humane leaders are empathetic, compassionate, and authentic, and they listen to their team members' concerns and ideas. They create a culture of trust, transparency, and accountability, where mistakes are seen as learning opportunities and success is celebrated as a collective achievement.

RIP, Susan. We will remember your humane leadership.

When I worked in Meta, I had an internal workplace group called “Yunkai’s Tidbits”, and it was well received. Towards the last couple of years, work got busy, and I didn’t have much time to write. Therefore when I left Meta, I decided to commit to regularly writing and publishing. For the platform, as suggested by a former Meta colleague, I chose Substack. For the domain, as suggested by a former Google colleague, I registered yunk.ai.

• Figuring out logistics of publishing, check.

• Finding time to write, check.

• Next task: distribution.

Since most of my content is tech / career related, distributing to LinkedIn is the natural choice. And so far the results have been great. The following is the growth chart of subscribers.

Last week, as inspired by Celine Dion’s performance at the Paris Olympics opening ceremony, I wrote I Am: Celine Dion. While the content has some tech / career implications, for the most part it’s a personal story, and therefore I felt Facebook was the more suitable channel. I shared the post on Facebook, and not on LinkedIn.

4 hours in, zero impressions / likes / reactions on Facebook.

When I first noticed this, my immediate reaction was my Facebook account got flagged and thus no distribution. I manually created a few more posts just to test whether they get any distribution. One of my close friends told me that he could see all the posts on my Facebook profile. This means that my account was fine, but the post was not showing up on others’ newsfeed.

In other words, it’s the Facebook newsfeed ranking algorithm that decided to downrank my post and not distribute it.

A few hours later I decided to post it on LinkedIn as well, just for comparison. Impressions / reactions on LinkedIn for this post were lower than other tech / career dedicated topics, but they still accrued. LinkedIn surpassed Facebook in distribution quickly, even though LinkedIn had less time.

So, the lesson learned here is even for personal story content like this, LinkedIn outperformed Facebook as a better distribution channel.

But why?

It’s ironic that I worked in the Facebook App org for several years, and I actually have deep connections / knowledge about Facebook newsfeed ranking. I simply forgot about it until this experiment.

• Facebook newsfeed downranks posts with outgoing links.

  • Facebook app today is not the same as the original Facebook app 15 years ago. When Facebook first came out, it’s a place where people re-discovered their old friends, and genuinely shared their latest updates. Users scrolled on Facebook to learn about what their friends were doing. The content was referred to as a connected feed.

  • Facebook app today is to try to keep users to scroll, period. Most content is unconnected, like popular reels. Of course, this is in response to users’ changing behavior. TikTok has demonstrated that users, especially younger generations, like to scroll on entertaining unconnected content.

  • If the post has an outgoing link, it increases the chance users click on the link, leave the Facebook app, and not come back right away. Thus posts with outgoing links likely hurt overall short-term engagement, and are downranked.

• Facebook (or any social media) ranking is now oriented towards encouraging low-friction reactions (including likes, emojis, etc).

  • 15 years ago, social media encouraged comments and conversations. Those were the preferred demonstration of interest.

  • Now social media encourages likes. It’s a lot less effort for users, and you can make an argument that a post with 100 likes is more interesting than a post with 10 comments.

  • Conversations are disappearing; many social media become primarily for one-way communication.

In summary, Facebook / Instagram / Snap / TikTok are distribution channels for content that’s image / video centric, and first-instinct reaction driven. Content that requires deep thoughts to consume? Not the most suited here. I guess I’ll mostly stick to LinkedIn for my content going forward.

As a side note, I understood all of these as an insider, but still forgot as a genuine user. This is the amazing piece that made me reflect: Never forget the viewpoint of a genuine end user; we always respond to a product as a genuine end user, not as an insider.

Paris Olympics 2024 opened this week, and the opening ceremony created a lot of Internet buzz, like not being held in a stadium, controversial themes of certain performances.

To me though, the most mesmerizing part is Celine Dion’s performance.

The previous weekend, I was randomly on Amazon Prime Video looking for something to watch, and “I Am: Celine Dion” was the top promoted program. It’s been that way for some time now, but this time I clicked into it.

The opening scene is Celine recording a public announcement that she has stiff-person syndrome (SPS), and can’t perform any more. I was immediately captured.

I first came to know Celine when the movie Titanic came out towards the end of my college years, and the song “My Heart Will Go On” was everywhere in China. Celine’s voice was so clean that it just hit the heart. We used to joke that “‘My Heart Will Go On’ makes my heart stop, but thankfully my heart will go on after the song ends”.

A few years later, Celine announced she’d start residency in Las Vegas (which wasn’t a popular trend for singers back then), and we went to see her live performance in Caesars Palace. Besides her amazing songs, what surprised me the most was how much the venue was especially adapted to her songs. That was the first time I got a deeper understanding of Las Vegas entertainment.

For the next 15 years, with kids and work, I didn’t closely follow her. I would still hear all her new songs on radio though, since her slightly-French-accented English and her vocal chords were just so distinctive.

Until a couple of years ago, I learned from news that she had paused all her performances (residency and tour), since she’s been diagnosed with the rare SPS (about one in a million people), and will gradually lose her muscle movements.

The rest of the details were filled by the “I Am: Celine Dion” documentary. Celine didn’t hold back in this documentary. She was very transparent, and invited her audience to take a close look at her day-to-day life. Her dedication to her music, her struggle with her voice, her love for her kids, her affection for her staff; all of that was clearly demonstrated in this documentary.

But the most unusual piece is an unscripted recording of her seizure episode.

Celine was trying to record a new song. Her voice wasn’t fully ready yet. She recorded a few takes on day 1. Day 2, she came back to listen to the previous day’s recordings, and didn’t like them. She wanted to try again. She practiced on the spot, and made a few attempts at recording. Then she was late to her doctor’s session.

Walking in, she first apologized to the doctor for being late. She told the doctor she was trying to record a new song, and felt happy. The doctor asked her how her SPS symptoms had been, and she said she was having a spasm at the moment. Doctor explained that her brain was stimulated by the song practice and recording, and the stimuli weren’t properly released to the muscles. He asked Celine to lie down on a massage bed, and tried to massage her hand muscle. Right at that moment, Celine went into a seizure. The doctor called in an assistant to help him, applied some nasal sprays, and recorded his treatment.

All of that was captured by the camera. There was a moment the doctor even asked Celine whether she wanted the camera to be turned off, Celine gave a signal that it’s okay. This entire episode was genuinely recorded, and shown in the documentary.

It’s Celine’s choice to show her extreme vulnerability with the rest of the world. I can clearly see many of such deliberate decisions throughout this documentary. She didn’t choose to hide, and vulnerability brings trust.

As an audience sitting in front of my TV, I felt immensely close to her, and couldn’t help but admire her courage and fighting spirit. I know SPS has no cure, but I sincerely hope the doctor and medication can delay the inevitable, and at least in the near term bring her back to the level to perform again.

Then, just a few days later, I was completely surprised to see her perform live at the Eiffel Tower. After the performance, Kelly Clarkson couldn’t hold back her emotions and called Celine “a voice athlete”. If I hadn’t just seen the documentary a few days before, I would have just listened to her song, and probably thought her voice is no longer as pristine as 20 years ago. But with the documentary as the anchor, all I felt was joy that the doctor and medication indeed has brought her back to the level to perform again. Celine didn’t need to say yes to the performance invitation, but she must have pushed very hard to be ready.

In the rain, on top of the Eiffel Tower, I listened to “Hymne A L'Amour”, but I witnessed “My Heart Will Go On”.