More late-stage companies are switching from four-year vesting to one-year grants. Stripe, Lyft, and now Coinbase (blog.coinbase.com/how-coinbase-i…).
Seems like a good time to talk about why being an early startup employee is (used to be?) a much better deal than it might seem:
1. Picking winning startups is actually not *that* hard: benkuhn.net/vc-emh/ It's not *easy*, but some VCs, and TechCrunch award voters, do it regularly.
"If it's not hard then why aren't you rich?" Because plebs can't invest at those valuations, only name-brand VCs can.
("Why do name-brand VCs get a good deal?" Because many companies don't optimize very hard for valuation when fundraising. Instead they try to minimize distraction, risk of down rounds, etc. See post for a more fleshed-out argument.)
2. 4-year vesting stock grants are more valuable than a naïve calculation would suggest: benkuhn.net/optopt/
Briefly, this is because you can quit and move to a different company if it looks like the startup is doing badly.
The option of quitting is actually an option in the technical sense, and you can calculate its value using standard option-pricing math. If you do so, depending on your assumptions, the equity offer looks 30-100% more valuable than a naive expected-value calc would output.
Combine these, and you get a strategy of: pick the best-looking company, work 1-2y there, & if they're not a winner by then, repeat.
If you're as good as a TechCrunch audience member at picking startups, this gives you pretty good odds of making a good-VC-level return.
(Is this competitive with working at Big Tech? Hard to say—a lot depends on how good you are at picking startups, or at getting Big Tech to pay you a lot. It's been way better for me, but I got quite lucky!)
Anyway, this relies on 4y vesting to get enough mileage out of the winners to make it worthwhile. With annual grants, it's prob not worth it 😞
Understandable that Coinbase/Stripe/Lyft did this though, since nobody actually understood how to value the 4y grant (I sure didn't!)
This change is probably a Pareto improvement for Coinbase: they can offer a comp package with a higher "face value," while the actual cost to them is less because years 2-4 will be at a higher valuation. (Assuming number go up, of course.)
For that reason, I'd expect this to catch on, at least at places that are close to liquidity (+ hence have a more tangible expected-value for their equity).
I want to say "too bad for early employees," but I think most of us didn't realize what we were getting 😢
• • •
Missing some Tweet in this thread? You can try to
force a refresh
(“Outside view” = e.g. asking “what % of startups succeed?” and assuming that’s ~= your chance of success.)
In theory it seems obviously useful. In practice, it makes people underrate themselves and prematurely give up their ambition.
One problem is that finding the right comparison group is hard.
For instance, in one commonly-cited statistic that “90% of startups fail,” (national.biz/2019-small-bus…) “startup” meant all newly-started small businesses including eg groceries. Failure rates vary wildly by industry!
But it’s worse than that. Even if you knew the failure rate specifically of venture-funded tech startups, that leaves out a ton of important info. Consumer startups probably fail at a higher rate than B2B startups. Single-founder startups probably fail more than 2-founder ones.
A lot of managers (including me!) find it hard/scary to give critical feedback.
I realized recently that this is often downstream of a less obvious blindspot—giving people enough *positive* feedback! If you've done that, critical feedback "magically" becomes much less fraught.
Basically, the hard part of giving people critical feedback (at least for me) is worrying that it'll make them feel bad (as opposed to motivated to improve). The biggest thing that makes people feel bad is worrying that their manager thinks they overall suck at their job.
So you need to give positive feedback not just for things that are *surprisingly* awesome (which I think is many managers' default), but frequently enough that the positive:negative ratio accurately reflects how good they are at their job.
This is another great takeaway from last thread, which I *should* have learned from changing jobs, but actually took ~20 more cycles on the motivation roller coaster to realize.
For me, bad focus was ~always a response to circumstances, even when I wasn't consciously aware!
My first years at Wave, I repeated variants of the following ~monthly:
- notice I'm stressed/unfocused
- "huh, having an off day"
- go climbing, read books, etc.
- still stressed
- gripe to boss eg "accounting sucks"
- boss helps fix accounting problem
- ✨happiness returns✨
Eventually I started interpreting stress/unfocus as a sign, not that I was having a bad day, but that I was working ineffectively or on the wrong thing. Eg, I'd know I needed to be hiring faster, but kept getting distracted by other, less important, more urgent projects.
One thing that surprised me when I switched plans from "earn lots of $ and donate" to "build important things," is how much more productive I became.
I thought if I was earning the $ by doing intellectually interesting work I'd stay motivated. Turned out that wasn't true!
Actually, it was even worse—I *thought* I was motivated while I was doing plan A, and only when I switched did I even realize *how motivated it was possible to be.*
Several friends had this experience as well. Makes me wonder how many people are stuck in that state.
(For example, I never thought I'd be pumped enough about work to live for 1+ yr in a country where I didn't speak the language! Or to have the stamina to spend 20+hr/wk on the phone with an accounting firm. Or etc.)
People ask me for a lot of advice on what to do about technical debt. Here some things I’ve learned about how and when to prioritize fixing bad code:
1. Distinguish global vs local problems.
Local problems are things like a poorly-implemented module—it slows you down if working on that module, but is fine otherwise. Global problems are things like “we use database transactions wrong” that infect everything.
2. Fix local problems the next time they get in your way.
(i.e. trust that they’ll get solved eventually by a “make the change easy, then make the easy change” process.) Leave TODOs in the code, deprecate methods, etc. as breadcrumbs for anyone else who might want to fix.
I just finished *Creative Selection* by Ken Kocienda, which is largely the story of how he came to build the iPhone keyboard.
It’s a great example of how many twists and turns it can take to come up with something that seems so incredibly normal!
v1 started out looking like...
some wacko phone-keypad variant, because the developers were super worried about touch targets being small. The input method for this was: tap to get the top letter, swipe left/right to get the bottom letters.
Except instead of the letters being organized like a phone keyboard, they’re jumbled up. (Presumably to make sure that common letters were taps, not swipes? But that plus the gestures seems impossible to learn.)