I’m more convinced than ever that the hardest part of engineering leadership is balancing shipping (short-term velocity) and technical foundation (long-term velocity). Here are a few things / rules of thumb I think about:

(a 🧵) 1/ Define a time-horizon where “long-term” projects will pay-off in terms of revenue or time saved across eng within X months of completion. For early stage companies X is probably 1-3 months and by the time you have >100 engineers you should start stretching it to 12+ months.

I promised threads about recruiting for the next week. Here's the first one on referrals. In growth/marketing speak: referrals are your organic growth, inbound is your brand, and outbound/sourcing is your ad spend. You want to growth-hack your referrals. Here's how. 1/n 2/ Referrals (people on your team referring candidates into your recruiting pipeline) is great because it scales with your org size. They also convert higher since one of their friends is trying to convince them to join, plus they are generally not interviewing at many companies.

So with everything that happened yesterday, I have some personal news... 🌴

A 🧵 After 4 years here, I’ve decided to stay at Plaid (and in SF) to grow the team and continue building the future of fintech. The news though is that I am doubling my team this year.

Going to celebrate by tweeting recruiting tips all week. Later today: how to encourage referrals!

Under-appreciated frustration of building an API product: feature adoption is much slower than for a UI product like Slack/Instagram. Even for your very satisfied customers.

Flip side: retention is much higher.

Here’s what I wish I’d known when I joined Plaid four years ago: 1/ If you have a UI product area, introducing a new feature or product is as easy as putting it in front of the user. You can email your customers, put a modal on startup (hi @onepeloton ), etc.

The user just clicks on the thing and voila they can use it and you get feedback.