Mason Jones

I’ve actually almost never worked at a company that wasn’t a startup. I've been in tech for an embarrassingly long time and sort of stumbled into the joy working at small companies early on, before the term “startup” was even commonly used. I was working for 10-20 person tech companies in San Francisco and discovered how much I like the flexibility. Oddly enough, I love the unpredictability of it too. So I've been among the first couple of Engineers at a long series of companies. More recently I kind of purposely took a step into slightly larger companies, like working at Credit Karma for a long time when we grew from 350 people to1600 people, then got acquired by Intuit and we definitely weren’t a startup anymore. It’s just the fun of never knowing where the journey will take you and the opportunities that come with that.

Personally, I need to believe in what the company is trying to do. I've always said I'm not interested in helping build another photo sharing app. I want to know that what we're building means something, and that if we're successful that people will care. That it will make a difference. That's the first thing because if you're not excited about what you're building—what you're trying to put in front of people—then that's what it's all about at a startup. Then it’s the people who are there and the opportunities to learn. I get bored easily, so if there’s not going to be an exciting new challenge coming up then I’ll start looking for one and that can get me in some trouble. So I love to see some exciting opportunities ahead.

When you're a really early company, you're probably not even going to have a super formal process around managing incidents because, like everything else that happens at a small startup, it's all hands on deck for anything important. So pretty much you get in an incident “room” and everyone's involved and that's great. But that can also kind of burn everyone out. So having some lightweight process early on is really critical, even if it's nothing more than having a rotation of who's going to be—not even “on call” necessarily—but who's going to be watching things and jumping into things first. And taking turns or sharing that responsibility where you can, because we all know that things can burn people out much more quickly than you expect.

‍

The second thing is how you're going to choose to learn from the incidents. If you're an early-stage company, you're going to have incidents. It's guaranteed 100%. If you're a big company you are too. But with the small ones, you especially need to expect that you're going to have incidents because you're moving fast, you're trying to build stuff, maybe you're getting a lot of new customers quickly and things are going to break more frequently. And that's okay, as long as you're prepared to learn from it and take the next step. So when there's an incident, do you just kind of fix it and go on with work as usual? Or, do you fix it, step back, and think “okay, how do we prevent this from happening again? What did we learn from this?”. Then you're going to grow together and make use of the opportunity.

‍

When you realize that everyone is doing things their own way, because they think they have to in order to make progress. I’ve been at companies where early on it was kind of a free for all — which can be ok when it’s a half dozen developers who know the product inside and out. But it’s going to start to stall out really fast as you grow and cause negative repercussions. Suddenly you’re at 30 or 40 engineers and there’s no foundation that helps people get up to speed. It becomes difficult to select tools that help everyone because nobody is thinking the same way. At some point a certain level of standardization becomes essential to accelerate everyone’s work.

It’s mostly weird experimental music, with a lot of Japanese bands. I got connected to the independent music scene in Japan years ago and started going there every year, playing shows and meeting bands. I ended up booking tours for bands over here in the US putting up their records and just building this bridge which was really really fun. These days I'm a little bit more active trying to just spend time doing my own music rather than the record label side of things, but it comes and goes. 
‍

Mason’s team at Zapier is hiring! Check out their careers page: Zapier.com/jobs.