Front End Happy Hour podcast: Leadership, startups, and GTM with Emre Baran

Recently, Emre Baran, CEO and Co-Founder of Cerbos, was featured on the Front End Happy Hour podcast. Whether you're a founder looking to take your startup to the next level or an engineer working on building scalable, maintainable systems, this episode provides invaluable advice. Emre’s journey sheds light on the realities of scaling a business, the challenges of externalized authorization, and how the role of a CEO evolves with the growth of a company.

Key Discussion Points and Takeaways

Journey from Google to Cerbos

Emre discussed his time at Google, where he built several products within the Google Ads team. His experience there was like running startups within a large organization, giving him the freedom to innovate while benefiting from Google’s resources. This entrepreneurial spirit was key to co-founding Cerbos, an externalized authorization platform, designed to take the burden of building fine-grained access control off developers’ plates.

What is Cerbos?

Cerbos helps developers by externalizing complex authorization logic. Emre talked about how developers often start with simple "if-else" statements for access control, but as applications grow, the complexity skyrockets. Cerbos takes this pain away by providing scalable permission management, allowing teams to focus on building their core product rather than worrying about authorization architecture.

The evolution of a CEO’s role

Emre gave an inside look into what it means to be a good CEO, especially in a startup. His self-defined role as “Chief Everything Officer” reflects the varied responsibilities in a startup's early stages, where the CEO must handle everything from product decisions to sales. As the company grows, the focus shifts to building teams, delegating, and setting strategic direction, but always with a "founder mentality" — staying connected to both customers and employees.

Scaling challenges in remote work

Cerbos started as a fully remote company in 2021, a decision shaped by the pandemic and the flexibility it offered. Emre emphasized how important asynchronous communication and transparency are in scaling a remote company. The team relies heavily on open Slack channels, Loom videos, and GitHub issues to document discussions, keeping everyone informed no matter their location or time zone.

Distribution and go-to-market strategy

For founders, one of the most important lessons is to focus not just on building a great product but also on how to distribute it. Emre highlighted the importance of having a clear go-to-market strategy. Building a product is only half the battle; making sure customers know about it and want to use it is the other half. This was a key question investors asked him during fundraising, and it's something every aspiring founder should consider early on.

Conclusion

Emre Baran’s episode of the Front End Happy Hour podcast offers practical advice on the technical, strategic, and personal aspects of scaling a business. Whether you’re looking to better understand how to manage remote teams, scale systems, or navigate the complexities of a startup, this conversation is full of insights that will resonate with anyone in the tech world.

If you’re interested in learning more about how Cerbos can help streamline authorization in your product, sign up for Cerbos Hub. And don’t forget to join the Cerbos Slack community to ask questions, share ideas, and get support from the Cerbos team and other developers.

Transcript

Ryan: On this episode of Front End Happy Hour, I'm sitting down with Emre Baran, co-founder and CEO of Cerbos. With over 20 years of experience in the tech industry, Emre'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, Emre Baran is here to 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.

Emre, welcome to Front End Happy Hour. How are you doing?

Emre: I'm doing well. Thank you very much for having me.

Ryan: Awesome. Well, thanks for joining us. Tell us a little bit about yourself. Who are you? What do you do? And what are your favorite happy hour beverages? And let's start there.

Emre: Cool. 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, 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 especially enjoy.

Guinness Zero, and Corona Zero. How close

Ryan: are they to, like, your taste, like, when you have the alcohol versus the non alcoholic version?

Emre: In my mind, they're very close, because I actually also stopped drinking alcohol about five and a half years ago. So, 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 remember.

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

Emre: Sure. Cerbos is a scalable permission management platform. It allows you a lot of software developers to be able to define and evolve actions for roles within their software and 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 a few 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: 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, it gets very complex. So separating that out and having to. service for that. It's music to my ears.

Emre: Exactly. It's one of those things we always say every software developer approaches as, Oh, I can do that.

And yes, they can. But 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 else 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 for product teams. It's like, manager role is great, but you know, we can't have 5, 000 managers that needs to be nuanced managers in departments, managers in locations. And suddenly that Then our statement starts getting complex and suddenly, you know, an engineer raises saying, hello, we gotta refactor this way.

II'm gonna build something that's gonna actually scale so that next time a new requirement comes in, we don't have to write code, somebody can change the setting. And, and there are tons of pitfalls of that around par 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 ten times and different companies in one company, three times over three, four years.

And every time you're building, it's like, why isn't there something else? Why is it something, 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?

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: 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 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: It's the, 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.

Ryan: Yeah. 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: The way that I look at the role of a CEO you know, I, I also look at my previous companies that I worked in, where I was a co founder, CTO, et cetera, 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 1 of the 3 co founders or 4 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 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 I see 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 companies are completely different stories like, you know that almost steps into, you know, how to, how, you know, how, how high output management, but as a co founder CEO, I tried 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: I like that. I really liked 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 a hundred employees or to ten thousand employees that role Significantly changes and you kind of have to fit that 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 going to, you know, hand over the reins to someone who takes it that much further.

Emre: Yes, I agree on that. And one of the things that actually years ago, I've, I've discovered somebody called Jimmy Allen, who used to 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 learn because in this book, and in this, there's actually a great 20 minute video. Maybe we can put them in the show notes, et cetera. He talks about how companies slow down with additional layers. Of management and 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 lab 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 and experiencing everything.

Ryan: 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.

Let's say like in our world of engineering, it's like you're further away from the actual engineering work, the higher 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, you know, 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?

Emre: I think it's actually funny enough. It starts with being in touch with customers throughout the whole chain, whether it's, you know, being in touch with all the employees, being in touch with the employees is relatively easier.

Ryan: I mean,

Emre: 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 60, 80 people. 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 aren't 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, it's much easier because, because we're fully remote, our default mode of communication is asynchronous through slack or loom videos. So, you know, anything that's 1 way, it can be a loom video that's actually published, which takes care of time zones, et cetera, 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 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 meetings, 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: 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 I've 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. It's 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 ten times, you know, like that or more

Emre: That's exactly I mean then I I see that cadence a lot within Cerbos for 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 statement. What have I said? What have I not said? Like what? Because there's no script, right? And like, at least for me and the most recent example of this, yes, we do this for company meetings and updates, weekly updates, monthly updates, et cetera. 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, the first 10, 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, et cetera, which again, halfway through, I start having, you know, some mental problems of like, what have I said?

What have I not said? Like, am I, am I doing it justice to this role? And after doing the 3rd 1, I said, This is it. I actually recorded a loom that explains their 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.

Ryan: Oh 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 had said there too is that you forget. Did I tell you this?

Like, you know, cause 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, and sometimes I do like, you know, The repetitiveness, maybe it is like doing it three times as good because you kind of get a rhythm of

Emre: refine it. You refine exactly what the pitch is.

But after that, that's like, it sounds like a broken record and then broken record in your head. It's like, Oh, did I skip something? Did I say it? It's always challenge.

Ryan: Well, 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?

Emre: So Yeah, I mean, the funny thing was we started, as you mentioned, we started March 2021 and my co founders and I, we weren't more than a couple of miles from each other. Like, we used to use the, you know, 1 of the parks, right? Right? Right between us as a office for to go for walks. But, you know, most of the job, most of the day was actually done.

Remotely from home and there was no other way. And I actually loved it as a, you know, a, you know, at the time bootstrapped start up. We started. We didn't have any funding yet. Nothing has been figured out. And I'm like, great. No cost off an office. Right? And then whatever, whenever you do a budget was like, hey, 1, 1 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.

It's like, oh, is this going to be a challenge? Is this a good thing or not? And we actually made the, you know, 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 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, and being asynchronous or it 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, 1 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 started like, here's the information I publish it or each one of the teams publish it as their weekly update, et cetera, and it's consumed individually.

If there are any questions, all of those things happen, et cetera. 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 offsite and there were great ideas. There was 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, 1 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 the answer. But let's take this conversation and 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, et cetera, 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 the good old days, it would have been like, let's get in front of a whiteboard, but then, you know, suddenly it starts becoming. Much more much more, it starts becoming that we need to be much more considerate 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 were, 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 2 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 even 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 be. 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, et cetera.

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.

Ryan: You know, 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 is if. And I have been that person where I was the one person remote, the whole team. Mm-Hmm. . And everyone was in and that How did you feel? You feel so lonely.

Emre: Exactly. . Let me, I can you, you feel

Ryan: lonely, you feel like you're missing some of that context.

You're just like, and those conversations that you address, 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 it 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, 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 and 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: Let me give you a different example of this from my previous company. Where, you know, it was 4 co founders. We started 4 of us and, you know, we grew eventually at some point, our engineering team was 5, 10 people at the height of it with product and design everything. I think we were, we hit 50 or so, 50 or 60 and a 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 the, what's led to it? A consistent theme was hearing from them is like. 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 1 floor. Everybody overheard all the conversations as we grew. We had offices in, you know, 5, 6, different locations.

Even our main office was in 3, 4, different floors and, you know. People who would early on hear conversations about sales, hear conversations about successes, hear, hear conversation about conversations about you know, challenges don't really know what's going on anymore. So, you know, work that comes their way, 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 five minute discussion and a decision was made, or it was an ongoing issue, et cetera.

And there's a special breed of people who join early companies because they actually enjoy that. I would, I'd like to call it 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 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 a 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,

Ryan: I think you're headed in the right direction. Like, to 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 hundred 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'd started, it was probably a few thousand 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: 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,

Ryan: but

Emre: they're available in raw format.

But then also when we post them internally, 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, et cetera. 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 ears. 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: I like that. Yeah, that's and of 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.

Cause 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: 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 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, you know, designed for the company's success.

Ryan: I love that too. I think it's like you've, you as a 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?

It's 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. Like 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.

And leading

Emre: by example. as much as possible. Yes.

Ryan: 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? Cause those are, those are huge differences. And I would just love to hear the transition between those two.

Emre: 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 back then when they hired, they hired, especially within the product management people who were initiative takers, people who could actually.

Now almost operate like a startup within Google and you know, within Google, I built about four different products within the ads group. And 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 day jobs, but always we're, we're welcome to come up with new things that we can actually start up.

Yeah. And then, you know, sometimes you get a 20 percent 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. It's capable of testing certain things very easily and, 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. find people to talk about them and find the relevant people.

Whereas when you're at Google, you had billions of users that you can do certain tests on. You have hundreds and thousands 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 the moment, you know, some walls, brick walls start appearing on your path. You know, as an entrepreneur, the the natural tendency is like,

Ryan: Oh,

Emre: 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. With above certain sites, but you know, I've had a couple of those. Break 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 managed, et cetera. 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 to a 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 coincides with the time where AWS had just started. So we could just you know. Higher CPU and compute by the minute. We didn't have to order servers and high level of infrastructure investment was needed.

And we had a business idea around certain things. And, and again, those entrepreneurial instincts kicked in. To go start a 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.

And I remember 1st day off walking into the office actually at the time also moved from New York to London to, 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, et cetera, but at the 1st 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 cafeteria. You ate something. It was like, where do we go for lunch and where it is. So, and it's, it's completely a different challenge. Right? And, and, and, you know, 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, it's 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, when we look at software infrastructure, various other things. And like suddenly, you know, at the time, There wasn't much JavaScript going on at Google, whereas JavaScript was booming 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: 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, 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 big, Backing to kind of just run with something. You're 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.

Emre: There, there, there 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've got to work to find that data. Everybody, of course, is a founder has a hunch and the founders 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.

It's 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 ears? How do you prove that? It's you know. It's hard. 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 interviewed 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 it. And then 3rd 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 it's whatever we build is going to actually scale and therefore there's a, you know, nice balance to be struck between those two, those two things, but building always, always takes longer than you predict.

Ryan: I 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 should. 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, you're refactoring. You're, like, rethinking. It's like, you know, it got

Emre: 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.

Right. And, you know, when do you take that pause to go refactor?

Ryan: You never do. That's the thing. It's 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 going to pause on any new features or development. We're actually just going to 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? Yeah. 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 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.

This

Emre: all goes into the whole yak shaving bike shedding Yes, yeah It's just, it's never

Ryan: ending. So you're telling me there's no perfect science to this one.

Emre: I haven't found it. Maybe somebody that's, 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, customer's interaction with every product is different. Therefore, it dictates a different dynamic and you know, it's a whole different dynamic when you have. If you have a massive sales pipeline, then you can potentially say all 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 sink in all of this is actually the migration, not writing the new 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.

Exception handling or

Ryan: data handling. Oh, man, it's the migrations and those ones when you say about estimating the estimating a 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 estimate.

Be like, yeah, yeah, it's fine. We'll, we'll get this done real quick. It's like, no, there's, 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?

Emre: This is actually one of my co founders from my previous company has a whole LinkedIn post on this. He's now a VC. We all, especially as engineers, we can all, 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 covert times. We actually managed to speak to 90 different investors because everybody was busy. Everybody was bored at home taking calls, right? And the VCs, that's fair. We're all just doing, and, and, you know, in a good old world, it was much VCs office, et cetera, and suddenly they opened up and 1 of the common questions apart from, you know, why is your product different, et cetera, that I can.

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's also a, that's also 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, et cetera.

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 a product hunt. Those are not those are crap shoots. They're not guaranteed. So I, 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: I like that a lot too. Cause 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 cause 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, Emre, 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 you?

Emre: Oh, thank you. So, first of all, thank you very much for hosting me.

I am on LinkedIn as Emre Baran, my full name, and on Twitter X. I don't know if we're still calling it Twitter. I still do. I keep calling it Twitter. I still do as well. I am fortunate enough to have Emre at Emre on Twitter.

Ryan: That 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 Emre Baran. We explored his journey from Google to co founding Cerbos, 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.