Scaling Startups and Navigating Product-Market Fit with Emre Baran

Ryan Burgess
before we dive in, we have a quick word from our sponsor. Hey, listeners, have you heard of Infinite Red? They're a powerhouse in the React Native world, and we're excited to have them as a sponsor of this episode. Since 2015 they've built over 75 apps for companies ranging from startups to global brands. Infinite Red's team of senior developers are the experts you need to build your next React Native app. They're not just about delivering amazing products. They also empower your team by working with your team to share their knowledge, plus they're deeply involved in the community, hosting the chain react conference to over 400 developers and producing the popular React Native radio podcast. If your company needs a React Native partner, look no further than Infinite Red. Check them out at Infinite.red/FrontEndHH.

Ryan Burgess
on this episode of Front End happy hour, I'm sitting down with Emory Baron, co founder and CEO of cerbos, with over 20 years of experience in the tech industry. Emory's journey spans from building Turkey's largest social network to his impactful work he's done at Google. Whether you're an aspiring entrepreneur, a seasoned engineer, or someone just trying to scale up a startup. This conversation is packed with insights on leadership, scaling a business and staying agile in a fast paced industry, and what you'll hear is being a CEO often means you're the chief everything officer. So get ready for some invaluable lessons and an inside look at what it takes to build a company and scale it in 2024 Emory, welcome to front end happy hour. How are you doing?

Emre Baran
I'm doing well. Thank you very much for having me. Awesome. Well,

Ryan Burgess
thanks for joining us. Tell us a little bit about yourself. Who are you? What do you do, and what your favorite Happy Hour beverages? And let's start there cool.

Emre Baran
I'm Emre Baran. I am the co founder and CEO of cerbos. What do I do on a day to day basis? I try to be a good CEO and of a growing company, a fast growing company, trying to find trying to establish itself in the market, trying to establish a new product in the market, of an emerging technology and my happy hour beverage. Lately, I've been very much into alcohol free beer, and I'm nice. I especially enjoy Guinness zero servant and corona zero. How

Ryan Burgess
close are they to like your tastes like when you have the alcohol versus the non alcoholic version.

Emre Baran
In my mind, they're very close, because I actually also stopped drinking alcohol about five and a half years ago. So nice. I don't have much of a recollection of what it used to taste like, but I'm like, Oh, this, this tastes like what I remembered you

Ryan Burgess
mentioned something that I thought was really funny. I want to dive into, like, one. I want to know what servos is explain. You know what that is. And actually maybe let's start there. What is cerbos, and what do you all do?

Emre Baran
Sure cerbos is a scalable permission management platform. It allows you, it allows software developers to be able to define and evolve actions for roles in there, within their software. It allows your end users, product team, security team and developer teams to ultimately define and evolve actions for each of the roles that they have. You have actually built within your software. It's been referred as externalized authorization, which is in our up and coming fields, and at the end of the day, the way that we usually developers refer to it is fine grained access control, without having to build the infrastructure of fine grained Access Control yourself,

Ryan Burgess
which honestly it's a lot of work to do that, like in any application, it just it like, starts small, and then it's like, you keep adding things, and it's like, it gets very complex. So separating that out and having a service for that, it's music to my ears, exactly.

Emre Baran
It's one of those things we always say. Every software developer approaches as, oh, I can do that. And yes, they can with a very simple if then else statement. There you go. You have your permissions, like, if manager allow, if not don't allow, and that if then our statement will take you pretty good way along the way. You know, it will take you pretty far until you have a software that's actually serving enterprises with multiple users in different roles that really have to have those limitations. And suddenly new requirements start coming in from your customers, from the entry or sales team, from product teams. It's like manager role is great, but you know, we can't have 5000 managers that needs to be nuanced, managers in departments, managers in locations. And suddenly that, if then else, statement starts getting complex, and suddenly, you know, an engineer raises saying, Hello, we gotta refactor this way. I'm gonna build something that's gonna actually scale so that next time when you. Requirement comes in, we don't have to write code. Somebody can change the setting. And there are tons of pitfalls of that, around performance, distribution, speed, scalability, security, and suddenly it becomes a big task. Suddenly it's no longer three lines of code. It's like, you have to have a dedicated team to build it, manage it, scale it, maintain it over time. And you know, the backstory of cerbos is, in our previous jobs, we had to do that five to 10 times, and different companies in one company three times over three, four years. And every time we're building it's like, Why isn't there something else? Why isn't something else? Isn't there something else we can implement and just move on? Because it's an indifferentiated part of the stack. It's kind of like having to build your own database, right? And none of us are in the building of a database business, unless you are building databases right, because we're all in a business of solving a business problem. Suddenly you find yourself writing a piece of infrastructure to make your product work. And that's exactly what business we're in.

Ryan Burgess
Yeah, I think you said it really well. Is, when I'm building a piece of software, there's, there's something that I'm really focused on. It's like, I don't really want to, you know, figure out, like, authentication. It's like, that's been solved, right? Like, I don't need to go deep and rewrite that. This is another one, having different roles and responsibilities for people. It's like, I don't want to have to rewrite that all over and over again. Also, it's not an area of passion, right? Like, it's not something that I'm like, living and breathing all the nuances that go with that that make it more scalable, make it more flexible in the system, but now you have a team doing that, right, like, and you can offload that, where they're thinking about that, they're working with other companies that have the same problems. And I think that, to me, is exactly what I want in something where I don't have to think about much I can, you know, know that it works. Trust it works. People are thinking about it, especially on smaller teams too, right? Like, if you're not a large company that has a dedicated team doing this, it, it makes sense.

Emre Baran
It's usually the journey is like, you know, you build an MVP trying to prove value of your software, and then the end of that journey is going enterprise. But somewhere in between, you have to solve all those things. Like, you don't have to be a full enterprise solution. But you know, the moment it's no longer MVP, the moment is, you know, it's addressing businesses that have, you know, tiny bits of, Inklings, of showing of enterprise requirements. These things need to be taken care of. Yeah.

Ryan Burgess
And it's also like you have maybe 10 of those things, not just this. It's like, you have 10 of those things adding up. You're like, oh my god, I'm scrambling to get that going. So yeah, totally makes sense. Another thing in your intro that really sparked curiosity for me was you saying, I try to be a good CEO. So what does a good CEO mean? I would love you know, a definition of what you believe a good CEO does.

Emre Baran
The way that I look at the role of a CEO, you know, I also look at my previous companies that I worked in where I was a co founder, CTO, etc. A good definition of a good CTO or CEO as a co founder actually changes throughout the life cycle of a company, right? If you are one of the three co founders or four co founders just working in the beginning, the definition of a CTO is, you know, you are the developer, you are the tech lead, you are the architect, you are the VP of engineering, you are the CT CTO, or in a CEO case, all of those, plus the sales side, potentially, or it depends on who else is within the founding team. And, you know, I call my, my explanation of the abbreviation CEO is, especially in a startup, is Chief everything officer, right taking care of whatever is not being taken care of in order to get this business forward. You know, fast forward that in a bigger company, a larger company, what a C A good CEO is again giving direction to the teams, building a good company big, building a good team so that everything will be taken care of and whatever is not being taken care of, as a founder CEO stepping in and making those things happen. So, you know my definition of, let's, let's call it a founder, CEO, rather than just a CEO, because I'm sure the definition of a good CEO at a, you know, IPO company, you know, public company, is a completely different story. It's like you know, that almost steps into, you know, and to grow, how to, how you know, how, high output management. But as a co founder CEO, I try to be a good CEO and try not to step on too many toes, empower as much as possible, micromanage when it needs to be in the beginning of certain things to just get the spark going, but then be able to step away and. Enable teams to take over and and, you know, get the right processes in place and take things forward.

Ryan Burgess
I like that. I really like that you called out the difference almost to like, almost in the company life cycle, is that you're playing different roles, obviously, as a founder, yeah, like you said, you're playing, like everything, everything role, and then slowly you start to delegate that away. But I think that the skills probably change too. Like as a company is, you know, one employee, three employees, to 100 employees, or to 10,000 employees, that role significantly changes, and you kind of have to fit the need of that role as it as it happens. Or you're like, that might not be the thing too. Because I've seen some CEOs, they're like, now the company's got to this size. That's not really my bread and butter or something that I even enjoy. I'm gonna, you know, hand over the reins to someone who takes it that much further. Yes,

Emre Baran
I agree in that. And one of the things that actually, I've years ago, I've I've discovered somebody called Jemmy Allen, who used, who leads the strategy arm of BCG in the UK, and he has a book called founder mentality. So ever since I've actually read that, my approach to as a company grows being a CEO, CTO, VP of Engineering, and it's about, you know how you can, how you need to be always with a founder mentality in the front lines, and how not to introduce actually middle management and become and get your information through middle management, like how actually executives can always be in the Front Lines and and learn, because in his book, and in his there's actually a great 20 minute video, maybe we can put him in the show notes, etc. He, he talks about how companies slow down with additional layers of management, and what that, what that management actually really introduces is information filtering along the ways and how things actually get lost, and nuance, all these nuances get lost, and how to overcome that by having a front line, front line mentality by every executive along the way, so that they're not only getting their information via proxies, but they're actually also first hand experiencing everything.

Ryan Burgess
I love that, because you're right, like, it starts to the higher up you go, you know, you're further away from the like, say, like, in our world of engineering, it's like you're further away from the actual engineering work the higher you up you go. Which makes sense. How do you scale that? Though, too, right? Like, how do you think about it as, like, having touch base with an engineer versus having touch base with your VPS, directors, etc, managers, all that, like, how do you try and figure out how to scale something like that? I think it's

Emre Baran
actually funny enough. It starts with being in touch with customers throughout the whole chain. Whether it's being in touch with all the employees. Being in touch with the employees is relatively easier. I mean, right now we are small. In my previous company, we have scaled up to about 300 people or so. Within my organization, at some point, I had 6080 people. And in early stages, I always had a one on one with people. I always say, whether it's half an hour or so, and you know, of course, as a team grows, there are enough hours in a week to be able to catch up with everyone. So that became every two weeks, every three weeks, every four weeks. But nowadays, the way that we actually deal with in a fully remote company is much easier because, because we're fully remote, our default mode of communication is asynchronous through slack or loom videos. So the you know, anything that's one way it can be a loom video that's actually published, which takes care of the time zones, etc, and where people can actually get to see the update, and then suddenly the time that we have to we have for a catch up becomes any questions that they might have on top of the information that's been that's been already provided. And I've seen that in my previous company as well, where, like, they're probably already up to date with everything that's going on within the company. And I used to always say, I'm like, Look, this is your chance to question me for anything that you're not potentially hearing in the hallways, you know, ask me things that are happening within the executive meeting. So ask me questions about that are happening in the board meetings, like, What insight, what? What additional information can I give you so that you feel well informed about everything that's happening, or when you feel well informed about the decisions that are being made.

Ryan Burgess
I like that too, because even you know, even as a leader, as I've had more teams under me, or something like I felt the same thing, you start to spread out how many one on ones you can have. I think the one on one is so important. But they the the cadence starts to change. Also, what I find myself have had been doing over time is repeating myself, right? You're telling the same our team needs to do this, our team needs to do this. We need to think about this. And it's like, I loved what you said, too. Is like you're basically sharing a video of that and getting people to be like, All right, well, you've got the information. We all have the same information. What kind of questions can I answer? Do you agree with it? Do you disagree? And then, so that really helps just get to the get to that conversation a lot quicker, versus the like, oh, well, let me explain what we're doing 10 times, you know, like that or more.

Emre Baran
I mean, then I see that cadence a lot within servos, we're a fully remote company where, you know, sometimes I repeat myself twice, three times I said her, I'm like, I'm like, and then you get into a stay, I'm like, What have I said? What have I not said? Like, what? Because there's no script, right? And like, loft, at least for me. And the most recent example of this, yes, we do this for company meetings and updates, weekly updates, monthly updates, etc. But the most recent example of this was we were hiring for a director role, right? I was talking to a bunch of candidates. And, you know, first and 20 minutes of that conversation, talking to the candidates, again, I'm explaining what the company is doing, what the role is about, what we have in the place, etc, which, again, halfway through, I start having, you know, some mental problems of like, what am I said? What am I not? Said, like, am I? Am I doing it justice to this role? And after doing a third one, I said, This is it. I actually recorded a loom that explains the role and everything else, and sent that to our recruiter, and our recruiter shared that with all the candidates, so that the conversation, as we started, is actually jumping into the actual discussion and conversation. Oh,

Ryan Burgess
my God. I'm like, hearing that. It's so obvious, but I'm just like, wow, I wish I would have done that the amount of times that I said the same thing over and over again, and especially when you're hiring for a particular role, I think what you'd said there too is that you forget, did I tell you this? Like, you know, because I'm like, I know I said it to somebody, but I've talked to like 50 people, and it's like, did I say that same thing? And sometimes I do, like the repetitiveness. Maybe it is like, doing it three times is good, because you kind of get a rhythm of

Emre Baran
refine it, your refining exactly what the picture is. But after that, that's like, sounds like a broken record. And then broken record in your head is like, oh, did I skip something? Did I say it? It's always yes challenge. Well,

Ryan Burgess
I start to Yeah, you feel like a broken record. And I hate that. It's just such an annoying feeling. But then also, you leave out context too, right? Like, you kind of leave out some details that are really important, that you're like, Oh, I just assumed you had that because you've said it so many times that it's, yeah, I love that. Okay, so cool. Let's get to this remote stuff too. I love that you brought up, the company is fully remote. You all started in 2021 so I'm assuming that there was no question about it, because of the pandemic, you had to be remote. And I would love your thoughts on, like, what were the challenges in early days going like, Okay, we have to build a remote company. Did? How did that change your thinking versus like, Hey, we're in the office. So,

Emre Baran
yeah, I mean, the funny thing was, we started, as you mentioned, we started in March 2021, and my co founders and I, we were in more than a couple of miles from each other, like we we used to use the, you know, one of the parks Right, right between us, as a office for to go for walks. But you know, most the job most today was actually done remotely from home, and there was no other way. And I actually loved it as a, you know, a at the time, bootstrapped startup we started. We didn't have any funding, yet, nothing has been figured out. And, like, great, no cost of an office, right? And whatever, whenever you do a budget, was like, okay, one one item is less. And then, as we grew again, there was no end in sight yet. And we started hiring engineers. We started hiring the team around different places. And one of our very first employees, who actually, at the time, who applied, was living in New Zealand, and we actually, you know, had an active discussion about this, is like, Oh, is this going to be a challenge? Is this a good thing or not? And we actually made it. And of course, after the interview and having the conversations, we decided to go with it, because it was going to make us a better asynchronous and a remote company. You know, a lot of people consider remote when nobody's in the office, but, you know, it becomes a much bigger challenge when you're actually across multiple time zones, and being asynchronous forces you to rethink a lot of things, like company all hands, for example. Right? There's no There's it's impossible to have an all hands meeting and then, which kind of pushed us to think it was like, What's the point of an all hands when everything is almost like, one directional? Yeah, maybe it's a little bit of a motivating factor getting people together. But beyond that, it's actually all about the information that you're relaying. And that's where the beginning of our, you know, looms starters, like, here's the information. I publish it, or each one of the teams publish it as their weekly update, etc, and it's consumed individually, if there are any questions, all of those things happen, etc. So those were, you know, our early challenges. And do I miss an office environment? Absolutely. I mean, a couple of weeks ago we had our off site, and there were great ideas. There's great conversations being had. You know, there's a lot of serendipity, and other conversations happen. You know, when you're just not working, like when you're talking to someone, when you're having lunch, or when you overhear a conversation, we try to replicate that as much as possible in Slack, we try to, you know, one of the things that I always say is, when somebody actually DMS me on Slack about, you know, it's work topic, actually say, hey, let's take this to an open channel. Yes, I'm happy to tell you there's nothing private in this I'm happy to tell you that let's take this conversation open channel so that people have a chance of eavesdropping on this. If they're interested, they can dive into the thread and go through it. If they're not interested, whatnot, okay, they can just move on with their life. So the early day challenges were a lot around, you know, how do you get together? How do you brainstorm, etc, but then we were also very small, so it wasn't that much of a challenge. So it's actually a bigger challenge. Now, when you have multiple people and you want to do a brainstorming, but then you don't want to just, you know, waste people's time into a brainstorming in a good old days, it would have been hard. Let's get in on the in front of a whiteboard. But then, you know, suddenly it starts becoming much more, much more you starts becoming that we need to be much more considered about others times also, you know, we are remote and flexible hours in a sense that nobody's guaranteed to be on the other end of the of the chat if you need it. So it forces us to write better messages with more context and everything else. You know, it changed a lot of our thinking about, Okay, where is this person right now? What context do they have? What can we actually provide so that the answer that's coming back is as as complete as possible, and it's, you know, if you ask me, it's like, if we, if we would ever go back to an office right now, I would say, probably not for the time being, because this is how we started, and how we started making things work. It would be very disruptive to have two classes of citizens where some of them are in an office, and some of them are remote. And, you know, I completely understand people asking people to, you know, companies asking their employees to come to their office. It makes sense. There's a lot of value to be had, but what's impossible is having some of the staff in the office, some of the staff remotely, even, like when you think about a meeting, right? There's so much more high bandwidth conversation going on in a meeting room and in pre meeting and post meeting. And if you are the remote person, a, you're not in that whispering conversations. You cannot have those little whispery conversations within the room. B, post meeting, you're not really having the same level of conversations with people about little things that have been discussed, like any follow ups, etc. So on that. I'm not a huge fan of hybrid in a sense that where some people are on site, some people are off site, but that's just me. That's just what I've seen from having worked in an office as well as remotely, you know,

Ryan Burgess
I think I'm with you on that too. I've had it in all varying degrees. I to be honest, though, I don't think I've actually worked at a full remote company, but I can see when I've been on teams that are fully remote, and just how that has benefited just, you know, it makes things so much easier. Logistic wise, the hybrid is always, always the hardest, right? Like your people are feeling left out whatever it may be. But then even worse, as if, and I have been that person, where I was the one person remote, the whole team, and everyone was in and that so lonely, exactly, okay, let me yeah, you feel you feel lonely. You feel like you're missing some of that context. You're just like, and those conversations that you addressed, like, after the meeting, those are so powerful. Like, honestly, I feel like we solve problems that way too, right? Like, there's times where this idea came up the meeting's done. Like, you know, like we're humans. We don't like fit. Perfectly into, you know that 30 minutes or hour block, or whatever it is, you start having these conversations, and you start sparking this idea. And to me, those conversations are ones I don't want to be left out of too Right? Because that's also being an engineer at heart. I want to solve problems, and I love getting hearing other people's solutioning and stuff that happens in meetings. Don't get me wrong, but it is those conversations that if you are not there in person that others are having, you get left out or the other way around. Remote people could be doing that more right. Like when I'm in the office, I'm running around to meetings and everything like that. I'm not sitting on Slack. So I miss some of those details. And so I like to that you said I bring some of those, let's just bring this into the public right? Like, let's bring this into a public channel. Because that, to me, is like, your water cooler talk, in a sense, it's like, oh yeah, cool. They're talking about that ad. I'm not that interested. I can just kind of walk past the water cooler, but I might stop, because I'm interested in this subject. And like that, to me, is a really cool way to try and make up for something that might have been left in the office mode.

Emre Baran
Let me give you a different example of this from my previous company where, you know, it was four co founders. We started four of us, and, you know, we grew, uh, eventually, and at some point our engineering team was 510, people. At the height of it, with product and design everything, I think we hit 50 or so, 50 or 60 and bunch of early employees, when they were leaving, one of the key things that they mentioned, I was asking like, Why? Why are you leaving? What's what's led to it? A consistent theme was hearing from them, it's like, oh, I don't feel like I know what's going on anymore, where, which is very normal, right? When it was a small company, we were all in one floor. Everybody overheard all the conversations as we grew. We had offices in, you know, five, six different locations. Even our main office was in three, four different floors. And you know, people who would earlier on, hear conversations about sales, hear conversations about successes. Here's hear conversation about conversations about, you know, challenges. Don't really know what's going on anymore. So the you know, work that comes away, they don't really get the context of it and or if there are some decisions have been made, they only hear the official line of the decision and why it has been made, but they've never overheard the conversations that led to that. They don't really know whether this was a, you know, five minute discussion and a decision was made, or it was an ongoing issue, etc. And, you know, there's a special breed of people who join early companies because they actually enjoy that, what I'd like to call the organized chaos of it. And that doesn't scale. The problem is that level of conversations doesn't scale. So, you know, one of the hopes that I have with cerbos, we're right now, you know, 15 people or so, the way that we have it implemented, with the slack conversations being as much in the open as possible, all the engineering conversations being in GitHub issues, and everything being documented. Hopefully that will scale much further, and it will actually leave you know our our company employees much more in the loop about everything that's been happening. So we'll see the scalability of this model, hopefully in the next couple of years. I

Ryan Burgess
think you're headed in the right direction. Like me. It to me, it makes a lot of sense, especially as search and things get better and better, like, especially with AI and things like that too, that it's you. Those conversations are documented too, and so if you can search them easily, like, if you know you guys are five years in, let's say, and I come join and maybe a few 100 employees, and there's all this data that's built up. If you're able to ask the questions and really get those, like, real answers, that can be really helpful context to really help do your job too. Is like, Ah, I see how, three years ago we got to this decision, it really helps paint the picture. And so I think if you have that data built up and that practice of it, it can be really helpful. I think sometimes, like one thing I noticed too, that I was earlier at Netflix. Obviously, it was fairly large. Even back, you know, when I had started, it was probably a few 1000 people. But what I noticed when, as it grew and we were, you know, more hybrid remote type work, is that it was almost overwhelming information, like there's too much, and so it's really hard to know which information is important for someone and which is not. And so to have those filters, it's really difficult. And so you can have all the information in the world, but it's really hard if you can't parse it in a, you know, not overwhelming fashion.

Emre Baran
I mean, what we try on that sales calls and customer calls, what we try to do is we try to record them as much as possible, so they're available in raw format, but then also when we post them internal. Exactly. There's like, here are the key takeaways. Here are the key things that have been discussed. And, you know, John, this portion might be interesting for you. And try to, you know, record it with the minutes, etc. And then there's at least, always the raw information in there. And sometimes, you know, I even come out and saying, Hey, do you mind listening to this? Because I probably listen to the customer with happy years, and there are things I'm not catching in here. So it's always a good practice to have that raw information as well as of a, you know, here's a key piece of information, and who should be acting on certain things.

Ryan Burgess
I like that. Yeah, that's and, course, as it scales, hopefully that's just practice, right? Like, everyone kind of does that. And so then you're like, circles of people that are doing it and looking out for, you know, John needs this. And, you know, there's other people that are looking out for that that I could see scale, because it's like, you're not doing it all the time. You're not going to go to John's desk and be like, yeah, yeah, you need this. Like, maybe, but it's like, you can't do that with, like, you know, 500 people.

Emre Baran
And going back to your early question, what's the challenge of being a CEO? Is trying to lead by example, by implementing these things and hopefully hoping that people actually pick up on it and repeat it without me actually explicitly saying, this is the way to do it, because I don't know the exact way of doing it. I don't know what's the best method of it. And what I hope is people actually pick up. They always have their own styles adapted to it and like so I can, well, I like what you did there. Maybe I can actually repeat those things as well. But it's the, you know, trying to get these routines in place as much as possible, so that everything is designed for the company's success.

Ryan Burgess
I love that too. I think it's like, you've out you as the CEO, outline the values of the company. And like, you know, what are things that are important to us as we operate, and information and access to information is important. And so you distill that and make that a practice, then it opens the door for creativity, right? Is like, how people do that? And, you know, it might be a loom video today, but someone might find something that's even better or easier or whatever, to streamline that process. You're like, great. Like, do that. The whole important thing that I've set out is to share information and make it accessible for people so that they can, you know, get the most information to do their job the best way leading by example as much as possible. Yes. So you've also worked at larger companies, not just being a founder. I saw that you were at Google. What made you decide to leave a large company like Google and go found your own and do that? Because those are, those are huge differences, and I would just love to hear the transition between those two

Emre Baran
I was lucky enough to be at Google earlier on, where, you know, I was part of the Google Ads product team, and there weren't that many of us, and there was a lot of opportunity. And Google over back then, when they hired, they hired, especially within the product management, people who were initiative takers, people who could actually almost operate like a startup within Google. And I, you know, within Google, I built about four different products within the ads group. And you know, I love that. It was basically very much so like, Hey, I have this idea. I wonder if it will work. And we always had our, you know, day jobs, but always were welcome to, you know, come up with new things that we can actually start up. And then, you know, sometimes you get a 20% engineer to start the first versions of it. Sometimes you actually get a team assigned to it. And it was almost like a startup within Google, which was great, because you have everything else, right? You have the entire infrastructure set up. And not only that, you have an entire business that's already running with customers and end users, so you're always capable of testing certain things very easily, yes, and and be able to see results. And you know, one of the challenges as a startup founder, sometimes you have a new idea, but it's so hard to test that, because it's so hard to find people to talk about them and find the relevant people. Whereas when you're at Google, you have billions of users that you can do certain tests on, you have hundreds and 1000s of businesses that you can actually talk and start finding their, you know, talk about their problems and solutions that you might have to them. And you know, that was always great within Google and but I also feel like once an entrepreneur, always an entrepreneur, at the moment, things get a little bit more structured. Or does the moment, you know, some walls, brick walls, start appearing on your path. You know, as an entrepreneur, the natural tendency is like, oh, I can get around that. I can find a way around that. And I have nothing too bad to say about Google. Google has been is still probably light years ahead of any company that's being managed by the same size company, if you compare it or any company above certain size. But you know, I've hit couple of those brick walls within Google when I was trying to do something as Google was also maturing. Right to Google, this was Paul's 2008 crisis. There were certain, you know, structures being put in place. So the company is, you know, better manage, etc. And I want to do certain things. And it wasn't as easy as it was before. And you know, me and my co founders, we had a cool idea. And this also corresponded some time where Hadoop was being open source, so there was a lot of big data technologies that we could actually leverage. We didn't really need Google's infrastructure. This was also coincided with the time where AWS had just started. So we could just our higher CPU and compute by the minute. We didn't have to order servers, and high level of, you know, infrastructure investment was needed, and we had a business idea around certain things and and again, those entrepreneurial instincts kicked in to go start the company in a specific topic that we wanted to tackle. So that led me to go and again, found my own second company at the time. And, and, yeah, it's the, you know, it's different. It's absolutely different. I remember first day of walking into the office, actually, at the time, also moved from New York to London, just, you know, to be to start the company. We decided to start it in London because of certain reasons about where our customer demographics were, etc. But now the first day, I still vividly remember lunchtime. You know, me and my co founders, we looked at each other. I'm like, what do we do for lunch, which was never a question before in our life. You just walked into the cafe, you ate something, it was like, where do we go for lunch? And where it is so and it's completely a different challenge, right? And again, it was great to be within Google's realm, where whenever you wanted something, you could always get it like that, because there was somebody to take care of anything you need, or you knew who to talk to, whereas, when you're on your own, so Okay, who do we find someone to talk about? This is suddenly, I'm like, nobody realizes that was step one of thinking process, right? Or things around again in when we look at software, infrastructure, various other things. And like, suddenly, you know, at the time, there was a much JavaScript going on at Google, whereas JavaScript was filming in the world, and we were like, What is this? JavaScript? Do we do? We do it or not? And like, suddenly, like, being exposed to so many new technologies, so many new frameworks, was a very interesting it was a very interesting experience.

Ryan Burgess
I think that's always kept me interested in JavaScript, because of that, it's just like an evolving ecosystem so quickly, too. So that makes a ton of sense. Going through being a founder, I definitely get your connection from starting somewhere like Google, where you're like, yeah, it basically was building startups within a large company, and you just kind of had this backing to kind of just run with something like, I have this idea. I have the data that I can prove this out with going into the founder mode, side of it, outside of something like Google. Like, what are some of the key lessons, like, from some of those experiences that you've learned that you kind of reflect back on and maybe have adjusted as you're, you know, founding newer companies. There

Emre Baran
are lots of key lessons here, but it's number one is data is always hard to find right finding the right data is always fine. It's always hard. And, you know, many people don't realize you gotta work to find out data. Everybody, of course, is a founder has a hunch. And you know, the founder's intuition, the way that I refer to it is basically a collection of all your previous experiences and periods, conversations you've had. But it's very hard to pinpoint a specific data set as a founder's intuition of like, what should be done. And that becomes even harder if you have a team that you need to actually relay that information to. It's like, hey, it's you can use your social credit a couple of times. Like, trust me, I know this. You can do that once or twice, but after that, you need to be able to do that to show the data. And you know, finding data is very hard as an early, early stage startup founder, yes, of course, you can find some data out there, or you can do a small experiment, small survey, etc, but it's like, how do you prove that you're not listening with happy years? How do you prove that it's you know you. As early as my previous I mean, in 2010 you can always ask questions and survey questions to people, but you really don't know in what context they're responding, right? And you need to actually really interview and get to the details of it. But again, as a small startup, how many people can you talk to and make make sense out of that data. And the other thing is, again, a key lesson is very similar to that, is like talking to customers, right? So when you're similarly to data, you're talking to customers. And but how many customers do you have? How many potential customers do you have access to? And not only that, how many customers are just saying that, and how many customers are really willing to buy your product, are willing to put their money down before they talk to you, saying that they're going to actually find and then third one, I would say, key lesson is, building always takes longer, especially if you're coming from an engineering background, you know, non engineering background, people can probably put a hack together and show it to customer, and maybe that's the right way of building it. But then the moment you find a fit, you know, us, people with an engineering background always want to build it right, so that this is whatever we built is going to actually scale, and therefore there's an nice balance to be struck between those two, those two things, but building always, always takes longer than you predict. I

Ryan Burgess
like that, especially tying it back to the engineering side, because that's something I've been thinking actually a lot about from just even how leading teams and where should you Where should you spend, like, the extra time on those engineering investments? Like, we all know that, that there's times where you put something out there early as, like, a prototype, and if it's successful, that's awesome, but it means that you are, you're refactoring, you're, like, rethinking. It's like, you know, it

Emre Baran
got if it's successful, you don't even have time to refactor that. No, because somebody, somebody's already trying to sell that to grow the company for the next phase, next phase. And you know, when do you take that pause to go refactor?

Ryan Burgess
You never do that's the thing is, like, it's so difficult to do like and to say to the business that you're working for, it's like, you know what? Yeah, things are working good. We're gonna pause on any new features or development. We're actually just gonna go rewrite everything that you see today, but it will scale better. It's like, it has to be done. But I think there's, there is this weird balance of trying to figure out, like, when do you cut corners and hopefully cut the right corners, right like, there's times I want teams cutting corners because, like, I've also had teams that were trying to make the perfect thing, and I'm like, who cares? Like, sometimes it's like, if it doesn't get to the point that it needs to be there, then it doesn't matter. Like, it you just wasted time. And let's get an early signal. So there, but there's this weird balance, because they're like, but what if it is successful, then we're gonna have to go back and rewrite all this. And it's like, yeah, so it is. It's a tough one.

Emre Baran
This all goes into the whole yak shaving bike shaving, yes, yagni,

Ryan Burgess
it's never ending. So tell me, there's no perfect science to this one.

Emre Baran
I haven't found it. Maybe somebody does, you know, successful, more successful entrepreneur. Maybe they have a answer to that. But I also believe every company is different. Every product is different. Every interaction of a customer, you know, customers interaction with every product is different. Therefore it dictates a different dynamic. And you know, it's a whole different dynamic. When you have that massive sales pipeline, then you can potentially say, post certain things you can afford that you know, time versus if you're still in the discovery phase, and you're trying to get to a perfect product that's going to actually sell faster, 2x 3x 4x faster. You're always chasing that, let's call it a unicorn, trying to perfect your product. Versus when you're Google, the world is a whole different place. So you know, you can put a team on just building the product or maintaining it as it is, or putting new features on it based on a roadmap, and you can have a whole shadow team, re architecting, re engineering it, and one day you actually make the switch over to the new system, which, by the way, is another nugget. The biggest time sync in all of this is actually the migration, not writing that in the system, not maintaining the old one. It's once you have it the whole migration, which suddenly involves so many other teams, so much more time, so much more, you know, exception handling or data handling. Oh, man,

Ryan Burgess
it's the migrations and those ones, when you say about estimating, the estimating and migration is like, I don't think I've ever seen it successfully done, where it's like, it's always really far off, and it's like, everyone puts the best intent. To it's not just being wildly, like, liberal on the an estimate. Be like, yeah, yeah, it's fine. We'll get this done real quick. It's like, no, there's thoughtful thinking that goes into it. And then there's like, 20 things that people didn't account for that just quickly add up. And it's like, you see them in hindsight. You're like, Yeah, we should have counted for that. But that always, always happens. Maybe before we wrap up, I you've given some amazing nuggets of advice, but I would love to maybe just kind of end on like if we have listeners out there who are interested in starting their own company or building out a product from a founder with experience, what advice would you give them? This

Emre Baran
is I actually one of my co founders from my previous company has a whole LinkedIn post on this. He's He's now a VC. You know, we all, especially as engineers, we can all we're very we're all very good at seeing inefficiencies. We're always all very good at building solutions. We're okay, also good at imagining what it could be. But the biggest challenge that a lot of times gets overlooked is what's going to be your products, distribution strategy? And it's funny because we, I mean, this is a common thing. Maybe we can have a whole different conversation and a podcast session on this. But one of the things that I commonly saw and when we were doing our initial fundraising again, we were lucky. It was covid times, we actually managed to speak to 90 different investors because everybody was busy, everybody was bored at home, taking calls right at the VCs. That's very all just doing. And, you know, in a good old world, it was much harder. You had to go to the VCs office, etc, and suddenly they opened up. And one of the common questions, apart from, you know, why is your product different, etc, that I kept seeing, kept hearing consistently across every single one is, what's your go to market strategy? And by that they mean, how are you going to get distribution? How are you going to, you know, what angle are you going to go to customers that you're just going to convince them to take your product, and how are you going to make that scalable? How are you going to actually get them to hear about your product and say, hey, I want that, because that solves a that solves a pain. So you know, if you're starting about starting your own company, the easier part, again, for people with an engineering background software background, is building the prototype, building the demo, building the product that potentially scales, etc. But all of that is just dry piping, unless you're bringing customers into it, and, you know, putting it on Hacker News and hoping somebody will catch on putting it on Product Hunt. Those are not, those are, you know, crap shoots. They're not guaranteed. So I would highly recommend to have a very thought out strategy about who you're going to talk how are you going to get this How are you going to start this flywheel going, and what's going to be your flywheel? Right? It's not just talking to someone. It's like, what do you get out of them, right? How do you get them to be the promoter of your product, the customers or the potential customers that you speak to? So think about, you know, your flywheel and distribution strategy.

Ryan Burgess
I like that a lot, too, because, yeah, even as you're talking, I'm like, Yeah, my head, as an engineer, thinks about like, Oh, I'll build this great product, but it's like, just because you build a great product doesn't mean people are coming to it like, it's like, that takes a lot of work and effort, and that's why there's whole teams around how to continue growth of a product. So I think that's very good call out. And I love that. You know, just even through experience, that's the question that keeps coming up. That's what Vc, Vc money cares about. So, you know, be prepared to answer that question indeed. All right. Well, thank you so much Emery for taking the time to speak with me. Where can people find you? Where can they get in touch with you if they have questions and want to speak with

Emre Baran
you? Oh, thank you so first of all, thank you very much for hosting me. I am on LinkedIn is Emre Baron, my full name and on Twitter. X, I don't know if we're still calling it Twitter. I said I still do. Keep calling it. I still do as well. I am fortunate enough to have Emre back to Emre on Twitter. That

Ryan Burgess
is awesome. I am very jealous of that. I was early on on Twitter, but I feel like I used up making some creative name that I didn't like, like years later, and then by the time to try and get my actual name, it's like, yeah, that's it's impossible to do. What a great conversation with Emery Baird. We explored his journey from Google to co founding servos, the challenges of scaling a startup and the insights. On building a product that can revolutionize authentication, his advice of balancing leadership with the technical aspects of running a business is invaluable for anyone in tech. We'd love to hear your thoughts. What stood out from today's conversation. Reach out on social media at frontend hh, on Twitter or leave a comment on YouTube at frontend hh plus, let us know what topics or guests you'd like to hear next. As always, thanks for tuning in to this discussion, and we'll see you on the next happy hour. You.