When AI Writes All the Code, Who's Watching? with Kayvon Beykpour, Cofounder & CEO of Macroscope

Today, we're talking to Kayvon Beykpour, cofounder and CEO of Macroscope, about what happens after AI writes all the code. And you're listening to Joel Beasley, Modern CTO.

So what is a Macroscope?

We sort of think of it as a command and control center for your software development. It helps companies do a few things. Firstly, it helps you understand what is happening at your company. So like any other software team, you've got a bunch of code being shipped, you've got a bunch of engineers and agents working on things, and oftentimes, whether you're a product leader or whether you're an engineering leader or whether you're the cofounder and CEO, you just want to know what's happening. What are people working on?

What progress are we making against our priorities? How are things changing both in the code base and also visually in terms of how our users and customers might notice them? Macroscope solves that problem for you automatically using the code base. Rather than you having status meetings and sending emails back and forth and ClickUp messages and Slack messages, Macroscope just looks at the code, leverages LLMs to sort of make sense of what's happening and articulate it to you and anyone else who cares about it in terms that are really easy to understand. Whether that's 140-character updates or whether that's more of an executive summary, you can kind of define these formats, define these cadences, and understand the status of things.

So that's one thing that Macroscope does. And then the other is that we do automated code review. So agents are now writing most of the code that teams are shipping. And because of that, a ton of code is being produced and it's becoming extremely hard for humans to review all of this. The bottleneck is code review much more than it is code generation.

And so it's really important for any software company to have a really robust sort of defense layer around what's getting merged into production. And that's where Macroscope's code review comes in. We think we've built the best signal-to-noise ratio of any code review tool, meaning we can find the most issues with the least amount of noise, noise being false positives. No engineer wants to see a bunch of noisy comments on their PRs. And so Macroscope, you know, because of a bunch of technical things that we've done, which I'm happy to talk about if you're interested, we think we've built exceptionally good signal-to-noise code review.

And then the third thing that we do is we've built a programmable, customizable agent that has the best understanding of your software development life cycle. So our agent can research the code base. It can answer questions about how the product works, how the code base works. It can understand the status of things as I talked about with our status product. And you can sort of design agent prompts that respond on demand and on scheduled automations or on triggers.

And you sort of have this very customizable agent that you can use to answer questions, solve problems, fix bugs. Like, we have an agent that runs every night looking at our GCP logs and looking at any sort of abnormalities, whether they're bugs or whether they're just inefficient logs or warnings that are cluttering our logging system. And it will just cluster the most important or severe issues. It'll investigate why those issues are happening. It'll post PRs to solve them.

And so by the time we wake up, we just have a bot that's been like, "Hey, these three things happened overnight, and here's three PRs that fixed them." And so you can sort of design any agent that has a really robust understanding of your code base and have it plug into all the important parts of your system. So those are, in a nutshell, the three things that Macroscope helps customers do.

That's pretty cool. Now you were the CEO of Periscope. I know that people remember that. How did you go from Periscope CEO to this startup?

You know, the through line is actually more consistent than it sounds. I think, you know, this is the third company that I've started. The second was Periscope. And then before that, I started a company that made mobile apps for universities. This is right when Apple released the App Store.

And so we were actually the first education app on the App Store. We made an app for a university. It was called iStanford. And the reason we built that is the reason we built Periscope, is the reason we built Macroscope. And it's very simple.

It was very selfish. We just wanted to use a product that we couldn't find existing in the world, and so we built it ourselves. We just want to use the product ourselves. And so it's sort of born out of personal frustrations or problems that we've had. In the case of Macroscope, the motivation for it was I worked at Twitter for eight or nine years.

It was, yeah, around nine years when, you know, we started Periscope and eventually got acquired by Twitter. I went on to lead the product and the engineering team, the consumer engineering team at Twitter. And, you know, at a company at the scale of Twitter, the problems that I mentioned happen all the time. Right? I was the head of product. It was my job to understand what progress are we making against our roadmap. You know, I could tell you at any given point what are the three most important things that we should be doing. I would have no idea whether the 1,200 engineers at Twitter at the time were actually working on those things. And to solve that problem, like any product or engineering leader in the pre-LLM era, to solve that problem, you just had to have a bunch of fucking meetings. Or look at Jira or send a bunch of email updates.

And by the time an executive would get an update on what's happening, a, a bunch of engineers would have had to waste their time writing status updates; b, that information is out of date by the time it gets to you. Right? Because it's going through so many games of telephone to get to you that it's old news. And three, there's a bunch of bullshit in there. It's like people kind of self-report what they want you to hear rather than what's actually happening.

And so our feeling, a, this was a huge pain point for me. This was my least favorite part of my job as the head of product was just the game of telephone to understand what's actually happening. And at large organizations, I would venture to bet that every product leader and engineering leader hates this part of the job. It's just extremely inefficient, lossy information transfer. And so when, you know, we were thinking about what we wanted to build next after we left Twitter, my cofounders and I, this was just such a visceral pain point that we felt because it's extremely important, right?

Any executive at a big company needs to understand the status of things. Every engineer who works at a company like this hates this part of the job. They'd rather spend time building than spend time communicating what they built and what they're working on. And no one wants to go to meetings. And so it just sort of occupied this brain space for me of, like, I hate this part of the job and this new wave of AI tools ought to be able to help solve this problem.

And so it was as simple as that. We just wanted to be the change that we wanted to see in the world. And again, no different than the other two companies I started. There were sort of very discrete pain points that I felt and my cofounder felt, and we sort of just assumed, okay, if we built something that we like, hopefully there's other people out there that would like it as well.

Wow. It's interesting because I've seen a lot of—there's a lot of tools that focus on productivity, at least in a sales cycle. They're talking about we can make the engineers more productive. We can make your engineering more efficient. But I really like this. I guess, for me, it's a breath of fresh air, this idea that, hey, the executives need this information, and we're able to use these types of tools to create this information. So that's the status component of your product offering, right?

Yeah. And it's the symbiosis where it's finally an AI tool for the executives, but it also helps the engineers because in that it's helping answer questions that the executives have, it's also saving the engineers time from having to be the source of that information. As an engineer, you'd rather have your work speak for itself rather than you have to rearticulate, like, "Hey, Joel, let me tell you what I worked on over the last 48 hours." That's dumb if the AI can just figure it out.

So it's saving you time from having to spend time doing status updates, and it's also helping the executive who needs to know. They get to know faster. They get to know in the format that they want. Joel might want a more technical summary of what's happening compared to Kayvon. The sales executive wants a different altitude of update than the technical CEO, than the head of engineering.

The head of engineering might want to know, "Show me what the productivity of the team was." The head of product might want to know, "Tell me how we evolved the product relative to our priorities," and the CEO might want to know a little bit of everything. And so it's sort of like everyone gets whatever format and altitude of information they want without any engineer having had to waste any time.

Oh, it's properly named as a product—Macroscope. I like it. Now tell me this. AI code review, obviously, code review itself is a big bottleneck in software engineering. Now that we can generate code even faster, it's even more of a bottleneck. And AI code review seems to be the answer. However, how do you go from how things were to building enough trust with an AI code review tool? How do you go from that?

I think there's a couple things there. You know, one, like many AI coding-related tools, the trust gets built slowly and then all at once. Right? For months, if not years, engineers started getting used to tab-based autocomplete. Right?

They're still living in their IDEs. They were kind of using these AI autocomplete tools like Cursor, and they were like, "Okay, this is getting pretty good." And then the first agents started becoming popular and they were not very reliable at first and people used them sparingly for sort of low-complexity things. And then as the models got better, as Opus 4.5 comes out, so on and so forth, people are like, "Oh, shit. These things can actually do a lot more than they could do a couple months ago." And the same arc of trust, I think, existed with code review tools where at first, you know, they were useful for narrow types of things. When we first started building Macroscope's code review feature, the models were—they were good enough that we felt that there was promise here, but not good enough that you could afford to just blindly trust the code review tool. And I think the amount of progress that has been made in the last year and a half is pretty striking to the point that, unequivocally, AI-based code review tools are better at finding bugs than humans are, period. There's just zero doubt in my mind and in any sort of reputable software team that has actually tried these tools.

Humans are actually terrible at finding bugs. Humans are really good at assessing architectural things. Did we build this the right way? The AI systems, I think, are still not as good at that class of concerns. Excuse me.

But being able to thoroughly and unrelentingly look through your code and also how your code impacts the rest of the code base, the AI systems are just better. They're just better at doing this. And I wouldn't have said that a year and a half ago. But as teams try these tools and experience how thorough the tools are at finding bugs, finding correctness issues, then I think it becomes—it becomes actually a very fast transition. The teams get used to saying, "Hey, between what my coding agent is able to do on the first pass as it's actually implementing the work and what the AI code review tool is able to do in terms of finding these things that slip through that are correctness issues, human attention can move towards the higher-leverage thing, which is not looking for bugs. It's more assessing, is this a change that I even want to make?" If you have, you know, the most AI-filled engineers now have multiple coding agents working on multiple tasks, right?

And so before you know it, the team—you have all these PRs that are landing and you're like, "Do we even want to fucking change this? Is this a positive change that we want to make into the product?" That's where the human attention is actually the highest leverage. And so I think the teams that are most on the bleeding edge of leveraging AI tools, as it pertains to code review, this is kind of what you're focused on. It's like, "Hey, is this architected the right way as a technical change? Have we reused the right systems? Have we built this in the right way?" And, b, "Is this even a change that we want to make right now?"

And that could be a technical consideration. That could be more of a product consideration. Like, do I want the UI to work this way? And so I think that's the new norm, is the PR, you know, it's more of a change request for the company than it is a pull request for merging something into Git, if that makes sense.

Yeah. Are we—when are we going to see the end of human code review? Do you think the technology is already there? It's just behaviorally we're not there, or do you think the technology still needs to catch up?

I think there's still things missing from the technology. For example, just to name one, you know, whether the code compiles, whether there are any correctness issues is not sufficient. A good code review doesn't just focus on those two things, right? It's also, you need to be able to—if you're really doing a rigorous job, you need to be able to use the product.

Okay. We added these front end features. Or maybe it's a more complex thing where we added a bunch of UI changes. We did some database migrations. We have some new endpoints. And the actual customer-facing thing that we're going to ship needs to be validated by actually using the feature. And most, if not all, code review tools right now aren't actually satisfying that test. Right? They're able to do lots of useful things by having an agent look through the code, maybe even compile the code. But they're not necessarily doing a full usability test.

They're not running a browser and clicking through the thing and taking a screen recording and asking the question of, "Does this behave the way I want it to?" And so that's just one example. I think the end of human code review would at minimum require that to also be automated. Right? You want to catch those types of things before a feature merges into production.

And so I think if you want to eliminate the need for humans to look at PRs, you need to be able to bite off more classes of things that currently code review tools can't catch. You need to be able to tackle the full set of things that humans do when they're doing a rigorous code review. I think that's possible, and I think that's a really interesting and worthwhile problem to solve, but I don't think we're there yet.

(Joel Beasley at 00:15:54) And that's when you get into the messiness of the definitions because code review at one company can just be reviewing the pull request. Code review at another company could include the actual integration testing, like manual. There can be different specific descriptions of what a code review entails at different companies. And so what you're saying is you think for it to get fully automated, it's going to have to do the best possible everything to say, essentially, I'm giving you this outcome I want, and it comes back to me proving to me that it achieved the outcome.

(Kayvon Beykpour at 00:16:26) Yeah. I mean, this is putting aside whether this happens at the coding agent stage or the code review stage, I think what I expect, if I'm going to delegate the implementation of something, some feature that we want to build into the product, I'm going to delegate that to an autonomous agent. It needs to be able to prove that it built the thing and that it works and that it fits our bar for the user experience as well as correctness, as well as our idiomatic conventions in the code base. Like, all of the things that a software team today kind of considers the end-to-end set of requirements. If the agent or some agent can't accomplish all those things, there's still human in the loop.

(Kayvon Beykpour at 00:17:16) Right? Like, the agent can write all the code. They can test for all the bugs. But if it's not able to also do the full usability test, it's just not responsible for you to ship that. I mean, maybe a daring team that doesn't have any customers that depend on the thing working, maybe they'll still ship it anyway and figure it out later.

(Kayvon Beykpour at 00:17:37) That's fine. But I think for a mature software organization that has a high bar for, like, we can't screw things up in production. We should catch them earlier. You can't fully delegate that to the agent unless it's able to do everything the human does today before deciding to merge the thing. And there's other considerations too.

(Kayvon Beykpour at 00:17:57) Right? Like, you know, we updated our APIs. We have to make sure our documentation is up to date. We need to be able to inform our customers if this is a breaking change or a non-breaking change. You know?

(Kayvon Beykpour at 00:18:07) There's a whole set of operational considerations that every team has processes for. Oh, this is behind a feature switch. When do we flip the feature? Like, we've merged the code, but the feature switch is still off.

(Kayvon Beykpour at 00:18:18) Like, it's not as simple as saying it's now in production. Right? Like, there's a whole bunch of things like that that the humans are the glue right now. And that's fine. We still have agents helping us with all the rest of it.

(Kayvon Beykpour at 00:18:30) But I think to truly unleash the omniscient AI system that can just self-improve and make the product just get better every day. Like, there's a lot of other things to build.

(Joel Beasley at 00:18:43) For sure. But it is happening. So last night, I had a meeting with my business partners. We own some Bitcoin mines, and I had a meeting with them. And we have three mines up now, and so we needed this dashboard.

(Joel Beasley at 00:18:57) All the technical dashboards, they'll show you certain data, but they don't show us the data we care about in the executive meeting. And so they said, hey, Joel. Can you build something like this? And I said, yeah. Yeah.

(Joel Beasley at 00:19:08) I can. And so I went down, jotted down some notes, had a conversation with Grok and Gemini, and basically created a spec sheet and a description that I was going to send to one of my developers that I've worked with for 15 years and just have him put something together. And I sent it off, and then I thought I had two hours last night of free time, which is unusual because I've got three kids, but I had some free time. And I said, you know what? Let me just see what I could do.

(Joel Beasley at 00:19:36) And within two hours, I had the dashboard completely operational. And so I followed up, emailed to my buddy, and I was like, hey. We actually don't need to do this because it's working. And I was so surprised. I just told it to go read the API.

(Joel Beasley at 00:19:51) It was a back and forth conversation that took about two hours, and the byproduct was a single page app that achieved exactly what we had talked about. So my net time investment was three hours, an hour of talking to it and two hours of working with it. And then I took a screen video. And by the way, I did it all from my iPhone. And it was wild because Grok will let you have HTML, like, single page apps, and it'll play them and you can use it.

(Joel Beasley at 00:20:16) And so I was blown away by my experience because I've been in software for 20 years. I've been building software systems for 20 years. And the fact that it was that great, I achieved the outcome in three hours. That blows my mind.

(Kayvon Beykpour at 00:20:33) This resonates with me a lot because I have so many almost daily experiences like this between work where obviously we're using all the things and personal. First of all, I feel like I'm constantly in agent obsession mode, which is borderline unhealthy. It's like if I'm not, if my agents aren't working for me, I have anxiety. I'm like, when I'm driving from work to the office, I'm like, fuck. I forgot to start the agents on a task.

(Kayvon Beykpour at 00:21:03) I'm the opportunity cost of not burning tokens right now is too high. And then on the weekends, you know, I've like many others, I'm really into OpenClaw right now and playing with...

(Joel Beasley at 00:21:14) Me too.

(Kayvon Beykpour at 00:21:15) What I can do with OpenClaw. And so my new thing on the weekends when I have a moment of freedom, because I have two kids, not quite three, but it's still a handful.

(Joel Beasley at 00:21:26) It's a lot. Yeah.

(Kayvon Beykpour at 00:21:28) My move is I'm grilling outside. I've got a moment of peace, one arm on the grill. I've got my iPhone with Telegram. I'm just dropping voice notes to my OpenClaw. And it's just the feeling of magic of being able to drop a 60-second voice note where you're just rambling.

(Kayvon Beykpour at 00:21:46) You're just rambling this dream you have. And then two minutes later, once you've turned the steaks over, you've got, makes a repo, commits a bunch of code, deploys it to Vercel, sends me a preview link, and I'm like, yeah. That's great. Awesome. Like, problem solved.

(Kayvon Beykpour at 00:22:02) You know? It's a whole new world type experience. And it's very amazing to see that loop of dream to usable product that is accessible. Like, in the OpenClaw context, I can send my wife a little micro app I built for our house, and she can use it two minutes later. And in the work context, the example I had recently, do you know about Retool?

(Kayvon Beykpour at 00:22:31) Like, the company Retool? You know, very incredible company. I love Retool. We've built a bunch of internal tools that our company depends on in Retool.

(Kayvon Beykpour at 00:22:44) And, you know, as a technical person who now that I'm CEO, I spend most of my time not writing code, even though I do get in there every once in a while. I spend a lot of time doing commercial stuff, sales, whatnot. Retool before LLMs was my way of adding value where I could get in there and not screw things up in the code base, but help build internal tools. It went from being the fastest way for me to build tools to, as a team, I could comfortably say Retool was the slowest part of our development stack because in a world where you can use Claude Code for everything, having to do a WYSIWYG tool builder was just really, really slow. And like you, in your Bitcoin mining project the other week, we just got to a point where we were like, ugh, can we, we just need to rebuild.

(Kayvon Beykpour at 00:23:31) We need to take everything we've built in Retool over the last year and a half and just build our own internal tools so that we can use Claude Code. And basically, I don't want to say one shot because it wasn't a one shot. It was more like a couple hours of work, but we were able to basically replace a year and a half's worth of Retool apps that we built in a two-hour Claude session. And it's just, it was mind-blowing how well the models do when you have a really structured app that you can give and say, hey. I want to refactor this into something that's not in Retool.

(Kayvon Beykpour at 00:24:09) So, yeah, it's a whole new world.

(Joel Beasley at 00:24:14) And it's amazing to see. I've seen some great stock stories about companies who have large percentages of their revenue coming from, like, rewriting existing code bases. Their stock price dropping as AI. And I was like, you know, because that's an excellent use case. Rewriting existing or porting existing code bases for the AI is pretty decent at.

(Kayvon Beykpour at 00:24:36) For sure. Yeah. I think a lot of the success of these, these tools that started, like, the first agentic autonomous coding agent type tools like Devin and Factory, a lot of the use cases that we hear from customers were super effective in leveraging those tools for early on was these code base ports from legacy systems. Like, you have some COBOL system or whatever and porting that to a more modern stack. Like, these systems are actually really good at doing that.

(Joel Beasley at 00:25:14) Let's talk more about this little project. So one of the things I noticed is my cofounders and I had to have the conversation, identify this need. And then I had to go talk about it to get the exact specs of what we wanted as a group and, like, how do I communicate that this is what we want. And then I would take that, and I could go to, you know, an engineer. And because this is just the smallest scale of this happening.

(Joel Beasley at 00:25:41) Right? And it has that whole added communication that if I take it to an engineer, I have to take the entire conversation that I've had getting the AI up to speed and then translate that and re-communicate all that to the engineer who will then think of problems. But instead, I could just interact with the AI directly, communicate with it in plain English, and out comes the byproduct. And then I see things like Jack Dorsey laying off half of his company from efficiencies. And then the question for me is, well, what's going to happen across the market as a whole?

(Joel Beasley at 00:26:17) What do you think we're going to see? Like, large, I don't want to, I'm not trying to scare people. I'm just trying to, we're engineers. It's like, do you think other companies are going to follow suit? Do you think they're going to reallocate those jobs? Do you think they're putting their head in the sand?

(Joel Beasley at 00:26:28) Where do you think the other companies are?

(Kayvon Beykpour at 00:26:31) I think it really depends on the stage of the company, but I think the reality is most large organizations are too big. And this is, put AI aside for a second. Like, in the last five years, people just overhired. I think this was one of the impacts of COVID. You know, we saw it at Twitter, and I think it's true for a lot of other large companies.

(Kayvon Beykpour at 00:26:54) Like, they just, they hired too many people. They hired too fast and, you know, it's not the case that at a large organization that if you double the size of the team, your output doubles. Like, if anything, things slow down. Work structures need to change, communication becomes more difficult. And so I think there have been corrections and there will continue to be corrections. Like, you've seen a lot of big companies like Google and Meta already do enormous corrections.

(Kayvon Beykpour at 00:27:22) And I think my read on the Block changes was they were in part motivated by correcting. Right? Like, they just grew a lot, and I don't think they had corrected as much as other companies had. Obviously, the AI motivation is an independent one as well. Like, I think in theory at an organization at that scale, engineers ought to be way more efficient, way more effective with less than ever before.

(Kayvon Beykpour at 00:27:54) And I think, you know, whether Block is already experiencing that or whether this is a forcing function to achieve that, you know, I don't know. I'm not an employee at that company. But I think it is certainly like, if I was running an organization that size, I would absolutely be making sure our team was as small as, you know, as small as it needed to be and not any larger because everything is worse when the organization is larger than it needs to be. And I think, you know, sometimes you need a really disruptive push, a really disruptive forcing function, as unfortunate as it is that people's jobs are impacted. You need to jolt the organization.

(Kayvon Beykpour at 00:28:38) Like at these big companies, it's not the case that people just wake up on their own and embrace the new norm. It's the exact opposite. Like people are calcified in their ways. People are comfortable. This is not a critique of Block.

(Kayvon Beykpour at 00:28:52) This is a critique of big companies in general. They're just resistant to change. They're comfortable. Like, one of the reasons, you know, maybe not a completely fair generalization, but a hot take. Like, one of the reasons people oftentimes go to big companies is that they are risk averse.

(Kayvon Beykpour at 00:29:10) And so when something as disruptive as what we're seeing in AI happens, it's not like they're just automatically embracing it. They need to be jolted. They need to be incentivized. They need to be inspired. They need to be pushed.

(Kayvon Beykpour at 00:29:23) And I think a big correction, like, hey. We are saying goodbye to a bunch of people, and the expectation is we're going to do a lot more with a lot less and we're going to embrace these tools across product, marketing, and engineering and sales and all the things. That is one way to jolt the organization. So, you know, I think different companies are going to embrace that at different times, but I think it is a must. It's not a nice to have.

(Kayvon Beykpour at 00:29:52) Like, if you as a company are not embracing this new way of working, you are cooked. You're not going to make it. So you might as well jolt the team earlier rather than later.

(Joel Beasley at 00:30:05) I like that perspective. You're right. That is, it's a great way to shake everything up and set a new standard, I guess. Say, hey. There's a big massive change that creates a lot of chaos, and then they're like, this is the new standard.

(Joel Beasley at 00:30:20) It gets their attention.

(Kayvon Beykpour at 00:30:22) Yep. Yeah.

(Joel Beasley at 00:30:22) I've never worked, look. I've never worked at a big company. I've built three startups, built small engineering teams and then sold them off. I never have had the experience of working at a large company, but I talk to a lot of people who have. And that's because I'm just too much of a doer.

(Joel Beasley at 00:30:38) I'm too much of a problem solver and a person that just has to go take action. I don't want to ask for permission. I just want to go do things, and that's just, you know, byproduct of my personality. But, yes. So I've never been really attracted to the moment I see the rules and the processes and the gunk is what I call it, I'm just like, no.

(Joel Beasley at 00:30:59) I'm good. I'm going to go back.

(Kayvon Beykpour at 00:31:01) Work for it. It does feel like gunk. It's organizational gunk for sure.

(Joel Beasley at 00:31:06) Mhmm.

(Kayvon Beykpour at 00:31:07) I, you know, I hear you. I feel like I'm wired the same way. I feel like the reason why I've started three companies is that I'd rather get shit done and build things than talk about stuff. And I think that vibe is, it's oil and water with how big companies work.

(Kayvon Beykpour at 00:31:33) Most in at most companies. But there is tremendous opportunity in making big companies have a culture and a vibe that is more like that. I think incredible things can happen if you can get large organizations with the scale of distribution and the brand, all the positive things that come with a big company. If you can get big companies to operate that way, incredible things can happen. And I think that's what a lot of these founder CEO types like Jack and Zuck and, you know, any other, Elon and

(Kevan Baikpour at 00:32:11) Yeah. I mean, Elon, obviously, all of his companies operate at an extreme in this way. I'm sure they have their own versions of gunk. You can't be a 100,000 person company without having some gunk, but I think it's an incredible challenge and an incredible imperative to get organizations to have the right amount of startup DNA to be able to ship quickly and impact positive change as quickly as possible.

(Kevan Baikpour at 00:32:44) This is one of the reasons why I stayed at Twitter as long as I did. I wanted to make Twitter operate more like that as much as possible. And yeah, I think every one of these big companies is going through their own version of that right now.

(Joel Beasley at 00:33:02) And you got to Twitter through the Periscope acquisition. And then, can you just, for people who don't know, can you just remind us what Periscope did?

(Kevan Baikpour at 00:33:11) Periscope was a live streaming app. So we let you take your phone out, press a button, go live, and broadcast to anyone in the world. And people could join and not just see what you were seeing and not just talk to you, but interact with you in real time. So one of the things that Periscope did that was novel compared to any other live streaming app at the time is that we actually built extremely low latency video. Despite the fact that it was a one to many broadcast where you could have millions of viewers, we were able to make the experience extremely low latency, meaning your viewers could actually have a conversation with you. You know, you could be broadcasting some concert you were seeing and the viewers could be like, "Hey, Joel, who's that on the stage on the right?"

(Kevan Baikpour at 00:33:59) And you would see that comment in less than a couple seconds and you would be able to react and, you know, change the camera or answer the question or whatever. And at the time, back in 2015 when we launched Periscope, that felt like magic. That was like, there was no such thing as a live broadcast that was one to many that had the latency of a FaceTime. You either had FaceTime or Google Meet or whatever, but that was super low latency, but a closed room. It was a WebRTC based connection so you could have a one to one or maybe like a, you know, six people or something in a chat.

(Kevan Baikpour at 00:34:34) Or you could have a live stream where there are many companies that supported sort of professional live stream type experiences where the video was sixty seconds delayed because it was an HLS stream and it wasn't interactive. It was just like, "Oh, cool. Like, Tesla is hosting a product unveiling. Like, we can all watch it live," but it's not interactive. The audience isn't affecting the broadcast.

(Kevan Baikpour at 00:34:54) Periscope tried to have our cake and eat it too. Give you a one to many broadcast that millions of people could watch, but make it super low latency. And that was really the special sauce that I think made it feel magical, and it allowed us to build all these features that felt really novel at the time. For example, the viewers could not just chat. They could tap the screen as many times as they wanted.

(Kevan Baikpour at 00:35:17) And each time they did, it would send a little fluttering heart. And so Joel, as the broadcaster, would be like, he could feel the energy of his audience. Right? Like, any time they liked what they, you were panning your camera and you could see your kid sliding on the slip and slide. And immediately, you'd see a burst of hearts explode from your friends or your family who are watching that livestream.

(Kevan Baikpour at 00:35:40) And that was, like, that single feature was the magic moment. That was the thing that when our users first tried Periscope and they saw that, they were like, "Oh my god, this thing is alive." No pun intended. It was literally like this feels alive in a way that no other social experience did at the time. And so that was Periscope in a nutshell.

(Kevan Baikpour at 00:36:02) We launched it in early 2015. We were acquired by Twitter actually right before we launched publicly. They found us while we were in private beta. We had like 25 users and somehow a few people at Twitter, including Jack and Dick Costolo, who was the CEO at the time, were like, they got, they finagled their way into the beta. And so they got in touch with us and they convinced us to join.

(Kevan Baikpour at 00:36:28) And so we really launched it as a part of Twitter, with the backing and the support of Twitter, which is I think one of the reasons why it blew up so quickly. Like, we were, at the time, we went from zero to a million DAU within like seven days, which, you know, that seems like rookie numbers now with the crazy advent of all these AI tools that explode in popularity. But at the time, that was like one of the fastest apps to grow to a million DAU, if not the fastest. And yeah, it was wild. It was like so much fun and crazy and a lot of it was great.

(Joel Beasley at 00:37:03) Did it get integrated into Twitter as a native feature? Was that the goal of the team, or was it to keep it separate? How did that work? Because I remember downloading Periscope. It was a separate application.

(Kevan Baikpour at 00:37:13) Yeah. So two answers to your question. Was it a goal? The thesis was yes. The thesis of the acquisition was we were gonna keep the app separate, but we were gonna do all the things to leverage Twitter, Twitter's scale, Twitter's ecosystem, Twitter's product as much as possible.

(Kevan Baikpour at 00:37:30) So from the very beginning, the goal was keep it independent and also build all the features into Twitter so that Joel could go live from Twitter if he wanted to so that people who were on Twitter could see a live broadcast. Like, Joel could start a broadcast in the Periscope app, but maybe he's capturing a concert or a protest or something. Like, if that's posted to Twitter, people should be able to watch it on Twitter without downloading a separate app. So we did end up integrating all those things. Even today, it's in Twitter. Like, you can see live videos in Twitter.

(Kevan Baikpour at 00:38:00) Like, if you watch TBN on Twitter, that is a Periscope broadcast. Like, it's not called Periscope, but behind the scenes, the infrastructure is all there still. It's Periscope. And so yes, we did do the integrations. I would say they had varying degrees of success.

(Kevan Baikpour at 00:38:17) We never were able to get people to go live in Twitter much. Like, the sort of professional studio level broadcasts were successful, like things like TBN or ESPN or, you know, if Tesla does a product unveiling. Like, we have a feature which at the time we called Periscope Producer. Now I'm sure they just call it the X, you know, broadcast API or whatever, where you can just pipe an RTMP RTSP stream to our infrastructure and boom, you've got a live broadcast that works on Twitter. So that feature was very popular. A lot of professional broadcasters, like the brands I mentioned, would use that to go live.

(Kevan Baikpour at 00:38:57) But like, Joel opening the Twitter app and pressing the live button, it just never really, it was like orders of magnitude less adoption than the Periscope app, because people just thought of the Periscope app as live streaming, whereas people don't think of the Twitter app as live streaming. They think of it as, like, let me share a thought. Let me share a tweet. So that never really took off. And, you know, we found more success building other derivative features in Twitter like Spaces, which is also a feature that still exists on X, you know, audio conversations.

(Kevan Baikpour at 00:39:33) I think they just felt more at home on Twitter because, you know, they're audio based and they just, they didn't, I think we didn't have a lot of the primitives to make long form videos successful at the time on Twitter. I think X has now done a good job improving on some of that, but the long answer to your question is, like, they just never really took off.

(Joel Beasley at 00:39:58) That makes sense, like, in hindsight saying that audio worked better than video because audio is your voice and the text is your voice. And people were already coming to Twitter for the voice through text. It's just a different medium. But when you start getting video and audio together, that's a whole different thing.

(Kevan Baikpour at 00:40:17) Yeah. I think these formats, anything long form, I think, struggles to work in a feed based context without a bunch of work. Right? Like, and Twitter was an extreme of this because it, it's not only a feed. It's a feed, it was a feed of primarily 140 character chunks. Like, the attention span built into the user behavior of every Twitter user that's been using that product for twenty years is like bite sized chunks.

(Kevan Baikpour at 00:40:45) Then enter, you know, a live broadcast, whether it's video or audio only. It's the exact opposite of that. You're right. It's a long form piece of content. And so we had to build entire primitives.

(Kevan Baikpour at 00:40:57) Like, you see now if you open X, there's the top bar, which shows you when someone's live, whether it's a video of a SpaceX launch or whether it's like Joel and Kevan having a conversation in a space. We had to build these primitives like that bar or, like, when you tap it, having a persistent affordance that shows that you're, like, you've got this broadcast open. So a lot of that stuff just didn't exist at first, and we had to build it. And as we did, I think it made it a little bit more sort of tenable for those use cases to exist in the product.

(Joel Beasley at 00:41:28) Alright. So as we start to wrap up, one of my favorite leadership questions is the best leadership advice that you've ever received, but here are the constraints. You heard it. You adapted it, adopted it early on, and you've kept it with you for a while now.

(Kevan Baikpour at 00:41:49) I'll give you two. One is less leadership-y, but more, I think, like, work ethic that applies to anyone whether you're a leader or whether you're an IC engineer and it's advice I got at my first job when I was like 12. I was cleaning fire extinguishers, literally like we would just go into buildings and take out fire extinguishers and empty them and retag them and inspect them. And I had a boss who told me, like, he said, "When you got nothing to do, sweep." And, you know, he found me, like, I'd finished my fire extinguisher cleaning or whatever, and I was just sitting in the truck waiting for him to finish.

(Kevan Baikpour at 00:42:31) And he was like, "What the fuck are you doing?" And I'm like, "I'm done." He's like, "No. You're never done. Like, when you got nothing to do, sweep the floor, clean, do something." And I think that's really stuck with me as a just like a principle of work ethic. Like, there's always more you can do to push yourself to learn to be productive. And I think it's true of any leader, it's true of any IC. And so that really resonates with me. Leadership advice, you know, I think this was like one of my first meetings with Brett Taylor.

(Kevan Baikpour at 00:43:06) Brett is the CEO of Sierra, and he was the co-CEO at Salesforce. And now he's also the chairman of OpenAI. He was on the board of Twitter. One of my favorite board members. I learned a lot from him and, you know, he gave me this advice at one point. Because I asked him like, you know, this is right when I, I think I got my job leading the product team or something at Twitter. And I went to his office. He was running Quip at the time, his last company that got acquired by Salesforce. And he was like, you know, "Some counterintuitive advice that I would give you is you just, you have to repeat, you have to repeat what's important way more times than you think. So this might be about your roadmap.

(Kevan Baikpour at 00:43:46) This might be about your principles, your vision, like where the team is going. At an organization of any scale. It just doesn't sink in the first time. You have to repeat it so much that you get annoyed at yourself because you're hearing the same thing over and over again. And even then keep, keep repeating it." And it's something that I found to be very true.

(Kevan Baikpour at 00:44:07) Like, only by failing to follow his advice unintentionally did I realize how true this is. Like, you know, like, simple things like at Twitter at the time, you know, this is 1,200 person organization. I was leading the product team. Like, we unveiled a new product roadmap and it's like it completely falls on deaf ears the first time, the second time. You have to keep repeating it.

(Kevan Baikpour at 00:44:25) You have to repeat it until it becomes muscle memory for everyone. And I think that's, it's sort of like the need for that is proportional to the size of the organization. The larger the organization is, the more you have to repeat it until you're bleeding from your ears, you know. And I just think it's like so true. And it makes sense that someone like Brett who's operated at the largest of scales, you know, has experienced that the hard way and has come to embrace that mindset.

(Joel Beasley at 00:44:53) That makes sense. I used to get real frustrated very early in my career when I had to repeat myself. For some reason, I was born with this thought that like, I shouldn't have to repeat myself. And then I come to find out, you know, twenty, thirty years later, I'm a public speaker, and I basically repeat myself every keynote I give every night. It's like, I'm just saying the same thing.

(Joel Beasley at 00:45:13) I do a business, and I realized if I want my team to do something, I have to say it, and I have to say it again. And then like, if I wanted, what was it? Some leadership advice about letting people know that they could come to me. Like, you can come to me with stuff. It's like, yeah.

(Joel Beasley at 00:45:25) You say that once, but you have to keep saying that. You have to keep letting them know it's okay. You have to keep giving them permission. You have to and if you don't, it's just not gonna work as well.

(Kevan Baikpour at 00:45:35) Well and with something like that, there's also, like, you gotta show not tell too. It's like you gotta, because I think with like, people management stuff, like, it's one thing to say it and for people to hear it, but it's also like they just don't really believe it. You have to demonstrate it. So, yeah. I'm totally with you.

(Joel Beasley at 00:45:51) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.