With postmortems, some common losing battles:

• “My thing is more complicated”
• “My thing was under-resourced”
• “We didn’t have enough time”
• “We should have built more automated testing earlier” — usually, you know that it was failing and investing time in testing would not have helped

You will be more successful with:

• “We should have decreased scope in X way”
• “We could have de-risked by doing X”

Other failure modes:

• Assuming simplicity in someone’s domain

Other things I’ve learned recently:

• Even if you are not responsible for implementing change, you can be responsible for highlighting problems and sharing the state of the world, and shining a light, even if it is embarrassing.
• One of the most useful things you can do is have data that is presented well.
• There’s a difference between saying “Ok, I agree” and then feeling responsible for the risks vs. saying “Ok, I agree, but here are the risks” and having the peace of mind that you pointed out all the problems (and that your party is also aware of these problems)

I asked my co-worker Blake recently about his feedback on an escalation path I had written for reporting issues with Tesla’s in-car entertainment system. He was very good at thinking in terms of frameworks (“Is this supposed to be an algorithm that customer service follows to a T or rather guiding principles?”), alternative solutions (“diagrams are more consumable than lists”), and edge cases. I told him he thinks surprisingly long-term for someone at Tesla, or in any fast-paced startup environment where the default is to rush urgently to solve a problem, and then sprint to the next fire. He said for him it’s important to take things slowly, because he can think through why it happened and make sure it doesn’t happen again. I realized in this way, he develops a repository of repeatable approaches to solving any kind of problem. My boss does this too. People say she’s going to run the entire org very soon. I notice she thinks carefully about everything — whether she’s negotiating a business deal with Spotify, or phrasing the wording of an email with a random startup who wants to partner with us. This allows her learnings from each situation to compound, so that whenever she runs into a problem, for her it’s always: “just another one of those x issues.”

This reminds me of one my favorite quotes, “Even though your work seems very trivial and contemptible, make sure you regard it as great and precious, not on account of your worthiness, but because it has its place within that.“

The other day I had a difficult meeting where I was under a tremendous amount of pressure from our engineering directors. My boss J was sitting in it for the first time — J didn’t say anything during the meeting, but after the meeting, he gave me a step-by-step rundown of how the meeting went, the things I said, and how if I had framed things a certain way, I would have been more effective. Two things I learned from our debrief:

(1) Use detail as a tool to build trust.

There are little things, that when phrased differently, can have a big impact. In the meeting, I was under a lot of pressure to reach alignment with an Autopilot manager to decide whether his features were shipping with this release, but I was having trouble getting in contact with him all morning. You could explain the situation to the executive team in two ways:

Less useful: “I couldn’t get a hold of them.” (your bias for action is abstract)

More useful: “I tried calling them, but they didn’t pick up.” (your bias for action is concrete)

It’s a small difference in word choice but a big difference in how people perceive you as someone who is capable of driving results.

(2) Being decisive about the world enables you to make progress faster.

Most people who ask someone to make a decision, ask for a decision in an open-ended way. e.g. “what are you going to do about X?” Even the directors fell into this trap when they asked Autopilot manager, “What are we doing about these new features?” It’s much more useful to instead, define the world for them, and ask them to answer the question in the context of the world you have defined.

Less useful: “What are you doing about this new feature?” (the conversation goes on for 30m+ as we navigated through all the assumptions that needed to be made in order to answer this question)

More useful: “We are shipping this firmware in 5 days. Are you going to be on the train or not?” (by indicating when you are going to ship the firmware, you define the world for them)

You can always change the context later, but defining the world makes it easier for them to make a call, because you are scoping down the unknowns.

It was refreshing to get this level of feedback — most feedback at work is about overall performance than at a day to day level. I remember when I first started playing rugby at Brown, which went undefeated in the Ivy league for several years, I was amazed at how quickly I picked it up. At first, I arrogantly attributed it to my athletic dexterity — then I realized it was the nature of the training program — the immediate feedback from our coach on all the micro-drills created the perfect feedback loop. I was being given targeted guidance on exactly what I was doing wrong and why. And wasn’t just rugby — the same dynamic also helped me in coding. And it’s not just me — as people, we are beholden to making progress in environments with tight loops.

When I was in grade school, one of my favorite English teachers would often remind us, “if you can write, you can do anything.” I would always think, “well of course she’s saying that… she’s an English teacher.”

I’m reading Alexander Hamilton’s biography, and he had quite a facility with words, even when he was a teenager growing up in poverty-stricken St. Croix. When a storm devastated the island inhabitants, Hamilton wrote, “…the ear-piercing shrieks of the distressed, were sufficient to strike astonishment into Angels,” in a letter to his father at the tender age of seventeen.

Hamilton may well have stayed in St. Croix for the rest of his life had the Gazette not picked up his letter and published it in their newspaper anonymously. The island governor demanded to know who wrote the letter, and a group of local businessmen raised a fund to send Hamilton to America to be educated.

Before we had writing, we always needed to be in the same place at the same time in order to communicate. The appeal of writing is that it allows you to exchange ideas without time or place needing to be relevant. When I look at some of my role models — I often realize that they’re not particularly smarter than many of the other people in my life — rather, they document their thoughts. Without Paul Graham’s essays, his ideas about the world would be trapped in his head and few would be privy to them. Writing is much more scalable than conversations.

During my last improv class, we did an exercise where everyone had a monologue. I was surprised at how each person was able to make a scene come to life with a beginning, climax, and end so seamlessly. When one of my classmates Olga went on stage and was given the location ‘ice cream shop’, she immediately transformed into an ice cream shop server. As she pranced around the shop, she sampled a taste of ice cream and made the ice cream cone come to life. She took a few licks, and then scolded the ice cream cone for making her butt big, but wrestled with how delicious he was. She finally decided to toss the ice cream in the trash. Every person appeared as if they had been preparing for this scene for the past week.

But none of them had any even preconceived notions in mind. They had all been given a random location on the spot, and had to create a scene based on that location.

I notice an analog in programming. When I was pair programming with our front-end developer Bruno today, I asked why he had defined a function in class A but not in class B, I expected him to be prepared with an answer. Instead, he said “Let’s investigate” and opened class A, going line by line to trace back where the method was being used. He realized that there actually was no need for that method and we ended up taking it out.

You can’t know the answers to some things in life. And trying to hold everything in your head is exhausting. What you can do is be quick to adjust in the moment and execute on the spot.

A popular strategy for bootstrapping products is what I like to call the Wikipedia Effect. Wikipedia didn’t set out to build an entire encyclopedia by themselves — they knew their comparative advantage was not in knowing all of the information in the world. Rather, individuals all over the world would likely have more knowledge about topics spanning zoo archaeology to Dostoevsky than a single company ever would. The Wikipedia Effect is identifying what people are good at, and leveraging their strengths to create value.

This strategy is difficult to internalize, because in order to execute the strategy effectively, we have to recognize our weaknesses, and humans typically have defensive, emotional reactions — ego barriers — that stand in the way of progress. Those who get over the ego barrier, might be prone to an engineer’s mindset — wanting to understand and implement every piece of the puzzle, instead of outsourcing their weaknesses to another party.

My friend P is currently working on his next venture. P doesn’t have a software background, and instead of spending a year learning programming, he quickly recognized what he was good at, what he was not good at, and hired a product manager and two engineers as contractors. He built the product in 6 months and already has several customers.

The Wikipedia Effect isn’t the only way to build a company. Some people go to coding bootcamps, learn how to build the thing themselves, build the thing, and then earn customers and revenue. This path, however, is harder and requires more time and effort.

The first company I worked for out of college had a lot of politics*.

“Maybe politics is inevitable. And part of having a job is learning how to navigate people and make your contributions visible so that you can get promoted.”

I thought. So of course, I spent considerable effort on making my contributions visible. While I accepted the fact, I was frustrated and believed there ought to be a better way. I realized I felt as if I needed to appear successful because there wasn’t a clear definition of success. Our teams had no OKRs or systems for decision-making. Because there wasn’t a clear definition of how an employee is promoted, I thought I could get there by schmoozing with the C-suite instead of finishing the mock-ups for our next product.

When success is poorly defined, people find ways to achieve the appearance of success.

When I asked K at Uber whether people were ever promoted because they were good at appearing successful, but didn’t have the skill. She replied, “No, if they didn’t have the skill, they would be fired.” She explained that at Uber, each team and individual knew their definition of success, and if they didn’t meet that criteria, they would not advance.

When success is clearly defined, people are no longer making decisions based on how others will react, but rather, on what they genuinely think will help reach the team’s set goals, moving the company forward.