How Alexander Hamilton increased his luck surface area

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.

The impact of improv on your professional success

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.

Leverage the Wikipedia Effect to bootstrap your product

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.

Validate before building

A difficult concept to internalize for those first starting a startup is validation. Founders might talk to people about the idea, try and evaluate the feasibility of the idea, and get caught up in implementation details, making market need an after thought.

With my first company that focused on automating drug development for pharmaceutical companies, K and I spent many of our days reading research papers about Alzheimer’s and the nuances of beta amyloid plaques. We were learning a lot – but not exactly about our product-market fit.

After the first company, we decided to prototype a genetics product. We instead started with market need and put up a landing page for the product, set up a ‘Pre-order now’ button, ran an ad campaign, and asked people for feedback. While we had one customer pre-order our $500 product in the first few weeks, we also learned about the idiosyncrasies and doubts of our target consumers much more quickly than the first time around.

That said, whether a product can be adequately user-tested or not depends. Enterprise products that are only used by one person are easy to user test. Consumer products, on the other hand, tend to be more difficult, especially if they have a social component and require network effects for the user to realize value.

The trap of wanting to appear successful

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.

* Politics is defined as when people choose their words and actions based on how others to react rather than based on what they really think (Lencioni).

When top performers leave your company

Some companies try to keep their top performers and pressure them into staying. This response can create uncomfortable social pressure and cause the employee stay for the wrong reasons.
H told me he’ll have conversations with his manager where, while they highly value him, will talk about, “Where should H go next?” Does it make sense for him to join a nonprofit? Start a new company? Because his manager shows genuine investment in his growth, whether its with the org or not, he continues to stay on and want to learn from her.
Other companies, like BCG, accept that their top performers will stay for two years, and then leave and do something else. These companies that accept the high turnover rate are building a natural forcing mechanism for sustainability. Because they know that their top performers will only be contributing for two years, they must prepare themselves for long-term sustainability by putting structures in place, like documentation and training, to enable new employees to rapidly learn and contribute to the organization.

A formula for deciding what to build

I’ve noticed making high-level decisions at a mid-stage company is trying. Prioritizing at a startup is easier, because you have less groups clamoring for your attention. But when marketing asks for more money for ad campaigns and the engineering team complains about how they’re overworked and need another developer — how do you know which ones to select and execute on?

One way is to draft a list of all these priorities and ask everyone to vote. This approach democratizes decision-making, which, if done too much, can lead to a company without a clear product drive.

Another way is to ask two questions. Everything boils down to numbers.

Question 1: What are the inputs?
For example, if you want a marketing campaign, do you need more money for Google ads (external) ? Do you need to a month of engineering time (internal)? Often people think about external costs, but forget about the cost of internal company resources, which are just as valuable.

Question 2: What are the outputs?
All businesses have 3 goals. So these inputs must be manipulated in some way to generate output into one or more of these company goals:

  • (1) Revenue
  • (2) Cost savings
  • (3) Market growth

Thus, the decision about what to build becomes simple. You make the decision based on the input/output ratio.

Troubleshooting OAuth

When I first started implementing OAuth, I thought it would be difficult, but I realized with all the libraries and documentation now a days, implementing would be very manageable. While I thought using libraries to help would speed up the implementation — in hindsight, implementing OAuth with rauth, a Python OAuth wrapper library, unnecessarily abstracted away both logic and understanding.

OAuth consists of 5 components:

  1. Present user to webpage
  2. Page redirect to facebook
  3. Get code
  4. Exchange code for an access token that you store
  5. Use that access token to access user data with API

The complications usually lie in the details. The common problems I ran into were:

1. This authorization code has already been used.
I was calling the authorization code twice, when I should have exchanged the code for an auth token and called the auth token twice.

2. Incorrect access token
I had already exchanged the code for a token with rauth, and was trying to do it manually:

def facebook_authorized():
  code = request.args.get('code')
  if not code:
    return redirect(url_for('index'))
  data = dict(code=code, redirect_uri=get_redirect_uri())

  # rauth request
  fb_session = get_facebook().get_auth_session(
    decoder=lambda x: json.loads(x.decode())
  me = fb_session.get('me?fields=id,email,name').json()

  # manual request
  res = requests.get('', params=token_params)
  access_token = res.content.access.token

To get the access code from rauth, I can use

access_token = fb_session.access_token



Documentation is better than StackOverflow
With documentation, you can figure out the first principles by yourself and troubleshoot your specific use case. Sometimes, StackOverflow can shortcut this for you, but more often than not you’ll solve the symptom but not the problem.

Don’t overoptimize too early.
I made the mistake of abstracting my OAuth functions into classes and started running into errors — the abstracted data structures made it difficult to pinpoint what the problem actually was.

Understand principles before jumping to the code
Rather than copying and pasting coding that you don’t understand, first understand how it works manually (i.e. the 5 steps above) and try to replicate that yourself.

Explaining Information Entropy to a 5 year old

Suppose there are 8 numbers. I choose one, but you don’t know which number it is. Your task is to guess which number. You can ask yes or no questions. What is the minimum number of questions you would need to ask to guess the number?


All have an equal chance of occurring (P(any number) = 1/8).

What would be your approach for asking questions?

Start at the mid-way point and asking if the number is less than 5.  Suppose the answer is yes. Now you know the number must be


Do the same thing and ask if the number is less than 3. Suppose the answer is yes again. Now you know the number must be


Now you ask whether the number is 1, and if the answer is no, then you know the number is 2. You have guessed the number in 3 questions.

3 is the minimum number of bits you would need to use to encode the probability distribution of these 8 numbers. This algorithm is at the core of how we are all able to send emails, pictures, and videos so quickly now. Before the father of information theory Claude Shannon had invented this algorithm, it was unthinkable to send a picture — even a voice message, across the globe. There was simply no efficient way to send it. Nobody knew how many bytes it would take to encode the message, or even how to encode the message.

Next question: What if the numbers did not have an equal chance of occurring?