• dolapo.io
• The Arc Browser

Allen: Welcome to It Shipped That Way where we talk to product leaders about the lessons they’ve learned, helping build great products and teams. I’m Allen Pike, and today’s interview is with Dolapo Falola. Dolapo is the head of engineering at the Browser Company, was previously a director of engineering at Slack and has also worked at Instagram, Foursquare, Google and others. Welcome Dolapo.

Dolapo: Hi. Thank you for having me. I’m excited to be here.

Allen: It’s so awesome to have you on the show. Heard great things about you. Obviously you’ve worked in some exciting, fast-growing, interesting environments with a wide variety, which I often find correlates with people who have seen a lot, learned a lot, and then not the least of which the fascinating parts working at the Browser Company where you’re building the hottest web browser in ages, which must be kind of a fun, fascinating environment to not just be in, but then helping build out how does engineering work at an org like this.

Dolapo: Yeah, for sure. I’ve had a lot of luck and I think I’ve been lucky to have a lot of great roles. So excited to talk about some of this.

Allen: Well, luck is a combination of preparation and then seizing those moments.

Dolapo: That’s right.

Allen: I wanted give you a chance to kind of share, give some folks some orientation about that kind of path, the path that you’ve taken so far, the Dolapo story. How do you like to tell that story in a sort of soundbitey or maybe somewhere in between a soundbite and a monologue intro.

Dolapo: Yeah, for sure. Yeah. I’ll give an overview. How did I get here? So I graduated college 2003, University of Texas in Austin, and I think I had somehow lucked or found my way into an internship at IBM in college. So I was a poor student and ended up working part-time through college at IBM.

Allen: Me too, not at IBM, but yes, I had the same actually fund my tuition through working in software, which is unusual path I think.

Dolapo: It is, and it’s actually in hindsight, very grateful because I was doing this thing that I loved kind of on the side while I was finishing my college career. At the time it was kind of fascinating because I was working on low level kernel extensions and security and it was just a way that-

Allen: That’s a fun first job.

Dolapo: Yes, it was.

Allen: Oh, which I don’t get a new guy to do. Low level kernel and security exemptions.

Dolapo: Exactly. It was really funny, because I was just kind of on this team way over my head and making very little progress, but hung out a lot with the QA people because they’d like to build computers and so did I. After that, I think at some point had a colleague who was leaving IBM to go to Google, and I think at the time I was like, that’s a place people work at? Of course it is. So I applied, ended up working there for a little over four years a bit on the Google Maps backend, and then actually started working on Google Reader, RIP as a 20% project, which was a thing that Google had.

Allen: Back when that was a thing.

Dolapo: Back when that was a thing. Then transitioned to work on that sort of full time for a few years and had this experience where the company was trying to kill it the entire time. So got a little frustrated and joined a startup with a few reader and blogger folks called Thing Labs. We worked on that for a year and a half or so we’re acquired by AOL, so I was actually at AOL for three months or something like that.

Allen: There’s even more. That’s not even on your LinkedIn, just the list of big companies that you’ve had some exposure to just expands and expands. I didn’t mention IBM either in my intro.

Dolapo: Yeah, yeah. The AOL stint, I don’t even really talk about. It was just so-

Allen: Three months.

Dolapo: It was like a blip. Exactly. Then started really kind of talking to the Foursquare folks. They were building this team out in New York. It was a software product that I was starting to use and really liked. Anytime I find an opportunity to work on products that I use, I just get a lot of energy out of that. And joined that team was there as at the height I think of Foursquare sort of popularity and peak and was there for four years or so. And then through some personal life stuff, my wife and I wanted to move to London and live in London for a bit. Took a job at Facebook Meta.

Allen: It was Facebook at the time.

Dolapo: It was Facebook at the time. That was such an interesting experience. I was kind of there for the beginning of Facebook’s big push into AR.

Allen: Before it was cool.

Dolapo: Yeah, exactly. Back when it was still camera filters and camera effects and things like that, putting puppies on your face.

Allen: But this was in the moment of Facebook reacting to Snapchat, right?

Dolapo: Yeah. Oh yeah, yeah, yeah, yeah. There was a very interesting moment.

Allen: They’re like, oh no, we might die.

Dolapo: Exactly. Facebook had this whole culture of lockdowns, which were these-

Allen: Lockdowns.

Dolapo: Yeah. They would declare we’re going into Code Red situation, highly competitive moment. Mark was like, “I want a stories product in Messenger, Facebook and Instagram,” in two months or something like that. It was just like your team has permission to not do interviews and all these other sort of things just to make it happen. It was just, as you can imagine, sort of an intense moment. We acquired some companies and we were building all of these tools and it was just one of the highlights I think of my career, just kind of chaotic and kind of fun. And then worked on Facebook stories and Instagram stories for a bit. This is a long story, but we’re almost at the end of it.

Allen: No, I don’t feel like you’re dwelling on any point. I helped save Facebook from Apocalypse and then continue on in the story.

Dolapo: I’m happy to obviously talk about any of it, but just give an overview.

Allen: Yeah, orientation.

Dolapo: Exactly. So yeah, around 2020 pandemic happened. I’d had my first son at that point and really wanted to take a little bit of a break, so I took a little bit of time off and then started talking to some of the folks at Slack who were really, really thinking about remote work.

Allen: This is during the COVID lockdown.

Dolapo: Exactly.

Allen: They were thinking about remote work already a lot and now they’re thinking about a lot, a lot, a lot.

Dolapo: Exactly, exactly. Got to work with someone who you had on the podcast recently, Johnny Rogers, on huddles and some of these features just to improve how people work from home at the time. I think around that time I was already kind of talking to the Browser Company and they were talking about building a web browser and I was like, why are you doing that?

Allen: It seems like a crazy thing to do. You can’t just build a web browser.

Dolapo: Exactly. I think I spent a bunch of time with them and I think the more I thought about the space, I was just felt like this perfect combination of bold product problem and interesting technology and a team that I felt like could actually do it. It just kind of felt like one of those rare opportunities that I was just like, okay, I have to do this. And I’ve been there for a little over two years now.

Allen: Nice. Which is a meaningful percentage of the company’s existence.

Dolapo: Yeah, yeah, exactly.

Allen: So for a people that there might be someone listening who doesn’t know, probably someone listening who doesn’t know. So we’ve been talking about the Browser Company, but the Browser is called Arc, which is the software I’m using to talk to you and the software presumably you’re using to talk to me. But just so if anybody’s like, oh, I haven’t heard the Browser Company’s like Arc I’m sure pretty much anyone in tech has heard of Arc now. How big was the team when you joined?

Dolapo: The team I think was probably around 20ish folks in eng and I think maybe the overall company was 30 at that point I want to say.

Allen: Yeah, that’s a pretty good ratio. Then over the last couple of years, where have you grown up to recently? I assume there’s been some pretty substantial growth.

Dolapo: Yeah, exactly. Overall team is around 80 folks right now with engineering being 46, something like that.

Allen: So more than doubled in two years, which is everyone has their own feelings of how much growth is in team size is too much, but that seems to be in that sweet spot where it’s about as fast as you can grow a team without everything just going to hell. From what I’ve heard on a few of the folks on the show.

Dolapo: Exactly. I’ll say we’ve always been super cautious about it. We think still think pretty deeply about every new person that’s joining the company and what they’re adding. I think you’ll have to remember some of this period of time was in the height of the uncertainty about the economy and tech and the SVB thing was with the various bank issues. So we never wanted to be in a position where we were even considering layoffs and we’ve never had to take any sort of actions like that. But I think there was a period of time there where we were like, okay, let’s write this out and see what happens.

Allen: Yeah, well it’s a pretty wise thing to do. From my memory, I think Browser Company raised a bunch of money when it was really easy to raise money and then it became a lot less easy to raise money pretty soon after that.

Dolapo: Exactly.

Allen: Which is always a little bit of a dangerous place to be where you’re like, okay, are we building a company based on the amount of money that we used to be able to raise or are we based on … So that kind of thoughtfulness I think is always appreciated by employees and users alike.

Dolapo: Yeah, hundred percent.

Allen: The company to keep being sustainable. Cool. So that’s the context of the size of the company. What is the shape of it? So you have an engineering org has grown up to 40 something people, you’re the head of engineering. How have you been organizing it? Is it about your feature teams? There’s a lot of different opinions about this and everybody has opinions, but I still find them interesting. What kind of tactics have you been finding working and maybe not working as you scale back?

Dolapo: Yeah, okay, so stepping back a bit, I think that has been pretty core to how we organize and build is the idea that we need to match people who are excited about the thing they’re working on with the work that they’re doing. So we’ve always been a very energy driven company. There have been periods where we’ve been that way to a fault where we might not do things if it’s like no one wants to do this.

Allen: That’s the huge thing. The first thing that came to mind when you mentioned that is you hear horror stories of Valve. I’m not sure if you’re familiar with Valve and how they’re organized, but it’s everyone just picks what they want to work on. So then it’s like the max steam client is just complete garbage with popups that talk about install start menu icon, and it’s been there for 15 years and nobody wants to fix it because none of them use Max or whatever.

Dolapo: Exactly.

Allen: So I’m curious then tell me about how you’ve approached then this goal of having people who are working on stuff that are energized about keeping from getting into a situation where important things always get done.

Dolapo: Yeah, for sure. And maybe it has evolved a little bit. I would say about a year and a half ago. The way things work is, just to paint a high level organizational picture, we like to work in these really short milestones. We work in six week milestones and we are a startup, so we have these silly rituals around them. They’re all named after produce and kind of alphabetically increasing. We’re in wasabi, which is produce for some reason.

Allen: You’re getting a little … it could be watermelon, but yeah.

Dolapo: Yeah, yeah, exactly. We’ve got X coming up, which is going to be a real puzzler. So we work in these six week milestones and a year and a half ago we would basically look at what the company objectives are were and then create pods every six weeks.

Allen: Okay. Like reassemble teams that maybe have working with someone different you weren’t working with repeating every six weeks.

Dolapo: Exactly. So we would do that every six weeks. It’d be like, this is a pod, it has person A, B, C, D on it, and they’re working on features X, Y, and Z. We would be kind of super thoughtful on those pods based on like, okay, this person is really good at UI polish and that’s the state that this project is in. This person is really good at this other thing or is excited about this other thing. That worked really well for us being able to build things quickly because it was this kind of six week … you only have six weeks to do it, as well as making sure that we could retweak and move things around based on people’s energy. But as you can imagine, reconfiguring a team every six weeks is really messy for a number of reasons. One is just groups of people take time to learn how to work together. It is actually really hard to just be like, you’re working with persons B, C and D now. Good luck. It takes time. Other things is like it worked well … it actually ends up being a little bit more top down than maybe you might expect because I think when you’re not working on something for long enough, you’re not thinking about the-

Allen: It’s difficult for those six person team to come in with a strategic view and it’s like, well, the way we’re really going to choose our business objectives in this area is … I don’t know, I’ve only been thinking about this for four days, so tell me what you do boss.

Dolapo: Exactly, exactly. But I will say it was a really good strategy for the beginning of the company because we were able to really quickly react to what features were working, what functionality was working, and a lot of these sort of initial architecture decisions at the company we made in these sprints. The whole space and sidebar model always done by two or three people working together to just figure that out and building it. Nowadays we are a little bit more, I’m not going to say … we’ve tried to retain our speed and velocity. I think for us that’s the thing that sets us apart from the other browser makers. It’s like our advantage.

Allen: It’s your unfair advantage as the company that’s whatever fraction of the size of some of the biggest companies in the world.

Dolapo: Exactly. So we’ve tried to retain that but have a little bit more stability and be a little bit more bottoms up. So we do longer strategic planning. We still do the pod structure just to maybe protect this idea that these are not super rigid teams. We need to be nimble and make sure that we’re optimizing for the global maximum not little teams. I mentioned that only because I think one thing that you often see at larger companies is once you form a team, that team is just like, okay, we are the team that works on feature X. Sometimes what they’re doing may not actually be the most important thing for the company.

Allen: Well obviously as the company grows, you start to get people who identify with feature X instead of with the company. So they’re like, well, I am a whatever tab, sidebar tab, whatever, some head feature which may end up being not the most important thing or maybe whatever. So you get politics at some scale.

Dolapo: Exactly. Exactly. So we still call them pods, but they last a lot longer. We’ve got some pods that have been around for as long as I can remember our performance instability pod. It’s been the same set of people for the last year and a half. But then we also will have these feature initiative pods that maybe last six months or something, but they last longer than six weeks now, they get to do a little bit more planning. To answer the question around energy is really still very focused. One of the things I still think a lot about is the exact configuration of people and how they work together and how that translates to the thing that they’re building.

Allen: Something that I’ve heard reasonable engineering leaders disagree on is to what degree it’s our jobs as engineering leaders to find work that is energizing for our people versus find people who are energized by. I’m curious, you’ve seen so many different orgs and ways teams could get set up and the higher processes and assignment of work and all these sort of things. How do you think about that? Obviously they’re both important, but…

Dolapo: It’s funny because my natural inclination is towards the latter. That said, I really intellectually and logically want to push back even against the binary because I think that is a mix. You do have to help people understand why something is important.

Allen: For sure.

Dolapo: But at the end of the day, I think performance is a thing that I sometimes use as an example of this. It was really important for us to find people who actually wanted to work on performance because so many people don’t want to do that. It’s a very specific kind of work, so it’s hard to get people excited about it if it’s just not their natural tendency.

Allen: You could show them a chart saying like, no, but look how much better performance could be. These numbers could be lower. 90% of engineers, they’re like, I want to add more buttons.

Dolapo: Exactly. Exactly. Exactly. Yeah. That has really shown up in how our hiring has changed over time. We’re hiring a lot of different archetypes and it’s been interesting because I think it has had some interesting downstream things that I’m still trying to solve. We have way too many interview loops and we’ve just hired some of our first Android people and bootstrapping that was a hard thing because we hadn’t hired them before.

Allen: Well companies that are very rigorous about hiring and are very thoughtful about who they hire and how they hire tend to do better. But there’s kind of an omnipresent angst about, man, we spent a lot of time on hiring.

Dolapo: Yes, a hundred percent. It’s also imperfect. Hiring is imperfect at the end of the day. So yeah, we’ve also had to spend a lot of time on onboarding. I’m a person I don’t like surprises have also have to spend a lot of time being like, this is what working at this company is. Let me make sure you understand that as much as possible.

Allen: This is always going to be true to some degree startup. But are you finding people are sometimes coming in and then being a little bit of like, oh, this is not how I expected companies to work?

Dolapo: I think when I first started at the company, I think we were still very much trying to figure out what our engineering culture was like and what we cared about. We had enough people that had come from different companies that had their own strong opinions about like, oh, I’m from Google, this is how things work at Google. Or I come from Instagram, this is how things work at Instagram. I think we were still very much in this, wait, what do we actually care about here phase? I think we did have to go through a period of just like, no, actually this is what we care about. This is what we care about. Some people left the company as a result, which I think is fine. I think that’s healthy. But I hope that we’re at a place now where we’re much clearer about it through our interviews, through how we do performance reviews, through how we talk to people. Obviously a process.

Allen: That’s really interesting. I haven’t gone through that process. What is something that as a team you care more about than most teams that not everyone would agree with?

Dolapo: Yeah, I’m not picking on Google at all, but one thing, like I mentioned Velocity for instance, we put a lot of emphasis on moving quickly and I think we will sometimes … we’ve had people join the company before who are like, okay, I’m meant to build this feature. Okay, I’m going to go do a thorough research session phase, write a doc.

Allen: Write a peer D.

Dolapo: Get feedback on the doc, and we are just not that company. We have this value that’s make them feel something. For us, the way we work is very much out loud prototype, show it to your coworkers as fast as possible and very much the only thing you need to build is the thing that you think is the key risk with this piece of software. Build that first.

Allen: You’re trying to answer a question, a hypothesis.

Dolapo: Exactly. Exactly. Answer that question as quickly as possible, but do it in the code. We’re also a very distributed company.

Allen: You’re the Browser Company of New York. It says right in the title you have to all be in New York.

Dolapo: I know. It is really funny actually because there’s this little meme that happens where, because we have people kind of all over the world, everyone ends up making their own shirt or logo with their city in it. We did an offset in Montreal, so the swag was like BCNY. I don’t know, I don’t speak French, so I forget what the phrase for four is, but Browser Company of Montreal shirts. So it’s a funny little name.

Allen: Nice. So you’re a distributed company, you’ve got all these different teams rapidly trying stuff. What is the North Star? This trades into product, but obviously you’re Head of Engineering, so you’re involved in all this product stuff. What’s the North Star, if there is one, that you’re all able to get more bottom up? We’re all trying to move towards this. Most artists have one. What’s the holy grail? Either number or, I mean make people feel things like, yeah, but we need to know whether or not, how do we know whether or not they’re feeling things? So how is that driven?

Dolapo: I’m trying to see what can I talk about. I think right now we’re very much in this period. The summer is a really funny period always because it’s for desktop usage, it’s very sporadic because people are taking vacations, et cetera. So growth is always-

Allen: So right. So if our number is down this week or up this week, is it just that people came back from vacation or is it that … Yeah, it’s hard to tell.

Dolapo: Yeah. But we always use this time as building towards the thing for the fall. Right now a lot of our product engineering effort is super focused on, I think Josh has been teasing some of this vision of what the next version of the browser looks like. So that’s what we’re really focused on the product side. But other initiatives that at least I am paying a lot of attention to right now. We just launched Windows.

Allen: Right. Congratulations on doing something non-trivial.

Dolapo: Yes.

Allen: Am I remembering right that a lot of the code is written in Swift, which is not the typical you build a Windows app?

Dolapo: Yeah, and just to give a quick background on that, so we’re a chromium based browser, right? Chromium is this giant C plus plus code base, and a lot of the other chromium based browsers are giant C plus plus applications.

Allen: Sure.

Dolapo: Speed and moving quickly was always a goal of ours. And writing the browser in C plus plus did not feel like it would meet our bar for speed, like our ability to iterate just because it’s not a memory safe language. Finding product engineers and who can be faster-

Allen: It’s C plus plus.

Dolapo: Yeah, exactly. I don’t have to-

Allen: I think most of the people who listen to the show, even if they’re not software engineers, they know that it’s not like the cool rapid development thing of 2024.

Dolapo: Exactly. So we spent a lot of energy making this exposing chromium to a Swift application and so that we could hire product and design engineers who could iterate on product features very, very quickly. Then we were thinking about Windows and at the time there was a small shift on Windows community. So we just engaged with those folks on the side. Were working on de-risking, we use that word a lot, de-risking shift on Windows. Hired some folks, hired one of the people who maintain Swift on Windows. Our Windows application is built in Swift. We don’t share UI, just business logic. The UI in Windows uses WIN UI, which is-

Allen: Okay, so you’ve got native UI on each platform. You’ve got a shared Swift and then shared C plus plus, which is the browser engine stuff.

Dolapo: Exactly, exactly.

Allen: A lot of complexity. But there’s a clever like a foxness to that.

Dolapo: Yes. Honestly it let us get the Windows app out really, really fast because we had to teach people WIN UI, but we actually use WIN UI through Swift Bindings. So you’re still writing and Swift. Obviously it’s a new UI framework and people have to learn that. But it’s been a pretty interesting bet, I think.

Allen: Cool. So when the Arc in Windows, is it fully launched or it’s in beta or private beta now or whatever? I don’t use Windows.

Dolapo: Yeah.

Allen: Nice.

Dolapo: It’s fully out. It’s fully out. You can just go to arc.net and get it. Windows has such a huge market share. But I think sometimes in tech, certain pockets of tech can be so Mac centric that I think people forget that.

Allen: Yeah, well it’s one of those weird dynamics that existed at least 10 but maybe 15 years now where really huge product. Instagram was originally just an iOS only product where it’s obviously can’t get reach its maximum potential. But if you get the early adopters on the early adopter platform that’s smaller than the platform that the world uses, that can sometimes be a really effective way to prove out a product. It’s kind in some ways the default way. So this is a natural thing. I assume it was a debate though. At what point are we far enough along that we’re going to take on, okay, yes, of course we’ll get way more market share if we switch Windows, but this is a lot of time and attention. Are we going to do it now? Are we going to do it in six months or are you going to do it 12 months? Can we wait longer? Can we please wait longer? So you’ve now crossed the chasm. Now you’ve got to maintain all that.

Dolapo: Exactly. Yeah, yeah, yeah. We’re working on Android now too, so it’s about to be a fourth platform, which should be really interesting.

Allen: Yeah, I’m not super familiar with the way that the Android … I’m getting way into the nerdy weeds now. This is the danger of someone with an engineering background talking about leadership and then I’m like, oh yeah, what that programming languages are you using to set up different parts of your app? Maybe a better question, rather than digging into the architecture of the mobile app, we were talking a bit about this. You worked at various orgs, Google, Slack, Meta before it was Meta. You’ve seen different ways that teams have worked and set up and cultural things. Are there any key ideas that you learned or saw in those various adventures that you wanted to bring to the Browser Company or that once you joined you saw like, oh, this idea which worked really well here, now we’re big enough or we’ve come far enough in our journey, we should try to instill this or implement this, tactics that you like?

Dolapo: It’s funny, I think I was at Facebook for six years and so sometimes I have to check myself and be like, am I Meta pilled? But I think Facebook, one of the things that I always thought, Facebook’s engineering culture is really fascinating because they have spent so much energy trying to align individuals like performance with success of the company.

Allen: When you say performance, you mean how people are being graded.

Dolapo: Yeah.

Allen: Which sounds great in theory. If we can just make it so your incentivized, you get promoted. If you make Facebook succeed as a company, then the whole rest of the thing is Warren Buffett’s incentives mindset.

Dolapo: Exactly. Exactly. It sounds simple, but I don’t think, and I know Google has changed a little bit since, but it was interesting to me coming from Google because I think Google really rewarded things like technical complexity and technical excellence. So I would see people really get rewarded for working on complex problems.

Allen: We can all just very quickly imagine if you reward people for complexity, you’re going to get complexity.

Dolapo: Exactly, exactly right. But on the flip side of it, because Facebook was very much driven by these short six month, did you have impact cycles, you’d see all these strategy shifts happen all the time and with huge downstream effects on look at what happened to newsfeed distribution and news publishers and things like that. It’s just like these are tiny little company strategy shifts that actually affect people in the real world. I don’t know. I’ve always wanted to make sure that folks on the team felt really, really, really connected to a company and business impact. I think it’s a thing that we’re still kind of playing with and tweaking and how we align teams and reward people’s performance. But to me, this really connect how well people do to company and business impact is such a strong thing for me. The other thing that I think about sometimes, which I don’t fully formed a full world view on this, is that Browser is complex. It’s just a very hard problem. Culturally trying to build a team of people who can tackle this problem and not create a team where there’s egos.

Allen: Sure.

Dolapo: Has been fascinating because I would say by and large, we pride ourselves in trying to hire humble people. So we’ve kind of assembled this team of people who I think are really pleasant to work with, but also, not to brag on my team for a little bit, but the best of the business, it’s just kind of like an incredible pairing. I think sometimes you go-

Allen: But it seemed from the outside, from early days of Browser Company, when I would see, oh, this so-and-so has joined the Browser Company. I’m like, oh wow. They know how to hire. That’s been an interesting thing. I always should follow up a little bit on how you all do that, but I’ll let you finish your thought. I just wanted to interrupt you to agree with you that you do seem to hire great people.

Dolapo: I think sometimes you see environments like that, but the culture is toxic or people are jerks. But we have a team that is exceedingly, exceedingly pleasant and exceedingly nice, almost to a fault. But it’s great. It’s a nice combination.

Allen: Interesting. I could see that being a problem when you’re trying to hire a team that’s humble, but they can’t be so humble that they don’t think that they can create the first new browser in a generation, right?

Dolapo: That’s exactly right. Yeah. You have to have some daring, right? You have to be confident, if that makes sense.

Allen: There’s this idea that was going around recently about the difference in between people who are bad stubborn versus good stubborn. If people are persistently pursuing a goal versus just arrogantly being like, well, my way or the highway, and this is the only way that works. Which is something that I think of when you think of a humble person that still believes they can achieve a great thing. It’s like by persistently learning and iterating rather than … because they’re so amazing.

Dolapo: I hadn’t seen that, but I really like that. I like that framing. That’s good.

Allen: Stepping one layer back to the thing that we mentioned before, which is hiring. Obviously you’ve been growing this team relatively rapidly and you’re working on quite unusual problem. Most people don’t work on a browser, most companies don’t have the browser, and you’re even doing it in a bit of an unusual way where it’s way more experimental with UI and product and what even should a browser be? Also, Swift on Windows and you have all these sort of complicated requirements, and the culture that you’ve now kind of crystallized into this is the culture. What are the tactics that you’re using to bring in and hire and then retain these top caliber folks that are core to actually bringing that about?

Dolapo: For sure, and I think our team just has such a building a browser. We have such a breadth of different skill sets and archetypes. It’s everything from chromium engineers, I mentioned Swift, so we have LLVM and compiler engineers, product engineers, performance and stability folks, some folks working on ML and AI. It’s just like this breadth. I think for us, we have always been good at playing a long game with some folks. So there are folks that have taken us over a year to hire, and I think it’s something that Josh, our CEO in particular has been like … he’s very good at building these long-term relationships with people. To use myself as an example, I was talking to them for a year before I joined. So we have a number of people that we’ve been talking to, checking in with, seeing how they are, because you never know where people are going to be. To go back to this, people who want to challenge, we do tend to attract people who want to solve a really hard problem. So I think for some of the Swift and Swift on Windows chromium kind of archetypes, we have been lucky because there are a number of people who are like, I am a programming language person and there are not that many places that I can actually work on a problem like that. Then I think the other thing that really helped is our building our brand has always been a big focus for us. So I think we were able to build a strong brand early with the same set of folks that we were also trying to hire, if that makes sense.

Allen: Yeah. That’s one of the famous things where people talk about, some startups will be like, well, we’re going to be stealth for the first five years. It’s like, yeah, you can do that, but then how do you build … there’s obviously multiple problems with that, but one is like, how do you hire really great people? No one knows who you’re what your deal is.

Dolapo: Exactly. So we have had a number of people we’ve hired who they’ve used Arc, they know what it is, they learned we were hiring, they followed our Twitter, other marketing presence and just reached out. That has actually been super helpful.

Allen: Again, I’m asking questions outside of your domain, so you shrug if you want, but how intentional is that when you’re making marketing choices, you’re thinking about what kind of marketing you’re doing or the tone of it? Is it like, oh, we’re 80% talking to developers or to potential users and 20% talking to potential hires, or is it just entirely user focused, but because the users are often developers, because developers are often adopting this stuff, then it just accidentally works?

Dolapo: More the latter. I think more the latter. I think our early messaging, we’re playing around with new things now, but our early messaging, a lot of it was on Twitter. I think we have done a lot of video type experiments, but we gained a lot of traction pretty early with the design community and the product eng community, and that was really helpful, I think, for hiring.

Allen: Nice. Well, that’s a tip for everybody if you’re building a business, then make your first user speed designers and builders, and then you can just hire them. You hire these people, you got them on board, then you have a great hire pipeline. How do you retain this talent density?

Dolapo: Yeah, yeah. We’ve been pretty lucky so far, and I don’t know. For me, I feel like engineers tend to stick around if they feel like they believe in the mission, they feel like they’re growing and they have the ownership and scope that is commensurate to where they are in their career or what they’re trying to do. In a lot of ways, I think we’ve been pretty lucky there. The product is successful and growing, so that keeps people motivated and happy. There’s no shortage of impossible problems, which I think is helpful for you.

Allen: Use that terminology internally. Will you refer to it as impossible or is that just kind of our flippant, just building in the next big browser is impossible, roughly impossible, right?

Dolapo: I’m being a little flippant. I’m being a little flippant actually. I would say sometimes internally I just feel like we go the other way where we’re like, yeah, we’ll just do thing X.

Allen: Yeah, we’ll just put Swift on Windows.

Dolapo: Yeah, exactly. It’s just code. It’s fine. Yeah, so I think those two things is what I would attribute it to. I think I’ve worked at startups before that have been on this part of the journey of this trajectory and it’s just like, it’s fun.

Allen: There was a flip part of a question. I asked you something that I realized I didn’t ask you the other half now looking at my list. I’d asked you about cultural things that you’ve sort of prioritized. It’s like, okay, this is something we prioritize velocity at the Browser Company. We want speed that we’re answering questions and stuff like that. What is something that you sort of intentionally don’t prioritize where maybe other orgs do?

Dolapo: That is a good question. Yeah. I think there’s things that I feel like, oh, this is a dangerous question. I think there are things we’re definitely bad at, and in some ways some of them like we should be better about that. I think we’re could be better with documentation and testing and all those things, but that’s not because we don’t intentionally prioritize them.

Allen: It’s not like you have your cultural values, just like documentation is dumb. We’re never writing comments.

Dolapo: Yeah, yeah, yeah, yeah, yeah. But I don’t know. I don’t have a great answer to that question.

Allen: Yeah, it’s interesting. It’s something that I think about sometimes when we talk about values and hiring values and promotion values and engineering team values and all of this is that this idea. I used to be very, I used to think I had it all figured out. I would come up with these value statements for my team where it was just a bunch of things no one would disagree with.

Dolapo: Oh yes, sure.

Allen: Oh, of course. We make good software for our users and we care about being kind and also being effective and being fast and being correct. It’s just like, yeah. But then a few folks and mentors that I’ve had the fortunate chance to learn from over time started to say things like, yeah, if no one would disagree with these values, then they’re not meaningful. Whereas that’s which is what keep me into it. I found interesting your comment about velocity, being willing to trade that off for other things and being willing to say, not falling into the hole that sometimes young companies or earlier career engineering managers will get into this mindset of, well, if an engineer on my team doesn’t like this value, maybe we’ve taken it too far.

Dolapo: Right. Yeah. It is funny that you mentioned that because we actually went through that same process as we were writing our values because it is this question of for each one, you have to be able to articulate what they trade off against. The reason I’m kicking myself is because I’m like, oh, I should remember everything about that exercise, but I’ve now forgotten some of the more salient ones.

Allen: Other higher priority things going on then what were the two years ago when we made this doc?

Dolapo: Exactly.

Allen: So before we went out of time, one last thing I want to kind of give you an opportunity for, you’ve been in a lot of high growing orgs and teams and situations, whether it’s like, okay, stories is a thing, or Slack and all these various phases. You can take a second to think on this if you’d like, but what’s a hard one lesson for you that you’ve seen going through these different growth loops that would maybe useful to send back to your previous self?

Dolapo: Yeah, I think that a couple things jumped to mind and one of them, because I think you mentioned stories and we’ve been talking a lot about de-risking and this idea of figuring out what exactly is the hypothesis. I’ve been in situations where there’s been urgency created to solve a problem, but there was a lack of clarity around what … I think we had this at Foursquare. I was at Foursquare at a point where we looked at the consumer applications and it felt like they weren’t growing, and the company felt like, okay, we need to do something. And in the end, Foursquare did this thing where we split the two apps and it was such an interesting moment. I think we were trying to do it kind of quickly on a rapid timeline, and it was like when you’re going through these moments of making these kinds of changes and it’s very easy to get just fall into the how and making the thing happen that have you built a process of actually questioning and testing the hypotheses along the way.

Allen: Oh, we’d be doing the right thing. We don’t have time to ask. We have to do it rapidly.

Dolapo: Yeah, exactly. Exactly. It’s so easy. It is so easy to fall into this. I feel like some of that happened a little bit with stories as well. It was like, well, we got to do it in two months. You end up with these messes where it was, for stories, I think there was a different stories product on Messenger from Facebook, which doesn’t make a ton of sense, and so just thinking about your role as a leader and myself is just, yes, I need to be in the details in an execution mode, but I’m also supposed to be the person that’s week over week sort of like, okay, what are we doing and why are we doing it? Otherwise, you lose the forest for the trees and it’s very easy to do that, I think in these high velocity moments.

Allen: Yeah, that makes sense, and I can see why it would be especially true and critical when it’s like about the company moment.

Dolapo: Yeah, exactly. Exactly.

Allen: Awesome. Well, I appreciate you taking the time to chat and sharing some of what you’ve learned. How can people go to find more about you and what you do?

Dolapo: Oh, that’s a good question. Obviously arc.net to find out more about what the Browser Company’s up to and to download the browser, we actually read a lot of our feedback, so if you have feedback on that, you can submit it through the app. I am actually very bad about being on social, but I try to respond when people message me on LinkedIn and I’m at Dolapo.io, which is a domain that I was very happy to get.

Allen: Cool. Well, I’ll link those up in the show notes. Thanks again for coming in and joining us.

Dolapo: Yeah, thanks so much.

Allen: It’s Shipped That Way is brought to you by Steam Clock software. If you’re a growing business and your customers need a really nice mobile app, get in touch with Steam Clock. That’s it for today. You can give us feedback, follow us on social media or rate the show by going to itshipped.fm/contact. Until next time, keep shipping.