Determining bets, using customer insights to pivot, and gaining developer buy-in & trust w/ Tomas Reimers #264

**SPEAKER_1** (0:00)
This episode is brought to you by Sadero. If your team runs Kubernetes, chances are upgrades can feel risky. That's what the TELUS platform is for. It's built on immutable, minimal OS designed for Kubernetes. Immutable means clusters cannot drift, so they stay identical and upgrades are a non-event. Minimal means there is almost nothing to attack. 50 binaries, no shell, no SSH, so it's secured by default. Upgrades get boring, security gets boring, and that's exactly the point. Check it out at siderolabs.com. That's S-I-D-E-R-O, labs.com.

**Tomas Reimers** (0:33)
I think the question is, would I rather stay at Facebook for 10 more years, then take the leap? Or would I rather take the leap and then maybe go to a job after that? And my thought was, I think I'd rather do it now. Mostly because I don't actually think the skills I'm learning anymore are making me any better at starting a company. And for what it's worth, I stand by that 1,000%. The skills at a big company and the skills at a startup, there are some amount that I think are really valuable overlap. And for what it's worth, if you are a new grad listening to this, I actually still think a big company might be the best for you. Simply because they can invest in the kind of mentorship and career ladder that matters so much in an early stage. Especially as you start to get up there, especially once you know how to build an architect software and build systems that scale and stand on their own. I think a lot of what you learn beyond that isn't actually that applicable to seed stage companies in particular. In that case, I was like, I'd probably just take the leap, then take what I learned and do the next thing. I'm super glad I did it.

**SPEAKER_3** (1:28)
Welcome to Engineering Founders, the show for engineering leaders making the daring leap to start their own company. Tomas, it's Friday. How are you doing? Welcome to the show. Thanks for being here.

**Tomas Reimers** (1:37)
I'm doing great.

**SPEAKER_3** (1:38)
I love it. To frame some context, we've kind of lightly talked about some ideas around product market fit, go to market, and the growth journey behind Graphite. I think maybe the natural place to start here is to kick off from the beginning. So why don't you bring us in, where did this all begin?

**Tomas Reimers** (1:51)
We started Graphite just about six years ago. For those of you that don't know, Graphite is a code review platform. You can think about us like Superhuman for GitHub. So the same way with Superhuman, you can log in to Gmail, you then have a better client to read and write email. With Graphite, you log in with GitHub, you have a better client to read, write, and merge full requests. That's very much where we're focused. We started the company about six years ago. We did not start as a code review platform at all. So before this, I was at Facebook. I was working on a developer platform over there. The way this started was I had two friends from college. So Greg Merrill and I, those are the three co-founders. We all went to school together. They reached out and were like, We are going to start a company together. We would love for you to join us. And that honestly led to a lot of stress. I was having a great time at Facebook. I really love my team there. They felt like friends and family. And to be like, Okay, I'm going to jump ship was a really, really scary moment. But I think at the end of the day, what really convinced me was like, Greg Merrill had been friends for over a decade now.
We're approaching close on two decades. And the idea of these two built something that went really well. I think I'd really regret it. And so in these moments, I've often looked at regretmentization as my decision-making framework of last resort to say like, okay, yeah, I think I would really miss it if this went somewhere as it did. And so we started there. We started working in tools for QA developers. We started with the thesis of we want to make software to run faster. That's just the bias that all three of us come from. And we started by looking at a lot of places that people normally look. This was pre-AI, so this is 2020 And one of the ways which was most helpful for us was we flipped the question on its head. We're like, let's look at the life cycle of a unit of code, this pull request. Where does it spend time? And the truth was, even back then, you spend shockingly little of the time writing the pull request. You spend a lot of the time reviewing it. You spend a lot of time waiting on review. You spend a hell of a lot of time in QA. And if you've experienced the QA team before, you hand off QA. You give them a script of, here are things that we need to test. And you see what happens. And so we started by saying, we should build tools for that. Because that's how we're going to start to speak up developers.