Determining bets, using customer insights to pivot, and gaining developer buy in & trust w/ Tomas Reimers @ Graphite

Speaker A: I think the question is, would I rather stay at Facebook for n more years than 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 1000%. 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, uh, 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 at an early stage, but especially as you start to get up there, especially once you know how to build and 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, well, 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 B: 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.

Speaker A: I'm doing great.

Speaker B: 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?

Speaker A: 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. Super. So the same way with Superhuman you can log into 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 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 and Meryl have been friends for well over a decade now. Um, 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 regret minimization as my decision making framework of last resort to say, 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 development faster. That's sort of 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 and we're like, let's look at like the life cycle of like a unit of code. This pull request, where does it spend time? And the truth was, even back then, you spent 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 know, you kind of like 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, like, we should build tools for that because that's how we're going to start to see, uh, your developers along that, that journey went pretty well. Along that journey, I hired two of my old teammates from Facebook. Very quickly we realized we missed Facebook's code review tools. Uh, we built it for ourselves. About nine months after that, we ended up with a lot of our old teammates who would leave Facebook, then meta, uh, go on to other startups, be like, hey, code review out here sucks. And we'd be like, it does suck. And they're like, how do you fix it? And we're like, we built the thing. And they're like, can I buy that thing? And so about nine months later, um, we were eventually convinced to Try this. So we launched uh, a wait list. We had a huge amount of signups, we pivoted and then we've been building that ever since. Today we support code review for some of the largest companies in the world. So we support from everyone from Shopify to Notion to Figma to ramp a, uh, joke I often like to tell my friends is, uh, name is Silicon Valley company and we probably support them.

Speaker B: I want to go back to the relationship with your co founders because this declarative of hey, we are starting a company together is a different conversation than should we start a company together. So I want to get into like, is there a moment that you remember from your time with them that was like, oh, this is a conversation that signals that this is a must do. Do you remember a time or maybe is it a series of memories where it was like the impression of like, wow, this works so well that it's like a no brainer that at some point we're going to create at this

Speaker A: level together, I think in the best way possible. I don't think we ever had that questioning like the idea of like, we're really passionate in doing this. We're friends, we've all known each other for a long time, we're really interested in it in many ways. It just felt natural from the start and that's kind of the best way to do it. There wasn't an uh, intensive founder dating process. We were like, well, maybe you, maybe not you. It was more like, okay, I, that this would make sense to work on together. What needs to happen. I think the bigger questions we had more were like, are you going to break up with your job? You know, like, is this the thing we feel so passionately about, that we're going to do it and you kind of make this pact together of like, all right, we're all going to quit. It wasn't the exact same day, but it was within the same like two week period. And it was like, we're all going to quit. We're all going to give notice together and we're all going to quit and we're all going to take the leap into the unknown together. And that was almost the harder part of it was the uh, going from, okay, this is the thing we want to do because I think a lot of people experience the uh, oh, I'd like to flirt with the idea of starting a company but I think taking the leap is one of the hardest things that you can actually do.

Speaker B: Yeah, I want to dig into that part because breaking up with your Job. Like you said, that is the moment where you walk up to the cliff of, are we going to do it or not? And like you said, I mean, the whole reason why this show exists is because that leap is so hard. The breakup with your job moment. What was the conversation like between you three when there was like, okay, yeah, this is a no brainer.

Speaker A: So I think the three of us had this idea of where we want to start a company together. We had an idea of this space. We had an idea of like, the idea, uh, QA is this interesting space. We'd gotten behind the market, we'd gotten behind the. There's something for here we can build. What's really funny is the things that convinced me to do that leap are none of the things I do today. You know, like, it wasn't like, oh, we're really validating code review. I almost wish it was. And we can get. Well, we should get to that. Of why I think pivots are so hard is because you then need to do this again. For me at least, it was like, I did a great job at Facebook. I worked with teammates whom I really, really love. I still keep in touch with most of them today. And I had to make the decision of, am I willing to jump into the unknown with my friends here? At some point you just got to do it. I don't have a better answer for that. Of, you have to try it. And I think that I had two pieces of advice that really stuck with me. One came from an old friend of mine. He went on to sign a company. They went until the series C they actually sold recently. And his advice was, let's actually really think about this. I realize it's a really scary thing to think around the what if of your job. Let's break it out by cases. So, like, what happens if you quit your job and you come back within three months? And the really honest answer is they'll probably just give you back the job. If you leave for a month and you come back a month later and like, I really messed, uh, up, I want my job back, they'll give it to you and you'll probably go right back to the same team working on the same things. Uh, especially if they like having you. The zero to three month case, don't worry about it. The three to nine month case isn't that bad at all because they'll still probably take you back, but you'll just regress your career by three to nine months, which is like, okay, that's a meaningful career hit. You'll miss a perf cycle. But in the long arc of Life, in the 50 years of career you have, it does not matter, full stop. And so that one wasn't really such a bad case either. There's a one year to two year mark. I think that's the worst case for you to get stuck. Because what that means is the company didn't work and maybe you're going back to your old job and maybe they do or don't want you and now you're a year out. Maybe you have to find a different job because the position changed because the team changed. Kind of sucks, okay? And then there's the two plus case where you will probably come back at a higher level. Because if you make a startup that makes it for more than two years, what that actually means is that you did it in a real way. Maybe you got to the A and then you sold, or maybe you sold at the seed, or maybe you did something, but you built something super real. And people are probably willing to give you the credit for that. And so I think when you actually look at the ecosystem, a big part of the reason why we see young people, we're willing to take the leap more often than more senior people is because there's less to lose. You'll take the three to six months. You probably don't yet have kids to support, you probably don't yet have the other obligations that start to exist as you get older. You can just take the shot and you're still kind of fresh at your job. And so there's not that much in lost wages or vesting or anything that you're giving up. And it gets harder as you get older. So that was thought number one, which is just like, if you break it up by cases, you're pretty good. What you're really defending against is this really narrow window actually of one to two years where you just need to exit before or exit after and in either case you're actually going to be better. And that's the downside.

Speaker B: I love this breakdown. This is the best breakdown of the logical framework of this leap ever.

Speaker A: So that was idea number one that was given to me. And you know what was crazy? I remember when I, uh, gave notice, it was a whole thing. I had to talk to my director because they really want to keep me. And I remember this, I was in a room with the whiteboard and he's like, why would you leave? And I'm like, let me explain it to you logically. And then I drew this out and Then he was like, I mean this does make sense. And I'm like, that's it. There's not a deeper fight. It's logical to you too. And so that was thought number one. Thought number two was regret minimization. At the time I left to start this company, I was really early in my career. I was 25. And I remember my thinking being like, well, I probably want to start a company sometime before I have kids. And let's say that I want to have kids by like 33. Just to pick a number in that, to put a number in there. And starting a startup, if you're going to do it, you should probably have at least five years there. By the way, that has actually been one of the biggest lies I've realized. I think that startups take people will tell you five to 10 years. My belief is now assuming you're going for a good case, you're dealing with 8 to 12 years is the number I now tell friends. And so then the logic became like, okay, I know I will regret it if I never take the leap, if I never try it out. Mostly just from a diversity of life experience perspective. I really want to try something here. I think I could do it. I think building a company with friends is a journey that teaches you a lot about yourself. And so I want to take the leap. I had the idea of, okay, well, I really have eight years I'm playing with here. And so I think the question is, would I rather stay at Facebook for n more years than 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 1000%. 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, uh, 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 like career ladder that matters so much at an early stage. But especially as you start to get up there, especially once you know how to build and architect software and build systems that like 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 well, I'd probably just take the leap then take what I learned and do the next thing. I'm super glad I did it, it worked out. I would recommend it to a lot of people. I think it's a very fun journey if you have the uh, right companions. I think doing it alone. I still don't get how people do that. It seems super scary to be a solo first time founder.

Speaker B: This is the best case for why you should take the leap right now. Breaking it down by people, by regret, minimization and by the logical breakdown of the worst case scenario. I think that's all of the motivation people need to say yes to this. I think it's zoom in on ideation here because there's one particular part you mentioned that I think is so interesting and what I'm curious to learn about is what the conversation looked like then. And then if you were to revisit this now or when you are revisiting this in terms of products and things right now, how you think about it. So it was this question that you asked around where, like the unit of code, where do people spend time? And so one of the meta questions that you and I were talking about that you all asked at the beginning was like, how is software being built right now and how is it changing? Can you talk a little bit more about that conversation and how you were breaking down? Well, like why you focused in on that particular type of question, how you broke it down. And then the second half of this would be like, how would you do that now?

Speaker A: So how did we get there? I think we had a lot of conversations, I think we had a lot of ideas on maybe how to start companies. Two of us. Uh, the way we actually met in college was we were part of Rough Draft Ventures, which is like Dorm Room Fund, if you're familiar with either of them. It's a student run vc. And so we had our own exposure to startups and we had our own idea about how to start startups. We believe that there is economic value in speeding up code. Seems reasonable. We think that there is a purchaser. There's a pretty well trodden path of like, if this tool makes it faster to deliver, deliver code, we will just pay for it as a company. And so there isn't really uh, that kind of question. At the time we were looking for what is an industry that isn't going to be super competitive. There's this whole framework. I'm sure it's popular among some listeners of Blue Ocean, Red Ocean. Uh, the idea is Blue Ocean, there's no one in it. Red Ocean is full of sharks kind of all trying to eat the same dollars. In today's world, I'd say that coding agents are super red Ocean, there's 15,000 startups all trying to do that. And there's a lot of Blue Ocean areas that no one works in. At the time we were looking for something Blue Ocean, I think I was first time found. We've reflected on this a lot. I think we were really scared of competition. I actually think that was a mistake. My new framework for Blue Ocean and Red Ocean, Red Ocean is a statement of I need to outcompete those people. Blue Ocean is a statement of I am somehow smarter than everyone else that I've seen this opportunity that no one else has seen. And so I'm actually much more scared of Blue Ocean now than I used to be. Red Ocean company is where you're like, oh, these people do this, and I'm just going to do it better. It feels a lot more stable to me. And something that you can take to the bank. We had this idea of what's an area we look at. What are these sleepy areas that we think that, uh, technology could help. QA was one of them for us. It's a really interesting one. And then the framework of the pull request, I think that just came to us as we were starting to think ground what are the different areas we could engage and speed it up. At some point, someone came up with the idea of, let's actually just list all the stages software goes through before it releases. And we went from, well, you ideate, then you write out, uh, product spec, then you maybe create an architecture doc, then you write a pull request, probably looped through this part a few times, then you review the pull request, then you merge, then you maybe merge the pull request, then you do qa, then you deploy the thing, then you, uh, iterate on it. I can list out the whole life cycle at this point, but we were really looking at that and being like, which of these parts are sleepy, don't have a ton of innovation, and we think we could loosely get someone to pay for. One of my reflections on the whole process, you asked on sort of what would I do differently. So one is I'd look for competition because the more I've done startups, the more you realize you can look at a startup and be like, wow, everything's super buttoned up from the outside. How could someone possibly compete with them? Um, and having been on the inside, everything's on Fire. And it's always chaos. It's actually not that hard to fight with a startup. You probably can do it. Uh, the question is just, do you have the appetite to do it? The thing, uh, I would prioritize more is I was recently. I'm going to give such a nerdy answer. I was recently rereading Paul Graham's essays and one of the things that struck me was the technologies of the day are the ingredients that startups are built with. And I'm actually going to take sort of like one level more introspection there, which is a big part of what you try to answer with the startup is the why now? Why would this exist today and it couldn't exist yesterday or the day before? And the answer that no one had thought about it is a relatively pretty weak answer. Yeah, maybe there's a ton of people trying to start startups every day, so why is this suddenly possible? And I think the best startups have some aspect of like, oh, there was this societal change, or there was this legal change, or there was this economic change, or there was this technical change. And so I think one of the things I would actually spend a lot more time with in the future is what are things that have changed recently? Sort of like intersection with what are the areas I'm super interested in. As I said before, I think one of my reflections was previously people, uh, when I talked to people around how the startups go is, I don't know, five years in a short case, medium case maybe, and ten years at most. And I'm like, if it's successful, you're just going to spend two decades of your life there. A, uh, framework I've now started to give to a lot of friends who start to think around startups is if you actually look at your career, you have about 40 to 50 useful years that you're really in the thick of things. You can probably stay up late nights and put in work on weekends. And if you actually break down, how long do these really long efforts take? About six years. Okay, cool. That means you're going to get seven to eight bets in your career. Is this one of the, uh, seven or eight bets you would spend your career, um, on? Seriously? And if it takes 20 years, you get three. Is this one of the three bets you want to spend your life on? Because I think a lot of people, I hear a lot of friends who are like, yeah, the startup I really want to start is better HR tools for this. And I get that and I appreciate that. Is that the thing you're going to be super passionate about. Because if it's not, what's going to end up happening is you're going to wake up being like, how do we do, uh, receivables, automation for accounting? And don't get me wrong, there's a ton of money there. People would love to pay you good money for that. Uh, but are you personally going to wake up every day when you have people quitting on you, HR violations happening? Some competitor that's raised more money than you and is now poaching your employees? Is this the thing you're going to wake up and do?

Speaker B: I'm so happy about these particular frameworks for expediency. I'm going to zoom into a separate topic. You gave us a pretty good high level overview of some of the specific pivots. And one of the nuances I want to get into is this question of if sales isn't working, am I bad at sales or is it product market fit and working through that?

Speaker A: Oh, uh, my gosh.

Speaker B: Because the people listening to this, like, this is probably their first foray into either founder led sales or building a sales function. And you know, for me, I always default to like, I'm just so bad at this. Like, this is 100% my fault. But that may not necessarily always be the case. So, like, this was a big story for you. Can you bring us into what did this look like and how do we collapse that or deconstruct that a little bit?

Speaker A: This is a question that every founder I know contends with. So in the first three months of our journey, there were two books that, uh, I told someone would be like, oh, have you read? And they'd be like, seriously, you and your founders need to stop what you're doing and just take the day to read this book. Those two books are the MOM Test Strong recommend and Founding Sales Strong recommend as well. And so, uh, the Mom Test talks around how to do customer validation. If you have not read that book, I would stop this podcast and just go read that book. It's an incredible book. I give it to every new hire still, especially people who are joining our product team or thinking around what we should be building. Founding Sales is much more like how to run a sales team. I think it's really important to get knowledge to go into a startup with. I do not think you need to apply it all on day zero. I am, um, increasingly convinced that first startup, your first few sales should be PMF led. What you should have is you should be able to go to someone and be like, hey, this is the thing we have. Are you guys interested? Is this the thing that you would use? Let's get away even from buying it. Is this a thing that you think someone would want to use? And if you're, as an enterprise, if you're in B2B SaaS, eventually the conversation of money is going to come up. Why? It's because that's how things get through security and finance and legal and procurement. They're going to be like, yeah, and what do we pay you for this? And then you're going to come up with an answer, that's great, Cool. That's how your first sale should happen. If you are feeling. And we felt this, we've pivoted three times as a company. If you were feeling like, oh, I have to really convince people to use this software and I haven't found anyone who just wants to use it, but I have to convince everyone of this. There's something missing. Uh, I'm just going to tell you that I think you recognize PMF when you have it. That is not pmf. I'm here to tell you that the place where this gets conflated is too many founders bringing sales too late. We waited to have our first, I think, 2 million in sales before we even brought anyone into sales. I think that was probably too late in retrospect. A lot of people say a million. My personal benchmark would be 250k to 500k. I'd probably start to bring on your first sales hire. Not they don't even have to be a traditional sales hire, but someone whose primary function is going to be selling what you have built to other people. I would start by asking if you're pre 250k. I would start by asking like, okay, how can we start retooling the product? Because it should feel different. Right? And people will come up with all sorts of excuses. And it's really hard to, uh, introspect into your own product and be like, maybe your baby is ugly. Like, that's kind of the conclusion you need to bring yourself to. Of like, yeah, why does no one want this? Like, what's going on here? And I think you have to really hold the market as the objective measuring stick there. If you're past 250k, 500k, and you're like, should I do sales? Yes, definitively, yes. Go figure out your first sales hire. Figuring out your first sales hire can be tough. There's a whole school of thought there. But that's kind of the Fork in the road.

Speaker B: So for you, like what were the signals that helped you identify it was actually a product market fit issue versus our ability to sell that specific product. The three pivots you laid out some then like QA tool people loved, but there were no sales. Um, and then all of a sudden you know, you have this massive wait list for they have come up. How did you recognize it was sales vs product market fit? What were some of the things in hindsight that were pretty, the clear signals you were looking at?

Speaker A: I wish I could pretend to be smart enough to say that we figured out ahead of time. I think almost in all instances it was figured out sort of like post hoc and we were like, oh, this is what it should feel like. Which is an aside here. If you're thinking about uh, if you're currently working thing and you're thinking about starting a startup, I would highly recommend you go join a startup first. Go join something in the seed to series B range. Probably because you will never feel what PMF feels like unless you've been in it. And it's so hard when you're at uh, one of those well oiled machines where you're so distinct from the customers to actually understand what this looks like. So we had three pivots. So we started with qa. QA was awesome. The QA people loved it. The challenge we had was no one wanted to pay money for it. And I remember having such an explicit conversation with the CTO of a Fortune 500 company where I was like, you have a ton of QA people and they love what we're building and now you will pay us for it. And they're like no. And I'm like, but why? We feed them um, up by 30% with that number, we're saving you n dollars. And they're like, I hear your argument and I have no desire to invest in qa. And we're like, why? And they're like, well, web doesn't have qa. That's the future I want to buy into. I think one of the things I've learned, uh, I was recently having dinner with Scott Belsky from Now A24. He was the former CTO of Adobe. And something that he says about movies, which I think applies to startups, is people need to want to love your movie. And what he meant by that was there's a whole meta story that happens in terms of how did this come together, where did this IP come from, who's writing it, who's the studio behind it? If you Hate the person producing the movie, you're not going to love the movie. It doesn't matter how good the movie is. And I think the same is true of software, uh, where if you hate the area you're buying software for, it's going to be really hard to sell for, no matter how good the software is. QA fell into that bucket where a lot of organizations didn't really want to buy into the and we're going to modernize qa. I think right now there's a lot of people buying into this idea of AI is going to change everything and they want to love those products and those products are coming to market and they do love them because they're great products and they fit into a narrative they already have in their head. QA was never that. That was a pivot because we just had really honest conversations with the customers who were like, I don't care how good you make it, I'm not going to buy this. And that was a sign for us of something is fundamentally broken. From there, we pivoted into mobile, um, deployment software. For those of you who have built mobile apps, you know that there's a lot of going to call it nonsense you have to do when you submit to the app stores, be it Google or Apple. We were under the impression there's a lot of open source software that helps automate a lot of parts of that. We were under the impression we could create a hosting solution. We started to build that. It was awesome. We actually had some pretty big sales, um, I don't think I can name any other customers there, but let's say that we had like hundreds of Ks of sales. Um, we never crossed a million, but we did pretty well for a seed stage company back in 2021 at that point the pivot happened when we released the first version of Graphite. So we released this waitlist. We released a CLI tool to uh, help you manage pull requests more in the style of a Google or Facebook. The core feature was stacking. For those of you who that word makes sense. And what happened suddenly was we had all of these users showing up from everywhere. We had people coming from the waitlist, from Datadog, from Snowflake, from Toyota, from Sephora, from Rex, from Ramp, from uh, whatever. And we're like, holy crap. We didn't even realize all these people would just come and they were just finding us and they would be like, oh my God, I hear you have this. I want to figure out how. I don't know if my company can use it, but I'd love to figure how they can. And it was just a night and day difference from what we were selling before. It wasn't as if we'd looked at the previous thing. We were like, we don't have pmf. And then we pivoted. We kind of pivoted because we had all these customers trying to pull it out of our hands. And then we were like, maybe we should try it. And then once we started doing that, what we said was, okay, we're not going to sunset the other product. Let's put it on pause for like two months and see how far we can make it and then we'll make a call. And I think at the end of those two months, it was just so clear to everyone in the room, like, this is what PMF M feels like.

Speaker B: One of the phrases that you and I talked about was developers don't want to be sold to, they want to be taught. And this rocked my world. So I want to get into this as like a go to market philosophy or paradigm and what that looks like at different levels. Because I think that this is so true for anybody who's building in sort of like this dev tool space. Like that ethos matters so much and I can't overstate that enough. So bring us into that, bring us into that paradigm and help us deconstructure this insight and how this applies to, uh, go to market.

Speaker A: So it's hard. So I've only ever worked in DevTools, so it's hard for me to give you the counterfactual of what it's like. I can only tell you what people have told me who have come from more traditional marketing, sales or go to market roles and sort of come into dev tools. And the general sentiment is like, it's uh, upside down my tier because I think that developers are so, so, so first touch allergic to anything that feels like marketing or sales. If you are putting up a billboard to a developer, I think you need to be very cautious to not be like the voice of authority or trying to convince them that like, hey, if you use X you should use Y because they kind of just disc as like that doesn't make any sense. I think instead developers really want the ethos there is. They really want to understand. Right. They don't want to be told like, ah, uh, yes, like I think around like, I don't know, laundry, laundry detergent is my like canonical like old style sales example of oh, uh, if you want like brighter whites, you should use whatever that's not what developers want. What developers want to know is like, but why does this work? Why is this better? And so much of my time, uh, selling to developers is just being like, I'm a level with you. You. Here's what we do, here's exactly why it works, here's why we think, here's the data. We have to think it's better. What we don't do is we don't try to draw conclusions for you. We don't try to say, and therefore it's going to make you faster. Instead of, generally, when we get into ROI calculations, people love to talk to us around, how much faster did it make our developers? And the number is about 30 to 300% depending on the size of your org. 30 is the worst case scenario. And so I start there and what I can't tell you is graphite is going to make you better. What I can tell you is that for other companies of your scale, graphite increased their code output, measured either by PRs or lines of code, by about 30%. Insofar as that has value to you, we should talk about that. If that's totally meaningless to you or you have other priorities, that's totally fine. For any engineering organization, 30% is a huge number. If you have 100 engineers and I tell you like, yeah, buying Graphite at, uh, $40 a seat is the same as hiring 30 more engineers at 200k a year. You're like, uh, yeah, I should buy graphite. That's a really logical conclusion. And so, uh, for developers specifically, so much of what we do is nothing to do with sort of the classic sales things of how do we position our product in the right advertising, media and so much more. How do we just teach you the thing that we're building and let you draw those conclusions?

Speaker B: I want to sort of look at how this gets demonstrated in two different phases. So applying this to the earliest stages, how do you sort of construct some of those early conversations in a way that really demonstrates this? And then the other part is like, how do you keep the spirit alive as graphite grows and matures and expands and continues to develop more sophisticated use cases, uh, and other areas, I think,

Speaker A: okay, so how you apply in the early stages for us was a, uh, line we would often use was, I don't want you to think about us as a company selling you software. I want you to think about us like your developer experience team or your developer platform team, or your developer tools team. Like we are here as a cluster of engineers who are probably could have worked at your company in a different world and we're instead building this tool for you. Please bring us all your complaints, bring us your concerns, bring us the things that aren't working for you. Uh, one of the things we do in early days was literally set up a Slack connect channel so people could just jump in and be like, hey, I noticed you do X. Why do you do X instead of Y? And you can really level with them and have these conversations on like, oh, we do that because blank and the same in engineering it's usually if two reasonable people disagree, one of you just has context, the other one doesn't. And so, so much of that is finding the context that's missing and just providing that to the other person. How does this grow and scale into like a broader uh, EPD team, uh, or into a broader sort of like GTM team? A lot of it is what the heart, what's at the heart of like brand and marketing as you sell to developers, I think what you should not sell to developers is magic. I think that developers want to know, want to be able to peer inside the box. You're fundamentally selling to a group of people who probably when they were younger, like disassembled computers for Fox, you know, because they'd like rejected the idea that it was just this magic box. You want to be able to provide that for them or have the way that they can peek inside. I think, uh, beyond that, as you start to think around developers, you get into this idea of wanting to feel like in the in crowd, like we're these sed. As a developer, SED is one who writes still a ton of code every day and who used to just be a professional developer. We're the people who like have all these weird memes internally of like the statement hello world means something totally different to us than it does to any normal human human. And that's just the tip of the iceberg. Being able to speak to that and assert like, hey, I'm not a marketing person writing this, but I'm a developer who's sharing your love and passion of what you do with that is something really powerful. I said earlier that uh, the marketing uh, to developers is like upside down land in a weird way. It's the same set of high level principles that you would apply to any other industry. The reason I think it's upside down land is because what the conclusions that those principles draw you to is very different than you do in other industries. And I think in other industries, when you start to think around m How to establish authority with someone. I think as a developer, it's actually almost to be differential. The best developers can sit down and be like, oh, here's the 15 things you can do, here's how you think around each of them. And then here's why I drove this conclusion, maybe not why you would do it. I think the worst developers are like, this is the best conclusion. And I, uh, think that that carries through even into the marketing.

Speaker B: I am thinking about so many other ways that this shows up within sort of go to market. To me, this makes me believe why demo days have so much cultural clout. It's like, because this is so much of watch me build and understand how this works and why I'm excited about this particular pathway. And then it also makes me think about like some of the most effective marketing right now are sort of the builders or the founding teams that are like, hey, watch me build this thing. And like that's the marketing is like, here's how I built all of this. It's like sort of the marketing is showing the behind the scenes of building. And the documentation of that I think is so interesting.

Speaker A: I think we're going into this whole area right now where so much of developer marketing has been like someone standing in front of a camera in a way that, that feels like they just did it today, you know, like they're not high production like activities. And I think that sort of like authenticity and genuineness goes a lot farther with developers than it does maybe with other audiences.

Speaker B: And I'm even reflecting on. So, you know, one of the things we'll do is we'll do different, like through elc, we have different partner programs and partner dinners. And similar to this philosophy and why I think I resonate with it so much is because the most successful partners I've seen in these, which are, you know, oftentimes like in the developer tool space or infrastructure space or like selling to VPs of engineering or CTOs is like the partners that are in that conversation that are, that are doing what you're talking about, which is like trying, seeking to understand like what somebody is dealing with in that situation. And then not necessarily selling to, but then also demonstrating, oh, here's kind of what we did, why we did it, and why this is particularly interesting to us. And I don't know if that, uh, maybe that's useful for you. I don't know. I'd be curious to hear your perspective or opinions on it. It's like those conversations that are like deferential, consultative, curious and generous with learnings I, uh, think are really, really interesting.

Speaker A: I think the Trusted Advisor framework is very much what you're doing in developer sales. You're figuring out what makes sense here. And also this is again from the perspective who's only ever worked in developer tools. I believe maybe some more of this translates than I realize. These are just my learnings in that space.

Speaker B: This is a big inflection point for graphite. I mean right now there's the cursor. I don't. Are we allowed to public. Am I allowed to publicly imagine.

Speaker A: Yeah, no, no, it's done, it's closed.

Speaker B: So the cursor acquisition and my walk up here is not necessarily like the prettiest. But what I'm curious about is like, you know, here you are, this moment's happening and forward looking, like where is software development going from here? Like when you start to think about like all of the things that happened past this moment, like, you know, where are things going from here? What are you excited about? What are you looking Forward to?

Speaker A: My 1 sentence answer to that is I think that software development is alive and well. I think that coding will start to take a backseat. And so that's, that's my take on um, Like I think before there was this weirdity where like, like every software developer in order to develop software had to be a really good coder as well. I think the art of coding may start to disappear as the machines just get really good at that. I think the principles of software development in terms of what should be extensible, what are we building for scale? What's not building for scale? How do we think around pms? How ah, do we think around abstracting out product infrastructure? Those are principles that are hopefully going to last us the test of time. Part of the reason why we sold to Cursor was as we got to know that team better and better, we realized we had the same mission, which at the end of the day is to try and automate large parts of software engineering. They have done literally the best job imaginable with the creation of software. And I think we've taken a pretty good stab at uh, sort of review, merge and sharing of code, which is the other outer loop half of software. And we really thought that by sort of bringing those two together we'd be able to tell the full story a lot more efficiently.

Speaker B: Amazing. Tomas, we've got some rapid fire questions if you're ready to jump in.

Speaker A: Let's do it.

Speaker B: Question number one, what are you reading or listening to right now?

Speaker A: I just finished a book, so I just finished Thinking in Bets. Um, it's my second read through it. I'm a big believer in rereading books. I love rereading them at different points in the startup journey. I think that every time I come back to it, I find myself getting something else out of it. And so Thinking Bets was a book I had read, uh, before starting a company, and reading it again after starting a company was just a very different experience in a cool way.

Speaker B: That's fantastic. Question number two. Founder resources that have been most helpful for you.

Speaker A: The mom test, founding sales. Both of them are incredible. I'd highly recommend going there. Other than that, I'd really recommend going through your VCs. Go find other founders. I cannot stress enough how important it is to have other founders who are specifically one stage ahead of you. For so many questions, we found when we hire a first salesperson, when we had to deal with the first time we had to part ways with someone, when we had to, uh, issue our first offer, even when we had to think about pivoting, having one founder who's even just one stage ahead of you is so valuable to be like, oh, yeah, I did that. Here's some advice I can pass on. And so look for community. Often people find it through their investor networks, but there's a thousand ways to find it.

Speaker B: Love it. A trend that you're seeing or following that's interesting or hasn't hit the mainstream yet.

Speaker A: I have a handful of friends, uh, or other people who have given, uh, Claude code specifically access to like Slack and started to use it for coaching and started to say, hey, read all of my messages and how could I be better as a coworker, uh, or boss or whatever? I think there's something really interesting how we communicate there that's going to change over the next few years. I don't know what it is.

Speaker B: I have a recommendation of a company to take a peek at. They're tapping into that space in an interesting way. It's called Ren R E N Person Building it is Jonathan Raymond. He's been a longtime executive coach for tech executives and stuff and is taking a really interesting approach to this in that the AI tool's role should not be necessarily ingesting information, summarizing and then giving you feedback, but rather putting you into a position of human interaction. So empowering you to go and have that conversation, helping you tap into some of those things, and helping prepare you for those types of conversations that either improve performance, improve outcomes, improve relationships, some of the more cultural and performance related things. I'm a huge fan, uh, of it and I think you're so right. There is this sort of copilot, how to improve your effectiveness as a leader or operator is a really interesting space.

Speaker A: And to make it not a lightning question, the thing I'm looking at is the rubber duck that talks back. I think one of the things I'm watching people use AI for is they're like, hey, I'm about to send this really, I don't know, emotionally charged, slack message. And the AI can be like, I hear you. Don't send it. Let's maybe edit it these ways. And that can become even more powerful when it has access to your past history and context too.

Speaker B: Love it. Last question. Is there a quote or mantra you live by or a quote that's resonating with you right now?

Speaker A: Now I'm a huge framework person. Not because I think that their, uh, frameworks are like the end all, be all, but because I think they are really concise and pithy ways to communicate shared ideas with each other. There's something mimetic about them. The one that has stuck with me most recently is the job of any leader is to create urgency, clarity and optimism in every meeting. Those urgency, clarity, optimism is something I find myself repeating right now a lot to leaders at graphite of like, hey, did we create urgency, clarity and optimism? Awesome.

Speaker B: Amazing, Tomas. Everything from regret, minimization bets, don't be afraid of the competition, the rational case for doing it and making the leap and everything from the right ways to go to market, how to determine sales, if it's sales or pmf. What an incredible conversation. Thank you so much for just exporting all of the frameworks that have shaped a lot of your founder journey. So it really means a lot. Thank you.

Speaker A: Absolutely. Thank you for having me.

Speaker B: Again, if you're listening to this and you're wondering how can I get connect with other engineering leaders in my city, Pull up your phone right now and go to elc dot community. Click our chapters page. You can see that on the menu on the left. Find your local chapter and click Join. We're hosting virtual and in person events all the time and this is the best way to help you get involved, expand your network in your city and support your leadership and career growth. So pull up your phone, head to ELC.community join your local chapter and go get involved. A huge thank you to all of our local leaders who make community happen and thank you for listening to the Engineering Leadership Podcast.