Lieutenants are the limiting reagent
The statement "this company lacks focus" confuses me. Don't companies hire more people in order to do more things? Shouldn’t the number of things the company can "focus" on expand as you hire?
Clearly that is the case: Google has 100 products more than any new startup could have. But if anything, 100 products seems too few; after all, they have 200k employees! For reference, Instagram launched with less than 13 people. If Google were as efficient as Instagram was, they "should have" 150x more products.
Continue reading →Interfaces for logical migrations
This post explains how you can use interfaces to make data model and database migrations easier.
Imagine you run a B2B company and Account represents how you want to bill each of your clients. Account is both a table in your database and an object in memory that has:
Everybody is the main character
As a manager you are seen as the default main character of your team. In group meetings, you tell the collective story that guides everybody.
But an important part of being a good manager1 is to have others be the main character as well. You should give each of your reports space to write their own individual story in one-on-ones.
Continue reading →Team-oriented, outcome-oriented
Maybe the real treasure was the friends we made along the way.
No, I want my fucking gold.
In my career, I’ve found two different ways1 in which people are motivated:
Continue reading →Breaking changes in JSON APIs
For an overall product development strategy, see How to avoid breaking APIs.
When writing graphical user interfaces, the end user is a person. If the user interface changes overnight, the user might be surprised but they can adapt and react accordingly. Most software companies are used to changing their products often in various ways. API products don’t have this luxury.
Continue reading →How to avoid breaking APIs
When writing graphical user interfaces, the end user is a person. If the user interface changes overnight, the user might be surprised but they can adapt and react accordingly. Most software companies are used to changing their products often in various ways. API products don’t have this luxury.
APIs are used by programs which can’t adapt to change. So, whenever you change an API, the change should be backwards compatible so that the new API version can be used by existing integrations. For a list of breaking changes one can make to JSON APIs, see Breaking changes in JSON APIs.
Continue reading →Payments vs Transfers
Every so often, somebody will tell me how crypto will render Visa and Mastercard obsolete. Crypto could do that one day but what we have today is not enough. Other people tell me that crypto is terrible, Visa is also terrible, and that payment fees should be absolutely zero. In both cases, when they run me through the logic, I often realize that they don't understand the difference between payments and transfers:
- A transfer is the simplest operation: you move money from account A to account B. They are usually irreversible1 and in many cases, the same entity often controls both accounts. For example, you send money from your bank to your broker.
- A payment is made in exchange for goods and services and it has an implicit contract associated. The rules of this implicit contract are codified in the payment network rules.
Math intuitions on variance
This is a supplement to High Variance Management, where I build some intuition on the different probability distributions involved. Please read that post before reading this one.
The normal and Gumbel probability distributions
Continue reading →High Variance Management
There is a math supplement to this post where I build some intuition on the different probability distributions involved. If you are interested, read that later.
Why variance matters
Continue reading →APIs as ladders
Developers have opinions on what a good API1 is, but rarely have a shared vocabulary to describe what makes them good. This essay puts forward one set of considerations (out of many) that we started using at Stripe in 2019 to discuss API design2. You can find some of these concepts interspersed in this excellent blogpost by Michelle Bu.
The hard part of an API is not to use it, but to learn it. After learning how the API works, typing out the commands is not hard. But when you first time you encounter an API, a million questions pop into your mind: What is this object for? Is there a parameter for that? Can the API do X? Learning requires effort, but the more the developer learns, the more problems they can solve. We can imagine the developers climbing a ladder where, for every step they take up the “learning ladder”3, the more problems they can solve.
Continue reading →