Transcript Reader Lenny's Podcast
Library
Builder transcript 中文已完成

How Block is becoming the most AI-native enterprise in the world | Dhanji R.

Read the source conversation in a calm, mobile-friendly layout.

ChannelLenny's Podcast
Language中文
SourceYouTube
Coverage100%
0% 章节 01
Video Source How Block is becoming the most AI-native enterprise in the world | Dhanji R.

Lenny's Podcast

https://www.youtube.com/watch?v=JMeXWVw0r3E
Reading Mode

默认显示中文,缺失的章节会自动回退到英文原文,保证这页随时可读。

章节 01 / 09

第01节

中文 中文暂未完整,先显示英文原文

Lenny RachitskyThere's a lot of talk about productivity gains through AI. There's this camp of people that are so overhyped, nothing's working, nobody's actually adopting this at scale.

Dhanji R. PrasannaWe see a significant amount of games. We find engineering teams that are very, very AI forward are reporting about eight to 10 hours save per week. Whenever I hear a stat like this, I think an important element is this is the worst it will ever be. This is now the baseline. The truth is the value is changing every day, so you need to ride that wave along with it.

Lenny RachitskyThere's a story I heard you share on a different podcast where there's an engineer who has Goose watching.

Dhanji R. PrasannaYou'll be talking to a colleague on Slack or an email, and they'll be discussing some feature that they think is useful to implement. Now a few hours later, he'll find that Goose has already tried to build that feature and opened a PR for it on Git.

Lenny RachitskyWhat level of engineer is most benefiting from these tools?

Dhanji R. PrasannaWhat's been surprising and really amazing, the non-technical people using AI agents and programming tools to build things, the people that are able to embrace it to optimize for their particular workday and their particular set of tasks are really showing the most impact from these tools.

Lenny RachitskyHow do you think things will look in a couple of years in terms of how engineers work that's different from today?

Dhanji R. PrasannaAll these LLMs are sitting idle overnight and on weekends, while humans aren't there. There's no need for that. They should be working all the time. They should be trying to build in anticipation of what we want.

Lenny RachitskyWhat's maybe the most counterintuitive lesson you've learned about building products or building teams?

Dhanji R. PrasannaA lot of engineers think that code quality is important to building a successful product. The two have nothing to do with each other.

Lenny RachitskyToday my guest is Dhanji Prasanna. Dhanji is Chief Technology Officer at Block, where he oversees a team of over 3,500 people. With Dhanji's leadership, Block has become one of the most AI-native large companies in the world and has basically achieved what many eng and product leaders are trying to achieve within their companies.

In our conversation, we chat about their internal open source agent called Goose, that by their measure is saving employees on average eight to 10 hours a week of work time, and that number is going up, how AI specifically making their teams more productive and the teams that are benefiting most. Interestingly, it's not the engineering team, what it took to shift the culture to be very AI-oriented, the very boring change they made internally that boosted productivity even more than any AI tool.
And there's something big happening in messaging that product teams need to know about. Rich Communication Services or RCS. Think of RCS as SMS 2.0. Instead of getting texts from a random number, your users will see your verified company name and logo without needing to download anything new. It's a more secure and branded experience, plus you get features like interactive carousels and suggested replies, and here's why this matters. US carriers are starting to adopt RCS.
Suddenly, I could involve my whole team in the design process, give feedback on design concepts really quickly, and it just made the whole product development process so much more fun. But Figma never felt like it was for me. It was great for giving feedback and designs, but as a builder, I wanted to make stuff. That's why Figma built Figma Make. With just a few prompts, you can make any idea or design into a fully functional prototype or app that anyone can iterate on and validate with customers.
Figma Make is a different kind of vibe coding tool, because it's all in Figma. You can use your team's existing design building blocks, making it easy to create outputs that look good and feel real and are connected to how your team builds. Stop spending so much time telling people about your product vision and instead show it to them. Make code back prototypes and apps fast with Figma Make. Check it out at figma.com/lenny. Dhanji, thank you so much for being here and welcome to the podcast.

Dhanji R. PrasannaThank you Lenny. It's a great pleasure to be here.

Lenny RachitskyI want to start with a letter that I hear you wrote to Jack Dorsey to convince him that he and that Block needed to take AI a lot more seriously. I think you called it your AI manifesto and it seems like it really worked. We're going to talk a lot about the changes that came as a result of that. So let me just ask, what did you say in this letter and what happened right after you sent that letter to him?

Dhanji R. PrasannaSo about two and a half years ago or so, Jack really felt like things needed to change. I think he had a sense that the industry was going in a different direction. So he got about 40 of the company's top executives into a room on a weekly basis, and they all used to sort of talk everything through that was going on and he added me to that group.

So at some point, I observed that we were talking about lots of deep things, lots of relevant things, but no one was really paying attention to AI, and so that's when I wrote that letter. And to be honest, it's I think taken on a life of its own, but there wasn't much to the letter other than I think we should do this. I think we should do it centrally and it's important for us to be ahead of the game and be an AI native company because that's where the industry is heading.

Lenny RachitskyLet me just say it's important to note you were not CTO at this point. You were just a senior engineer kind of person?

Dhanji R. PrasannaNo, yeah, in fact, I was part-time at the time because I had just had a kid and I was coming back in and I was helping out one of the engineering teams and then Jack came over to Sydney and spent two days with me and both of us like long walks. So we walked all around Sydney and talked it through up and down, and then yeah, he offered me the job and I thought it was a great opportunity once in a lifetime, so I took it.

Lenny RachitskyIt's like be careful what you're good at sort of situation. Okay. So what were some of the bigger changes that you made after Jack is on board and Block execs are on board of are, "Cool, this is completely right. We need to go much bigger and think much more deeply about how AI is changing, how we build and how we should build." Or some of the bigger changes that you made from a perspective of other companies listening to this, trying to think about what they should be doing?

Dhanji R. PrasannaAt the start, my main focus was to get block to think like a technology company. And for a long time we had had a little bit of, I'm going to call it identity drift, maybe. We were talking about ourselves as a financial services company. Some people called us FinTech, all of this stuff. But when I started working at what was then known as Square, we were always thought of as a technology company just like Google or Facebook or any of the others.

And so I wanted to get us back to that. And so the first thing I did was to try and institute a number of programs that focused on that. So everything from getting the top ICs in the company together to talk to each other, to starting a whole bunch of special projects. So we got about two to five engineers per project. There were about eight or nine different projects and we had reinstituted, the company-wide hack week.
And so all of this just kind of created a little bit of a spark of, "Hey, we're building technology again, we're trying to push the frontier again." And that's how it started, and then there were a whole number of steps after that where we went from a GM structure to a functional org structure, which was I think the key to making our transformation into being more of an AI-native company.

Lenny RachitskyOkay, talk more about that. What does that mean? What does that look like? Why is that so important?

Dhanji R. PrasannaAbsolutely. So when we were in our mature phase, so when Square was working quite well, it was a very large business, and then we had started Cash App and that also followed suit. We had spun them out almost as what we call a GM structure. So they were effectively run as a portfolio of independent companies and they had their own CEOs who all reported to Jack and it was still one single executive team, but they had separate engineering practices, they had separate design teams.

They were kind of separate in almost every way except for some shared resources like our foundational resources like legal and some platforms and things like that. So I think that that was very useful for us for the stage of company that we were in, but when you really want to go deep in technology, when you really want to connect with these things that are industry changing events that are happening, you need a singular focus, and we changed the organization.
So all engineers report into one single team now, all designers report into one single team and there's single head of engineering, single head of design, et cetera. And so that was the big transformation that we made, and that meant we could really drive forward AI, we could drive forward platform and just technical depth generally.

Lenny RachitskyFor companies that are struggling with this potentially or trying to figure out how to do this, two things I'm hearing here is start to see yourself as a technology company. It doesn't necessarily apply to every company, but seems like an important element is like we're building technology, we're not a financial company, we're not a real estate company, we're not a technology company. And then two is organize the team such that say engineers report up to an engineering leader versus a GM who maybe doesn't understand engineering as well or doesn't take it as seriously as they should.

Dhanji R. PrasannaYeah, I think that's pretty much what we did. And not to lean too heavily on this, but this is what jobs did when he came back to Apple as well. He reorganized Apple to be functional, and it wasn't like we were following a playbook. We discovered this as we were investigating what it's going to take to make these teams more tech-focused and to bring our DNA back to our roots, which really was putting engineering and design first, which is what technology first means to me. So yeah, I would say to companies, find your DNA and really try to optimize for what that is in a very simple and clear way.

Lenny RachitskyOkay, so you made a bunch of changes, you had this manifesto, everyone's on board, you made a bunch of changes. Functional technology first, comparing the way that your say engineering team works today versus two or three years ago, what is most different?

Dhanji R. PrasannaNot everyone was on board, I'll tell you that. It was quite a painful transformation. I think that one of the things that I learned the most throughout this process is that Conway's Law can be really, really powerful. So it's the law that basically says you ship your org structure. So what you're organized as in terms of teams, in terms of collaborating groups and your operating model matters a lot to what you build.

And so I think that that was essentially the biggest change is we had a lot of momentum in each of these silos, be it Cash App, be it Afterpay, be it Square or even TIDAL or music streaming service. And no one was really talking to each other, no one was really aligned on technical strategy on what we even wanted to be five years from now as a collective team. And so all those things are different now. I'm not saying it's perfect, there's still a long road ahead of us, but we at least speak the same language.
We're all have access to the same tools, we share the same policies. So a certain level of senior engineer means the same thing across the whole company. People can move from one team to another's into an area of need. All of these things are very different. But to sum it up, I would say we're technically focused and we're focused on advancing technical excellence as a goal. And that just really wasn't that true two to three years ago. There were other things we were optimizing for then.

Lenny RachitskyMaybe going one level deeper in terms of how people actually work at a day. So if you're looking at an engineering team, say the average engineering team and maybe also the top most optimal engineering team, how is the way they work today different from a couple of years ago?

Dhanji R. PrasannaIn the small, certain teams that are very, very AI natives or teams that are building AI first everywhere are working much differently than before because they're using vibe code tools and they're essentially building without writing lines of code by hand, and that just wasn't true through the three years ago. I don't think it was true anywhere in the world. So that's dramatically different in teams that are still working with very heavy legacy code bases.

It's less true, but they're also encountering these background AI processes. So we have these tools that run 24/7 or run in the CI pipeline and they're analyzing vulnerabilities. They're looking at even bugs filed on tickets and trying to build patches while engineers are asleep. So they come in the next day and look at it. So I would say there are a number of ways in which they're different, but different teams have adapted in different ways depending on how close they are to the tools.

Lenny RachitskyOkay, so let me lean into that AI piece, which is I think where you guys are most ahead of a lot of other companies. You guys built your own agent I think is how you describe Goose. So there's a lot of talk about productivity gains through AI. There's this camp of people are like, you don't understand how much productivity there is to gain from AI. It's the future, this is the way it's all going to work.

We're all accelerating 10X. There's also this camp where people are like, I'm so overhyped, nothing's working. People talk about it. All these pilots are failing. Nobody's actually adopting this at scale. I feel like you're probably in that first camp. What sort of gains have you seen practically from AI tools on your teams?

Dhanji R. PrasannaOur number one priority is through automate Block, which means getting AI and getting AI forms of automation through our entire company. And we feel that that's just at the beginning of where the utility is with all these large language models, and I think we're going to continue to see that improve. But even now, we find engineering teams that are very, very AI forward that are using Goose every day are reporting about eight to 10 hours saved per week, and this is self-reported. And then we also have a number of check metrics to try and validate that.

So we look at PRs, we look at throughput of features, we look at a whole bunch of things and we have our data scientists come up with a complicated formula that tries to distill it all into something meaningful. And we feel across the whole company, we're probably trending towards 20 to 25% of manual hours saved. And I think that's just the start of all of this. I do feel that the more AI-native companies are doing a better job of realizing this.
So companies that started just with AI startups mostly, but there is some truth to this notion that AI isn't a panacea and it's growing as well in capability. So you need to ride that wave along with it. And I think a lot of the companies aren't realizing this. They're like, "Well, where's the value?" And the truth is the value is changing every day. And so you need to be adaptable and look at what the value is today and plan for what the value will be tomorrow and then slowly expand to the areas where it's most efficacious.
I'll give you an example. One area in which we find that it's really good is for non-technical teams to be able to build little software tools for themselves. So this has been one of the most surprising and energizing uses of Goose within Block is we'll have our enterprise risk management team build a whole system for self-servicing enterprise risk, and this is compressing weeks of work into hours, or ordinarily, they would be waiting for an internal apps team or something to go and build that and they would put that on their Q2 roadmap and everyone would be twiddling their thumbs until it all clicked into place, but now you can just go and do it.
And so a lot of these kinds of use cases we're seeing an enormous amount of productivity gain in the other area, which I'm really excited about is we have this other tool called Gosling, which is a goose for mobile effectively. So it operates your Android OS at a native level using the accessibility API. And we use that for automating UI tests.
So before, you would have to hire an army of contractors or QAs who would go and click through every screen, but now we can just bake those into automated tests and then give you a report at the end. So we're seeing a lot of advantages in those types of areas, but where you have a lot of depth and a lot of really strong people come together is where AI, I think still underperforms humans. And that's something that's probably going to get better over time, but it's also something where we should lean into as humans.
So when you have some very senior engineers and they're thinking about things like architecture and design and race conditions, orchestration, things like this, that's still an area where AI isn't quite there. And so I think the companies that aren't feeling the success in AI are trying to just throw these tools at their giant code bases and hoping good things will happen, and that's not how it's playing out. Eventually, I do think it'll get there, but right now we're still in the early utility phase.

Lenny RachitskyHoly moly, there's so much there in what you just shared. There's like five things I want to follow up on. Okay, so one is this metric you kind of alluded to, which is how you measure the impact of AI in your team. So it was human manual hours saved, is that how you describe it?

Dhanji R. PrasannaThat's correct. Yeah.

Lenny RachitskySo it's roughly a fourth of an engineer's time currently is being saved by AI tooling.

Dhanji R. PrasannaThat metric is across all teams. So that would be our support teams, our legal teams, our risk teams, all of them together.

Lenny RachitskyWow.

Dhanji R. PrasannaAnd then on the engineering side, it's very variable because like I said before, it matters how big and how complex the code base is. And so if you're building a totally new Greenfields code base or you're building an app for a new platform, then we're seeing those pretty aggressive gains, but in very complex code bases that already exist, those gains are not quite there yet.

Lenny RachitskyThat's amazing. And whenever I hear a stat like this, I think an important element that people need to think about is this is the worst it will ever be. This is the lowest, this is now the baseline. And so it may not sound that crazy yet, but it's going to get crazy. Okay, the other thing that you talked about is Goose, you haven't explained what Goose is. This is a huge deal. Explain what Goose is and how important this has become to you guys.

Dhanji R. PrasannaSo Goose is a general purpose AI agent. So you can think of it as a desktop tool or a program that you can download and install on your computer and then it has a UI. You can talk to it just like a chatbot and you can say anything from, "Hey Goose, organize my photos by category, and it has the ability to look within your photos and if there are a lot of trees, it'll organize them as nature photos. And there are a lot of people, it'll organize them as portraiture." All of this sort of stuff to writing software for you.

So it can do all of these tasks, and the way we've been able to do this is through something called a model context protocol or the MCP, which a lot of your listeners might've heard. And this is something that Anthropic came up with that we were a very early contributor to. And the model context protocol is very simply just a set of formalized wrappers around existing tools or existing capabilities. So if you have tools that you use in the enterprise, be it Salesforce or be it Snowflake or SQL, any of these things, you can wrap them in the MCP and then it exposes them to your LLM to be able to manipulate.
So until that point, the LLMs were not really able to do much other than chat, but Goose gives these brains arms and legs to go out and act in our digital world, and that's where we find it's had most impact and it's built on this fairly open protocol that anyone can implement. There have been an explosion of MCPs. Goose is entirely open source, by the way, so any of you can download it and extend it, write your own MCPs, and that's been our core successes through Goose.

Lenny RachitskyOkay. So essentially like Claude code with a UI, desktop app sort of thing built on top of Claude and OpenAI ChatGPT and a bunch of open source models. Is that right?

Dhanji R. PrasannaYeah, it can use any model. So we have a pluggable provider system and you can either bring your own API keys and use the Claude family models or OpenAI's family models, or you can use open source models and you can download them and use them directly or via Ollama and other, there are several tools that help you do that, but essentially it's taking the capability of these models to generate text and to interpret text and applying them to real world situations.

So one example that I really like is you can ask Goose to go and build your marketing report and it has MCPs to connect to Snowflake and Tableau and Looker. So it'll write SQL to pull out data from there, it'll do some analysis and a CSV so it can write Python code on your desktop to do all that. It will generate some graphs using some JavaScript charting library that it knows about.
And then finally, it'll put this all into a PDF or Google Doc or whatever and it can even email it for you or upload it somewhere. And it's doing all of this on its own, by the way. No one's sitting here telling it that, you're just saying, "Hey, I want this report, I want this emailed here, I want these pretty charts." And it's orchestrating across all these systems.

Lenny RachitskySo essentially at Block, instead of using Claude or ChatGPT directly or even Cursor and all these apps, they use Goose?

Dhanji R. PrasannaYeah, we allow our engineers and our general employee population to use any tools that they want. Goose is the one that's most well-integrated into all of our systems because it's built on the MCP and it's so easy to create an MCP for an existing system. So for example, if you're using a issue tracking tool and you want some AI automation added to it, before Goose, our teams would have to wait for the vendor to build that AI capability in there, or maybe there's some way in which OpenAI or Anthropic or Google would provide a general purpose capability where we could plug those in. But with Goose, that's no longer necessary with a few lines of code that an MCP represents. All these systems are orchestratable with AI basically overnight, and Goose can write its own MCPs. So it's pretty bootstrappable as well.

Lenny RachitskyAnd this is open source and basically you've spent all this time building this thing, any other company can now implement it and build on all the work you've done?

Dhanji R. PrasannaYeah, and we have a lot of companies using Goose pretty actively. I don't want to name too many names, but from our competitors to our close partners, a lot of them are using Goose pretty regularly on their teams. I know Databricks talks about it a lot, but everyone you can think of in this mid-tech tier is using Goose in some form.

Lenny RachitskyThat's insane. This feels like it could've been a massive business of its own, some of the fastest growing companies in the world, basically this is their product and you've built it and given away.

Dhanji R. PrasannaYeah, we believe in the power of open source and one of our core missions is to increase openness, and that means contributing to open protocols and contributing to open source. And as a tech company, we're built on a lot of open source software. I think pretty much every tech company is whether you're talking about Linux or Java or MySQL or any of these essential components, and so we feel like we have a strong imperative to give back.

We want to build things that not only are good for us and our customers, but that outlast Block and outgrow Block, that's certainly a core value for us and has been from the beginning even long before this whole AI phase. So yeah, Goose follows in that proud tradition and yeah, we're very excited that its had the success it's had.

Lenny RachitskyWhat's the story with the name Goose, by the way? Can't help but ask.

Dhanji R. PrasannaGoose is a Top Gun reference. So our engineer that came up with it. He also looks exactly like Goose, so it's kind of crazy if you put them side to side, he's going to be really embarrassed with my sharing this, but that's the reason why they call it Goose, and then we lent into the whole bird theme after that.

Lenny RachitskyThat's incredible. There's a story I heard you share on a different podcast where there's an engineer who takes this to the extreme and has Goose watch him. Talk about that, share that story.

Dhanji R. PrasannaYeah, absolutely. So he is very, very AI-focused and he's trying to extract all these crazy ideas from Goose and Goose can do all of the things that I described through specific interactions with tools, but it can also just watch your screen so it understands how to process images and process the things that it's looking at through screenshots. And so he built this system where it's essentially just watching everything he does all the time and he'll be talking to a colleague on Slack or an email and they'll be discussing some feature that they think is useful to implement.

And then a few hours later he'll find that Goose has already tried to build that feature and opened a PR for it on Git and all sorts of other wacky things like that. So it'll try to nudge him out of a workflow. If he's running over on a meeting and he's late for something else, it comes up with these creative things that he didn't program or he didn't write prompts for, but that it thinks will help him improve his productivity or improve his work day. So yeah, it's pretty crazy. You have to have the stomach for it to be that level of tied into your working tools, but it kind of shows you what's possible with tools like this.

Lenny RachitskyClearly this is where things are going. Once this gets good enough, I love this guy is just trying it. So it's basically watching him work and anticipating what he should be doing and does the work for him as a first draft so that he's like, "Oh, the PR is already done on this thing. We were just talking about it at this meeting." That's incredible.

Dhanji R. PrasannaExactly.

Lenny RachitskyHow good is it? Where's it at? If you had to go zero to a hundred of like, "Okay, going to, all you have to do is now think and talk and that'll just do your job."

Dhanji R. PrasannaYeah, so voice is the other big part of it. It has voice processing capability, so it's always listening to what he's saying as well and trying to interpret that. I would say that this is mostly an experiment, given that he's on our core Goose team and he contributes to Goose, so he has a day job. This is a kind of thing on the side that he was developing.

So once this evolves into more of a native feature of Goose itself or other tools that we use in the enterprise, I think it can have a lot of legs, but it's already pretty good. It's probably cutting down enormous amounts of busy work that he has to do. So for example, one thing he'll do is he'll say, "Oh, I have a meeting conflict. I can't make it that time, or I have to go pick up my kid."
And Goose will automatically reschedule that meeting without him ever sitting in front of his calendar and clicking through 10 times. Yeah, so these are things that I think we were waiting for the calendar vendor to build as features into calendar, but we don't need to do that anymore because AI is able to orchestrate this for us.

Lenny RachitskyThis isn't that guy that had four jobs at four different startups that he was able to paralyze all his work and hire people.

Dhanji R. PrasannaNo, it's not. He's someone that I've worked with for a long time and he's been at Block for a long time. He just loves experimenting and he embodies that culture of experimentation just like our creator of Goose who did the same thing.

Lenny RachitskySo let me pull on that thread a little bit. You're kind of seeing a glimpse of where things are going. You're very ahead of the curve in a lot of ways at Block. How do you think things will look in a couple of years in terms of how engineers work, how product teams work that's different from today?

Dhanji R. PrasannaI think a lot of it is dependent on the improvement of LLM performance, but I can tell you the way I'm trying to change how I work and how I'm trying to change our immediate team's way of working. So I think vibe coding has been an interesting, exciting thing, which is you talk to a chatbot essentially and it goes and builds software for you, but I think this is highly limiting.

It's very ping pong. You do something, you wait for three or four minutes and it comes back with something sort of half-baked and you have to nudge it and guide it and massage it to get where it needs to be. I think that we're going to see much more autonomy. So where we're working on a couple of experiments with Goose, with the next version of Goose where we're really trying to push it to work not just for two or three or five minutes at a time, our median session length is five minutes and on average, seven, but we're trying to push it to hours.
We're trying to say, "Hey, all these LLMs are sitting idle overnight and on weekends while humans aren't there, there's no need for that." They should be working all the time. They should be trying to build in anticipation of what we want if we go back to the earlier part of the conversation. But also I think that they should be able to build in ways that were never possible before.
Before as humans, we had limited resources, limited bandwidth, and a lot of coordination overhead. So we would have to choose the best path to try in an experiment, and I don't think we need that anymore. We need instead to be able to describe multiple different experiments in a great amount of detail. And then maybe we go to sleep and then in the morning, all those experiments are built and we can sort of throw away five or six of them.
So one of the things that I do regularly, so I write code every day, but one of the things that I do regularly is just throw away huge, huge amounts of code, and it's kind of hard for me because I've never done that before. I mean obviously engineers love deleting code, but this is different. You build a whole new system or a whole new feature and you're like, "Ah, it doesn't feel exactly right. I'm just going to delete and start over."
So I think you're going to see a lot more of that way of working. And I think that you're going to see instead of us, for example, refactoring an app to have a different UI or to evolve into its new version, we're just going to rewrite that app from scratch. And one of the things I'm really pushing our teams to think about is what would our world look like if every single release, RM minus RF deleted the entire app and rebuilt it from scratch? And so we can't really do that today, but I think this shows you some of the direction of what's possible and where these tools are taking us.

Lenny RachitskyWhat's interesting about that is that there's this common rule in software engineering and just product, don't ever just rewrite. Don't try to rewrite your thing. You're going to forget all of the small improvements and tweaks and bug fixes people have made over the years, and you think it's going to be the simple straightforward thing. It ends up being now it's like a year or more of just getting it back to where it was. And so interesting that AI now can make that possible, and what you're saying is that's actually maybe the way you should be working.

Dhanji R. PrasannaI think so. And I think that the trick is getting the AI to respect all of those incremental improvements, yeah, and sort of bake those in as a part of the specification, if you will. Yeah.

Lenny RachitskyAlso, the point you made about this agent, just you give it a bunch of ideas that builds them overnight and then you could see, I imagine it goes even further up the stack and comes up with the ideas and then starts building them and then you're like, "Okay, oh, that was a great idea. Now I can see it immediately in the same workflow."

Dhanji R. PrasannaYeah, that's true. I was actually literally trying what you're saying just last week. And so I have this new version of Goose that we're working on and I was asking it to come up with ideas to improve itself and implement it overnight. And sometimes-

Lenny RachitskySlip problem.

Dhanji R. Prasanna... Sometimes it kind of goes off the script entirely and you have to sort of pull it back a bit. So I think we're not quite at that era where it's completely self-improving and completely autonomous, but I do think we're in a transition phase where we can give it that nudge and say, "Hey, here's my wishlist of 10 things that I wish you could do. Go and figure out the best way to do them." And it's successful I would say on 60% of those things, if the features are well enough described and it struggles on the remaining 40 where you have to kind of intervene and massage it. Yeah.

Lenny RachitskyOh man, I'm just imagining this feature where you give it the goal of drive revenue and growth and then it's just like, "Okay, everyone's fired. Here's your paychecks. I'll take it from here."

Dhanji R. PrasannaI don't think we're going to be there. I do think we're going to need a lot of human taste to anchor these AIs so they don't go off script to be honest. And that's really where our design lead and our design teams are pushing us to think, and that's a differentiator that I think will push us beyond this era of AI slop that everyone's talking about. So yeah, it's very much anchoring it into a thing that matters to people and the thing that's tasteful and useful and has value.

Lenny RachitskyTo make that even more concrete, is there an example of something maybe AI was trying to, or a team was trying to pitch where you had to just know this is where humans are going to step in and keep things on track?

Dhanji R. PrasannaI'd say it was more around things like process automation or a lot of times I'll get this sort of request where a team will say, "We need to buy this new tool from this vendor because our current tool is entering X, Y and Z." Another team will say, "No, no, no, we can just use Goose to build an app that will do the same thing for us in half the time or less." And then as a human, you're sitting there thinking, "Is any of this necessary? If we just change the process, do we even need to think about building tools?" And this is the thing that AI isn't good at, it's not able to have this portfolio judgment or judgment across a global sense of what's important and what matters.

So a lot of times, I tell teams just question the base assumption, particularly our InfoSec teams because they'll twist themselves into knot sometimes trying to secure something and you'll be like, "We'll just ask the team that's building it to do it differently or to not build that at all if it doesn't matter, and then you won't have to increase your surface area of securing it." So I think those are the areas where it's better for a human to use judgment and AI has not done a great job.

Lenny RachitskyYou make this point about building your own software, your own tools instead of buying stuff. This is a big question with AI, is it's going to replace all these SaaS apps to Salesforce over. Is there a sense of just either how much money you guys have maybe saved building your own stuff, or have you built a new-found respect for the existing SaaS software that everyone's using and pays lots of money for?

Dhanji R. PrasannaI think there's a trap in getting away from your core purpose as a company. And our core purpose is economic empowerment. So getting customers or merchants or artists the ability to make a sale or pay their rent or upload their latest creation to TIDAL. And I think that anything that serves that purpose, we should encourage and we should invest in, but if we're just purely looking at dollars versus dollars, then that's pulling us off that purpose.

The savings and costs that there might be in replacing a vendor tool by something you build in-house is probably not worth it in the mental bandwidth that you've lost and the amount of the team's technical focus that's being taken away. So yeah, I would say it just keep coming to the thing that matters to you as a company and then the rest will follow from that.

Lenny RachitskyYeah, I think people forget just how much maintenance it takes to keep something you've built. Like, "Okay, cool, we built it in a weekend and now it's years of endless maintenance and requests and support." And also to your point, it feels like it comes back to the always motto of just focus on your core competencies and then buy everything else.

Dhanji R. PrasannaYeah, it's the classic 80/20 problem, and we have that enough with the apps that we build for our customers. We'll build some great experiments that really resonate, and then we have to spend a lot of time ironing out the long tail of problems. So in Cash Card, for example, we built the entire functionality of Cash Card, I would say pretty much in a weekend or maybe a week of integration and work.

And then it took a really long time to iron out all these edge cases where someone would tip twice the value of the bill and then it would completely break something in the back end, or people would use it as a gas station and they have a different way of billing your card. So yeah, it's very much that. And to your point, I would always come back to what is the reason we're doing this? Why does it matter to us and to our customers? And if it doesn't clearly satisfy that, I would just push it off as a not interesting thing.
Persona helps combat these threats with automated user business and employee verification. Whether you're looking to catch candidate fraud, meet age restrictions or keep your platform safe, Persona helps you verify users in a way that's tailored to your specific needs. Best of all, Persona makes it easy to know who you're dealing with without adding friction for good users. This is why leading platforms like Etsy, LinkedIn, Square and Lyft trust Persona to secure their platform persona is also offering my listeners 500 free services per month for one full year, just head to withpersona.com/lenny to get started, that's withpersona.com/lenny.
Thanks again to Persona for sponsoring this episode. One of the biggest parts of the conversation around AI is hiring jobs, things like that. So I have two kind of this two-part question. One is just how has the rise of all these AI tools, this increased productivity impacted the way you plan head counts and hire? And then what do you look for that's different in people you're hiring now that AI is such a big part of the way you guys work?

Dhanji R. PrasannaI don't think that things have progressed far enough that it's really impacted in a fundamental way how many people you would need to build an app of the scale of Cash App, for example. I think what's changed for us is much different and it has nothing to do with AI, it's what we talked about earlier is moving from our GM structure to a functional structure. And in our GM structure, our incentives were always to think of engineering headcount as a commodity.

And so we would just add more engineers if we wanted to build more features and the classic mythical man person month trap or whatever it's called. And I think that moving to a functional structure completely changes that and you're like, "Well, we can leverage common platforms, common modules, we can bring in experts from across the company to advise us on how better to do this."
And so those kinds of things I think have made it much different and how we hire and we no longer see engineers as a commodity to just add 100 people to go and build the next product in Cash App. But on the AI side, we're very much looking for people that are embracing these tools and that are eager to try and learn from it. We're not looking for people who are amazing AI practitioners on the get-go.
I think we have those people and we're interested in those people if they ever want to work with us. But I'm much more keen on looking for that college grad who just really is eager to learn about these tools and open to it, or even the veteran who has embraced these tools and figured it out. And that's kind of where we're optimizing for who we look for rather than a specific set of skills.

Lenny RachitskySo essentially the biggest change is just looking for people that are embracing AI, not being like, "No, I don't need this stuff. I'm an amazing engineer. I don't need to use Cursor or Goose or all these things."

Dhanji R. PrasannaYeah, a learning mindset is how I would put it. This is something that Jack our CEO talks about a lot is he wants us to be a learning first company. So everything we do, every experiment that we ship, what can we learn from it and did we feel that we gave it our best shot? And I think that that's more important to him than even sort of coming up with the right business answer every time.

Lenny RachitskyWhat about when you're interviewing? Are you encouraging engineers to use AI tools as they're doing exercises? How did that change over the past year or two?

Dhanji R. PrasannaYeah, we're starting to do that now. So traditionally we would just use CoderPad or something like that to wipe boards or a problem or even program it in Pseudocode or near Pseudocode. But now we're looking at can you use Vibe code to build something? How comfortable are you with these tools or how are you thinking about evolving with them as well?

But it's early days yet I would say that it's not clear to me that necessarily how someone knows how to use, be it Goose or Cursor or any of these other tools matters that much to whether they're a good engineer. I still think that things that we interviewed for in the past, a critical mindset, the ability to really understand deeply the technical nature of a problem is still much more important than whether you're a fully AI native programmer or not.

Lenny RachitskyAnother question that I've always been thinking about a lot of people wonder is what level of engineer is most benefiting from these tools? You could argue it's the junior engineers now, they could just get all this work done. You could argue it's senior engineers because they know so much more about how things work and now they could just orchestrate thousands of agents doing their bidding. What have you seen in terms of which level is benefiting most?

Dhanji R. PrasannaYeah, so two answers to that. One is you're definitely right that the more senior and the more junior they are, the more comfortable or the more eager they are to adopt these AI tools. And I think that's for a variety of reasons, including some of them that you named. I think the senior people really understand in great depth how everything works.

And so they're almost relieved that this tool exists that can go and do all these things that they've done a million times before and couldn't be bothered. And then the junior people are like my niece and nephew on a BlackBerry or something, they're just blitzing through things, not BlackBerry in the early days and iPhones now, they're blitzing through a text message when I'm still seek and destroying through my keyboard, shows you how old I am.
So I think there's that, but I think the non-technical people using AI agents and programming tools to build things is really what's been surprising and really amazing. And I think that speaks to how these roles are going to evolve in the future. The lines are going to be blurred between whether you're in legal or in risk or in engineering and design even. And so I think that the people that are able to embrace it to optimize for their particular work day and their particular set of tasks are really who are showing the most impact from these tools.

Lenny RachitskyIt's interesting. No one talks about that element of engineering productivity, which is the reduction of asks from all the other parts of the company to build random one-off things. That feels like a huge productivity gain for engineers.

Dhanji R. PrasannaIt is massive, although I think that it's a little bit like the analogy of if you build a bigger highway, you'll just get more cars on the road. So I think the fact that everyone's building software means that there's more software to be built, more coordination to happen, and everyone's more eager to ship things faster and with greater results. And so we're just seeing an overall uptake in velocity and the ask for more features, if that makes sense. Yeah.

Lenny RachitskyAbsolutely. And it connects to your point about you're not slowing hiring. What I'm hearing is just headcount, hiring desires for more engineers, more product people is not slowing at all. You're basically, it's as if AI wasn't really there.

Dhanji R. PrasannaWe're being more thoughtful about it. So like I said, we were looking at as a commodity in the GM era, and now that we're functional, it's much less about how many engineers we need as a function of the number of features we have in Square or Cash App and in the functional org structure, we think of it much more as what are the areas of optimization? Where can we build depth and what really accelerates our priorities through things like modularization reuse and going deep into platforms.

Lenny RachitskyI love this hot take of if you're trying to be more productive, forget AI, just re-org into a functional structure.

Dhanji R. PrasannaIt's not wrong in some ways. So here's another really interesting example where we are trying to improve our build times and you were using Goose and a lot of other tools to help us with this too, and they've done remarkable things. So we have this really cool tool that analyzes our test suites and selects the right test to run for changes that were made.

So we cut down basically 50% of test runs this way, which is pretty great, and we're not warming the planet as much with all these unnecessary CPU cycles being wasted on tests. But then things like offloading tests to the cloud or simply just deleting tests that don't make sense anymore, probably save you two to three times that.
So there is still a portfolio approach that you need to take for lack of a better term. It's like that example I told you earlier about should we buy a vendor tool? Should we build this in-house? It's like, "Well, do we even need to do this process at all?" So in some ways, structure matters more than the efficacy of the tools you have.

Lenny RachitskyWise words makes me think about Elon has this whole process for optimize stuff and one of the steps is like, "Do we even need this thing before we start out optimizing and automating it?" Before I zoom out and ask about just general lessons that you've learned over the course of your career, is there anything else that you think might be really valuable or useful to folks that are trying to lean in further into AI or just help their teams think a little bit more forward thinking?

Dhanji R. PrasannaI would say really try and use these tools yourself. So the way in which I think we've been able to drive most of the adoption is Jack uses Goose, I use Goose, our executive team all have used Goose and use it regularly and use other AI programming tools and assistance as well, and we do it every single day.

And so we learn a lot about how our own workflow can change, and that's going to tell you so much more about how are you going to change your organization's workflow than if you're reading a bunch of think pieces on LinkedIn or Harvard Business Review or whatever it is, and then trying to get your teams to follow suit. So I think we do this with everything. It's feel it, use the product yourself, feel it, understand its strengths and weaknesses and its ergonomics, and then figure out how to apply it to your teams.

Lenny RachitskySomething I've found helpful in doing that, which I completely agree with, which is stop reading about it, stop listening to us talking about it, just build some stuff. The thing that I found really helpful there is have a specific task or problem you want to solve for yourself because that really motivates you and makes it very real.

For example, just the other day, I was trying to pull images out of a Google Doc. Google Doc, it's like I think of it as Hotel California. You put images in there, but there's no way to get them back out unless you do some crazy stuff. So I just went to Lovable and like Bill an app, or I can give you a Google Doc URL and let me download the images real easily and bam. Perfect.

Dhanji R. PrasannaYeah, great example. I did something like this a couple months ago as well, where my son has a whole bunch of therapies, he has additional needs, and so I was trying to gather the receipts for all these therapies and share them with my wife and she will claim it from our insurer, and I was really struggling to do this because they're in various forms.

There are screenshots in some cases or PDFs or whatever. So I asked Goose to do this and it was all sitting on my laptop and Goose figured out that it could put all of these receipts into my Apple Notes app into a single note. It converted it to HTML so it would sync seamlessly to my phone and then I could email it or share it with her from there.
And that's just something I just never would've thought of. And it did this using Apple Script, so it just controlled my computer for me in the background. Yeah, so these are surprising ways in which these tools help us, and the more you use them to solve real problems to your point, the more you understand what their strengths are and where you can deploy them.

Lenny RachitskyI love this example. So did you just go to Goose and be like, "Here's the problem I have, how would you solve it?"

Dhanji R. PrasannaYeah, pretty much. I said, "I have all these receipts there in Google Drive, so we have similar origin problem there and I need to get them into a single form and I need to collate the totals and do all this." So it tried a few approaches first. It tried to download them and it tried to read them using a PDF reader and this and that. And then the thing about Goose that I think a lot of the other AI agents learn from us as well is if it tries a few things and fails, it'll back up and it'll try a different route and it'll just keep going until it makes some progress.

And that's what it did. Then it picked Apple Script as a way to do it because it had the MCP extension to control my computer, and this is the same thing that our engineer, we were talking about the other day uses to watch his screen and things like that, but this was a very focused problem and it managed to do that. So yeah, it's surprising what these tools can do and allowing them the flexibility to do that is a big part of learning how to use them.

Lenny RachitskyThat's cool. I love the, by the way, can you run Goose as a regular person? Can you just download Goose and use that instead of Claude?

Dhanji R. PrasannaYeah, absolutely. Yeah. You can just download it from our URL. We can share it in the show notes for you and yeah, you can install it. It comes for Mac and Windows and Linux I believe. It's an electron app, so it'll work on all of them. It also has a command line, so for people who are more comfortable using that, we have that UI as well.

Lenny RachitskyWow, you really are competing with these massive foundational model companies building. What's the simplest way to compare Goose to something else? Is it like this Claude code, this simplest comparison or something else?

Dhanji R. PrasannaI think it's a bit different than Claude Code because at its core, Goose is a platform that implements MCPs. So MCPs give it this dynamically extensible nature so it can do all of these things for you, whether it's automating things like we were talking about with Google Docs and notes and things like that, or it can do straight up programming tasks for you using other MCPs.

It can index code and do it that way. So it's really more of an extensible platform. So I would say it sits somewhere between your classic AI assistant where you just ask it, "What's the weather today? Can you calculate how many months it's been since this date?" Or whatever it is, to the more focused cursors and Claude codes of the world.

Lenny RachitskyBasically, it's everything combined wholly and free. You pay for the LM tokens, but yeah.

Dhanji R. PrasannaYeah, there's not like an open source models which-

Lenny RachitskyOh my God, this is crazy. What a cool team to be on building Goose at Block. Must having must be having so much fun. Oh man. Okay. Let me zoom out a little bit. So you've been CTO in LinkedIn right now for just about two years. What's something that you wish you knew before you stepped in this role? If you could go back a couple years and just whisper a few tips and tricks or lessons into your ear, what would they be?

Dhanji R. PrasannaI think maybe two different things. One is just the power of Conway's Law, like we talked about before. It's like how difficult it is to change outcomes without changing the structure of relationships between people in an organization. And I think I always kind of knew that at some level, but really appreciating it in a visceral way is big. The other thing that I really learned the hard way maybe is you only hear about it when things are going wrong.

So when things are going well, you kind of have this eerie silence and you're like, "Well, am I doing the right things here? Am I focusing on the right problems?" So having a bit of judgment, having a bit of time to step back and look at things holistically, those are things that you really need to make time for and do on a regular basis, which I wish I had known when I took up the role.

Lenny RachitskyLooking back at your time at Block, I keep trying to, I almost say Square because I'm so used to that over the air, but I know Block is the name of the broader company and Square is just one. Just so people understand, Square is one business unit, one product within Block.

Dhanji R. PrasannaCorrect, yeah, we have Square, Afterpay, Cash App and TIDAL are four major brands, and then we also have Bitkey and Proto that are focused on Bitcoin for us and we chip hardware in those two brands.

Lenny RachitskyOkay, great. I think that some people are like, what are you guys talking about? Okay, cool. So reflecting back on your time at Block, what's maybe the most counterintuitive lesson you've learned about building products or building teams that goes against what most people believe, say common startup wisdom?

Dhanji R. PrasannaI think code quality is one. Being an engineer. I learned this very early on and it keeps coming true over and over and over again. A lot of engineers think that code quality is important to building a successful product. The two have nothing to do with each other, but my favorite example is YouTube. I was working at Google around the time YouTube was acquired and I just remember there was this whole wash of angst about how horrible the YouTube code base is and how terrible their architecture is, and they're storing videos as blobs in MySQL and whatnot.

And you could argue that YouTube is the most successful product at Google by a long way, maybe more successful than many of their others combined. And so it really has very little to do with how well it was architected because the flip side of that Google video, which is product that I don't know if people remember, it existed before YouTube. It supported more formats, it supported higher resolution.
You could upload hour long videos, YouTube had none of this. It just had the one or two minute quick video thing and it's far and away, blown away its competition. And so I think just keeping that front and center is why are we building these tools or these apps or these products? They're for people to solve a specific problem. So in our case, it's for a square merchant to make a sale, to sell coffee to you or to sell something they've made. And that's really what's important.
It's not really important how well our Android platform performs unless it's serving that need. And so I think that's been a really hard one for me over my career. And I continually encounter engineers who think we need to refactor, we need to do this in a better way. And then I'm like, "No, all this code could be thrown away tomorrow. So just focus on what we're trying to build and whom we're trying to build for."

Lenny RachitskyThat is an incredible insight and lesson. This YouTube story is so fun and such a good example. You're saying they were storing the video content in a MySQL set like row and column as a blob data.

Dhanji R. PrasannaYeah, this is what, I didn't actually look the code so I couldn't verify it, but this was the common wisdom. And then they had an entirely Python stack that was incredibly slow compared to the state-of-the-art C++ and Java servers that we had hyper-optimized at Google back in those days.

Lenny RachitskyThat is hilarious. It makes me think about also companies when you look inside a company, if you work at a company, you're just like, "This is just pure chaos. No one knows what's going on. This is just about to all fall apart." And that's basically what it's like at every successful hyper-growth company.

Dhanji R. PrasannaYeah, there's some truth to that for sure. Yeah.

Lenny RachitskyAnd so I think again, it's just there's so much more that is more important to the success of a business. And it's what you said is are you solving a real problem for people? Can you get in their hands? Can you continue solving real problems for them? It's not about the quality of the code, it's not how well you operate internally.

Dhanji R. PrasannaAbsolutely. I think on Cash App we had that as well. So in the early days of Cash App, I was head of engineering from when we were about 10 engineers to 200 plus and took us to about 10 plus or 20 million users thereabouts. And there was a very similar thing there. From the outside it looked like everything was really chaotic. It's like people would build random experiments and ship them and it just didn't look like we were following strict policies on things like software life cycle and stuff like that, and it was kind of true.

And my philosophy was always, we have all these brilliant engineers and I'm going to do more harm than good by trying to harness them into very strict blinkered areas. If they want to spin their wheels building something that is a complete waste of time for a little bit. But at the same time, if they're delivering these amazing things on the flip side, then I'll almost allow that. I'll be okay with that.
And it's a fine balance because engineers can really go off and into rabbit holes if you let them. But yeah, there's a certain amount of creativity that chaos breeds and you have to know how to build controlled chaos in some ways. So you have to create a foundation that isn't liable to rupture. You have major liability problems or something like that, or you're going to lose money in our case. And so as long as those things are bedded down and you allow your engineers to have the freedom to experiment and iterate and do the things that energizes them, that's the ideal.

Lenny RachitskySpeaking of controlled chaos, one of your titles during your time at Block, I guess this was while you were actually at Square, was Mad Scientist for four and a half years.

Dhanji R. PrasannaYeah, that was a time when I was working part-time, mostly because I had very young kids with lots of additional needs and I was a consultant on various different projects and I was trying to help some wacky things get off the ground. And yeah, I'm really grateful to Block that they afforded me the freedom to have that role in my career as well.

Lenny RachitskyMaybe one more question before I take us to Fail Corner, which I'll explain. So you've shared a few lessons of things you've learned over the course of your career. Are there any other, just let's say core leadership lessons that you've learned that you think have been important to you being successful at the work that you've done?

Dhanji R. PrasannaI think start small with everything. If you try to boil the ocean to make a cup of tea, I don't know who said that, but it's a really a useful phrase that I keep coming back to. You'll never get there. So if you're making a cup of tea, just make the cup of tea. You don't need to boil all the water that there is.

Lenny RachitskyThat sounds like really not delicious tea. Ocean water.

Dhanji R. PrasannaYeah, I think there's another one of, I think Carl Sagan said, "If you want to make an apple pie from scratch, you have to first invent the universe." So it's like narrow your scope to the thing that's in front of you and that's achievable. And so that I think is really important and that's one of our core tenets and always has been even when we were just Square in the early days, start small.

Lenny RachitskyIs there an example that maybe worked really well or maybe didn't work?

Dhanji R. PrasannaYeah, Goose started small. It was just an engineer working on their own time trying to build something that was useful and that satisfied a thesis that they had. So Brad, our creator of Goose, believed very early on, I think long before we heard the buzzword going around that agents would be how we unlock value from LLMs. And he built a proof concept and he shared it with a bunch of people. He shared it with Databricks and Anthropic, got them excited and learned a lot from them.

And so it just sort of built momentum from there. And even internally, it was quite a similar thing. Cash App itself was like that and Cash App started more or less as a hack week sort of idea and grew into a bigger and bigger and bigger thing. So a lot of our projects start with these small experiments that we try to then build on top of. We became the very first company that was a public company to launch a Bitcoin product. And that was again a hack week idea that actually Jack and me and another engineer worked on.

Lenny RachitskyThat was the hackathon team? You and Jack Dorsey and an engineer?

Dhanji R. PrasannaYeah, it was the three of us.

Lenny RachitskyUnreal.

Dhanji R. PrasannaYeah, and it was great. We went and bought a cup of coffee, a blue bottle, and it was bought using Bitcoin over cash card. And I'll tell you those in hindsight, probably the most expensive cup of coffee.

Lenny RachitskyWhat was Bitcoin at? 20,000?

Dhanji R. PrasannaI think it was 6,000 or 7,000 back then. I don't know.

Lenny RachitskyIt's like 120,000 now. Great.

Dhanji R. PrasannaBut yeah, it's an example of how you get to a working useful product to people if you focus on a small thing first in a build.

Lenny RachitskyAnd just to double down on this counter too. "Okay, we have a big idea, we're just going to put a bunch of resources on it and go big immediately."

Dhanji R. PrasannaYeah, absolutely. And I've been part of teams like that too. So in my career, I worked at Google on this product called Google Wave, which was trying to be everything to everyone and we were 70, 80 engineers building this thing before it even really had any users outside Google. And so I think that's an example of something that started big, tried to go big on day one and probably lacked some of that meeting the earth where reality lies and adapting accordingly.

Lenny RachitskyI remember Google Wave. Absolutely. It was beautiful. A lot of hype. I don't remember what it was for specifically, but it looked really nice.

Dhanji R. PrasannaYeah, a lot of learnings from that one for me. Yeah.

Lenny RachitskyWhat else? Any other big lessons?

Dhanji R. PrasannaThose two are the big ones, but I would also say question base assumptions on everything. Sometimes we get into traps where we are as professionals, hyper focused on what we're building that day, that week, that month. And we don't stop to think should we even build this at all? Or what's the purpose of building this?

Could we build something completely different that would matter more to our core reason for being? So I would say, yeah, question the sort of base assumptions. It's somewhat of a cliche, but you really need to remind yourself to apply it over and over and over again.

Lenny RachitskyI had a colleague of yours on the podcast back in the day, IO, who worked with you on Cash App.

Dhanji R. PrasannaYeah.

Lenny RachitskyHe's a friend of mine, he's amazing. He had a quote along those lines of just like, I forget exactly what it was, but it was just get to the bare metal of the thing that you're working on, just touch the thing that you're building and go to the base of it to really understand what's going on. And I imagine that was really important with Building Cash App and Cash Card.

Dhanji R. PrasannaYeah, IO is one of the best product people I've ever worked with and one of my closest friends actually. So absolutely with him, and you on that one, yeah.

Lenny RachitskyOkay. I'm going to take us to a recurring segment on the podcast I call Fail Corner. You already shared one example of a product that failed that you worked on. I'm curious if there's another, and the question is just what's the product you worked on that did not work out? Because people listening to this hear all these amazing successful people come on the podcast, share all these stories of success, endless success, but they don't hear the stories when things don't work out. And so this question is just, "What's a product you worked on that didn't work out and what did that teach you?"

Dhanji R. PrasannaIt's a very valuable point. My career has basically been a string of failed product on top of failed product. And I think that, "Yeah, the Google wave example's there." I worked for Hot Minute on Google+, which was another epic failure.

Lenny RachitskyGood one.

Dhanji R. PrasannaI worked at this social networking startup called Secret, which burned hot for a bright minute and then blew up. And then there was an email startup that we did, and that was, again, very promising, and then that fizzled. So the co-founder of Canva and I worked on that one. So there's been a whole string of failures, but at each point, I think I learned something and I learned that I need to never make that class of failures or errors again.

And so Cash App was probably the big success for me that a product that I worked on that was very early on and grew to be this giant business and product that people love. So yeah, been my career is essentially taking the learnings from all these failures, getting some humility out of it in the process too, coming into things, willing to listen to other people's points of view, critical points of view, and not just thinking that I have all the answers, yeah.

Lenny RachitskyAnd I bet all these products that failed had really beautiful code. A lot of really good architecture decisions were made. Some of them, some of them were awful in every way. So many reasons for it to fail. Incredible. Dhanji, is there anything else that you wanted to share or I don't know, double down on before we get to our very exciting lightning round?

Dhanji R. PrasannaI would say I think that we're in this era of a lot of change and people are scared or reticent or uncertain about where things are going. And I think that look at the things that matter to you. For us, it's open source, open protocols, improving access for everyone. I've been very lucky in my career to only work on products that are either free or almost free to anyone or they have a free tier and then you pay for some premium services and that are usable by everyone. So anyone can become a Square seller.

I remember even in the early days, people used it to pay each other as a peer-to-peer money transfer system and that's why we built Cash App and that was really successful on the back of that. So I think it's really look at the things that are important to you and optimize for them. It's not really that important that the technology trends are growing in a certain way because technology is here to serve us, and if we have an important reason for being and an important purpose, then we can make that technology serve us. And that's much more important than being deep with the technology or being at the forefront of every trend.

Lenny RachitskySuch great advice when there's so much to pay attention to and so much happening. So stressful to feel like I'm just not aware of all the things. I'm not as good as all these people I'm seeing on social media, but what's happening with AI, I'm just so behind. What I'm hearing from you is just like what is actually important to you? And just do that. Don't feel like you need to be the best at everything that's happening on top of all the latest AI news.

Dhanji R. PrasannaYeah, exactly. And if it's not meaningful and fun, then you shouldn't be doing it probably.

Lenny RachitskyWith that Dhanji, we've reached our very exciting lightning round. I've got five questions for you. Are you ready?

Dhanji R. PrasannaOkay. Shoot.

Lenny RachitskyI see so many books behind you. So I love this first question. I'm excited to see what you pick. What are two or three books that you find yourself recommending most to other people?

Dhanji R. PrasannaYeah, so I very much of the opinion that you shouldn't read books that are about your daily work or your professional life. I read fiction, I read the classics, I read poetry, philosophy, history. These are the books I really enjoy. And I think it expands your mind and gives you creative ideas and helps you question things about the human condition.

And that's much more valuable than some self-help book or some get good at being an engineering manager book. So yeah, having said that, the Master in Margarita by Mikhail Bulgakov is one that I really love. It's a masterpiece of Russian literature. And then I've always been drawn to Tennyson's poetry and I find that in the times when I'm most uncertain or grieving, Tennyson's poetry has always resonated with me and helped me find a center.

Lenny RachitskyWow. Never heard these recommendations before. I'm really excited to check these out. Very cool for a CTO of a big tech company. What is a favorite recent movie or TV show you've really enjoyed?

Dhanji R. PrasannaAlien Earth I think is pretty awesome. It's by Noah Hawley who did the Fargo TV series. And so it's someone with all of these incredible skills in high art filmmaking who's doing a pulp sci-fi show, and it just looks stunning and it feels stunning and it captures all of that essential alien pulpiness that makes it so interesting and fun. So I really like that, and I'm also watching Slow Horses, which I think is one of the better shows on TV.

Lenny RachitskyLove Slow Horses. The new season's Out, think the fifth episode just dropped the day we're recording this. So I love that show. Alien Earth also just watched it, so creepy and just like all these slimy, gooey little creatures just crawling around.

Dhanji R. PrasannaYeah, I just love the aesthetic and they captured something essential about the original Alien and yeah, they do it, but every scene in Alien Earth feels like you're watching a painting or something or someone's reading a novel to you. It's really unfolds very thoughtfully.

Lenny RachitskyI've never watched any alien content in my life and I really enjoyed Alien Earth. I will say the ending, I was just like, it felt like it kind of slowed down a bit. I'm just like, "All right, I guess I see where it's going now." But it was really fun to watch. Okay, next question. Do you have a favorite product you really enjoyed? Sorry, a favorite product you've recently discovered that you really enjoy? It could be an app, could be an gadget, could be some kitchen thing.

Dhanji R. PrasannaWell, I'm a gamer. I love playing games. So for me it's the Steam Deck, the Steam Deck OLED, which is their latest version. It's like this gorgeous piece of hardware that lets you play the best games out there, but it's totally extensible and customizable. And in this era where we're constantly told by big tech companies that we need to lock everything down, we need to lock down the user experience and customizability in order to have things work for people.

I think Valve showed that's totally unnecessary and totally wrong, and you can build the Steam Deck. You can install competing app stores, you can install Windows on it. You can treat it like a computer, write programs, which I have done to run on it. So yeah, I think it's an incredible thing and it looks beautiful and it works great. So yeah, big fan.

Lenny RachitskyDo you have a favorite life motto that you find yourself coming back to often in work or in life?

Dhanji R. PrasannaIf you're not waking up in the morning feeling energized about what you're going to do that day in your professional life, then change something, quit if that's what it comes down to, or find a new way of doing what you're doing. Just don't accept what's meted out to you. So that's how I've tried to do things, and sometimes it works, sometimes not, but yeah, it's a good thing to ask yourself.

Lenny RachitskyI really love this advice. It's really hard to do that for a lot of people. Is there anything that has helped you get over that fear of just like, "Oh man, I'm going to quit this thing. I don't know where I'm going to go next."

Dhanji R. PrasannaThe main thing is telling yourself that a year from now, you're going to look back on what looks like a monumental problem, a life-changing thing, and you're going to be like, "Oh, that was so trivial." A lot of times we get into these traps where we're overthinking something or really nervous about making a change, but in hindsight, those don't seem that big.

And all the time that's passed since and all the events that have happened teach you that there's more to the world and it's never too late to do something useful or never too late to do something that's for yourself and improving yourself. So yeah, I think just kind of remembering that things are not as big or bleak or decisive as they seem in the moment is always important.

Lenny RachitskyFinal question. So you were a mad scientist at Square for many years. Do you have another favorite mad scientist from pop culture or real life?

Dhanji R. PrasannaThat's an interesting one. I think the image that always comes to my mind is Doc Brown from Back to the Future. I feel like he's the canonical mad scientist of my generation anyway, but there've been a lot in video games and stuff too, but he was the one that was like, "I'm just going to do this crazy thing because I almost have this burning desire, need to do it, and whether I want to or not, I must build this time machine." And he spends the entire movie trying to fix the problems that it creates. But yeah, he has always been a really fun character for me.

Lenny RachitskyYou know what? I think about Pinky from Pinky in the Brain.

Dhanji R. PrasannaOh yeah, that's a good one too. Yeah.

Lenny RachitskyOh man. Dhanji, this was awesome. You were wonderful. Thank you so much for being here. Two final questions before we actually wrap up. Where can folks find you online if they want to reach out, learn more about say Goose or anything else going on at Block? And how can listeners be useful to you?

Dhanji R. PrasannaCheck out our GitHub pages for Goose and all of the other open source projects we have at Block. So there's a lot that's useful there. We do a lot on Android open source as well, so check that stuff out. You can always find me on LinkedIn, so feel free to connect. I'm very happy to be contacted.

And I would say the way people can be useful is, again, going back to this era we're in of a lot of change and uncertainty, I think people that demand more of their companies, of their employers, of their teams, demand something better. At Block, we always ask, "Can we default to making this open source? Can we build this for people that are not just us or our customers? Can everyone benefit?"
And I think that's particularly important in this era of AI where everyone's locking themselves in walled gardens and trying to capture parts of the platform that are emerging. So yeah, just demand more of people. The internet was created as a promise for open sharing of information to the benefit of all, and I think that AI should realize that for us. And so yeah, just demand that of people.

Lenny RachitskyA really beautiful way to end it. Dhanji, thank you so much for being here.

Dhanji R. PrasannaThank you, Lenny. I really appreciated it. Thank you.

Lenny RachitskyI appreciate you.

Dhanji R. PrasannaCheers.

Lenny RachitskyBye everyone. Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennyspodcast.com. See you in the next episode.

English Original transcript

Lenny RachitskyThere's a lot of talk about productivity gains through AI. There's this camp of people that are so overhyped, nothing's working, nobody's actually adopting this at scale.

Dhanji R. PrasannaWe see a significant amount of games. We find engineering teams that are very, very AI forward are reporting about eight to 10 hours save per week. Whenever I hear a stat like this, I think an important element is this is the worst it will ever be. This is now the baseline. The truth is the value is changing every day, so you need to ride that wave along with it.

Lenny RachitskyThere's a story I heard you share on a different podcast where there's an engineer who has Goose watching.

Dhanji R. PrasannaYou'll be talking to a colleague on Slack or an email, and they'll be discussing some feature that they think is useful to implement. Now a few hours later, he'll find that Goose has already tried to build that feature and opened a PR for it on Git.

Lenny RachitskyWhat level of engineer is most benefiting from these tools?

Dhanji R. PrasannaWhat's been surprising and really amazing, the non-technical people using AI agents and programming tools to build things, the people that are able to embrace it to optimize for their particular workday and their particular set of tasks are really showing the most impact from these tools.

Lenny RachitskyHow do you think things will look in a couple of years in terms of how engineers work that's different from today?

Dhanji R. PrasannaAll these LLMs are sitting idle overnight and on weekends, while humans aren't there. There's no need for that. They should be working all the time. They should be trying to build in anticipation of what we want.

Lenny RachitskyWhat's maybe the most counterintuitive lesson you've learned about building products or building teams?

Dhanji R. PrasannaA lot of engineers think that code quality is important to building a successful product. The two have nothing to do with each other.

Lenny RachitskyToday my guest is Dhanji Prasanna. Dhanji is Chief Technology Officer at Block, where he oversees a team of over 3,500 people. With Dhanji's leadership, Block has become one of the most AI-native large companies in the world and has basically achieved what many eng and product leaders are trying to achieve within their companies.

In our conversation, we chat about their internal open source agent called Goose, that by their measure is saving employees on average eight to 10 hours a week of work time, and that number is going up, how AI specifically making their teams more productive and the teams that are benefiting most. Interestingly, it's not the engineering team, what it took to shift the culture to be very AI-oriented, the very boring change they made internally that boosted productivity even more than any AI tool.
And there's something big happening in messaging that product teams need to know about. Rich Communication Services or RCS. Think of RCS as SMS 2.0. Instead of getting texts from a random number, your users will see your verified company name and logo without needing to download anything new. It's a more secure and branded experience, plus you get features like interactive carousels and suggested replies, and here's why this matters. US carriers are starting to adopt RCS.
Suddenly, I could involve my whole team in the design process, give feedback on design concepts really quickly, and it just made the whole product development process so much more fun. But Figma never felt like it was for me. It was great for giving feedback and designs, but as a builder, I wanted to make stuff. That's why Figma built Figma Make. With just a few prompts, you can make any idea or design into a fully functional prototype or app that anyone can iterate on and validate with customers.
Figma Make is a different kind of vibe coding tool, because it's all in Figma. You can use your team's existing design building blocks, making it easy to create outputs that look good and feel real and are connected to how your team builds. Stop spending so much time telling people about your product vision and instead show it to them. Make code back prototypes and apps fast with Figma Make. Check it out at figma.com/lenny. Dhanji, thank you so much for being here and welcome to the podcast.

Dhanji R. PrasannaThank you Lenny. It's a great pleasure to be here.

Lenny RachitskyI want to start with a letter that I hear you wrote to Jack Dorsey to convince him that he and that Block needed to take AI a lot more seriously. I think you called it your AI manifesto and it seems like it really worked. We're going to talk a lot about the changes that came as a result of that. So let me just ask, what did you say in this letter and what happened right after you sent that letter to him?

Dhanji R. PrasannaSo about two and a half years ago or so, Jack really felt like things needed to change. I think he had a sense that the industry was going in a different direction. So he got about 40 of the company's top executives into a room on a weekly basis, and they all used to sort of talk everything through that was going on and he added me to that group.

So at some point, I observed that we were talking about lots of deep things, lots of relevant things, but no one was really paying attention to AI, and so that's when I wrote that letter. And to be honest, it's I think taken on a life of its own, but there wasn't much to the letter other than I think we should do this. I think we should do it centrally and it's important for us to be ahead of the game and be an AI native company because that's where the industry is heading.

Lenny RachitskyLet me just say it's important to note you were not CTO at this point. You were just a senior engineer kind of person?

Dhanji R. PrasannaNo, yeah, in fact, I was part-time at the time because I had just had a kid and I was coming back in and I was helping out one of the engineering teams and then Jack came over to Sydney and spent two days with me and both of us like long walks. So we walked all around Sydney and talked it through up and down, and then yeah, he offered me the job and I thought it was a great opportunity once in a lifetime, so I took it.

Lenny RachitskyIt's like be careful what you're good at sort of situation. Okay. So what were some of the bigger changes that you made after Jack is on board and Block execs are on board of are, "Cool, this is completely right. We need to go much bigger and think much more deeply about how AI is changing, how we build and how we should build." Or some of the bigger changes that you made from a perspective of other companies listening to this, trying to think about what they should be doing?

Dhanji R. PrasannaAt the start, my main focus was to get block to think like a technology company. And for a long time we had had a little bit of, I'm going to call it identity drift, maybe. We were talking about ourselves as a financial services company. Some people called us FinTech, all of this stuff. But when I started working at what was then known as Square, we were always thought of as a technology company just like Google or Facebook or any of the others.

And so I wanted to get us back to that. And so the first thing I did was to try and institute a number of programs that focused on that. So everything from getting the top ICs in the company together to talk to each other, to starting a whole bunch of special projects. So we got about two to five engineers per project. There were about eight or nine different projects and we had reinstituted, the company-wide hack week.
And so all of this just kind of created a little bit of a spark of, "Hey, we're building technology again, we're trying to push the frontier again." And that's how it started, and then there were a whole number of steps after that where we went from a GM structure to a functional org structure, which was I think the key to making our transformation into being more of an AI-native company.

Lenny RachitskyOkay, talk more about that. What does that mean? What does that look like? Why is that so important?

Dhanji R. PrasannaAbsolutely. So when we were in our mature phase, so when Square was working quite well, it was a very large business, and then we had started Cash App and that also followed suit. We had spun them out almost as what we call a GM structure. So they were effectively run as a portfolio of independent companies and they had their own CEOs who all reported to Jack and it was still one single executive team, but they had separate engineering practices, they had separate design teams.

They were kind of separate in almost every way except for some shared resources like our foundational resources like legal and some platforms and things like that. So I think that that was very useful for us for the stage of company that we were in, but when you really want to go deep in technology, when you really want to connect with these things that are industry changing events that are happening, you need a singular focus, and we changed the organization.
So all engineers report into one single team now, all designers report into one single team and there's single head of engineering, single head of design, et cetera. And so that was the big transformation that we made, and that meant we could really drive forward AI, we could drive forward platform and just technical depth generally.

Lenny RachitskyFor companies that are struggling with this potentially or trying to figure out how to do this, two things I'm hearing here is start to see yourself as a technology company. It doesn't necessarily apply to every company, but seems like an important element is like we're building technology, we're not a financial company, we're not a real estate company, we're not a technology company. And then two is organize the team such that say engineers report up to an engineering leader versus a GM who maybe doesn't understand engineering as well or doesn't take it as seriously as they should.

Dhanji R. PrasannaYeah, I think that's pretty much what we did. And not to lean too heavily on this, but this is what jobs did when he came back to Apple as well. He reorganized Apple to be functional, and it wasn't like we were following a playbook. We discovered this as we were investigating what it's going to take to make these teams more tech-focused and to bring our DNA back to our roots, which really was putting engineering and design first, which is what technology first means to me. So yeah, I would say to companies, find your DNA and really try to optimize for what that is in a very simple and clear way.

Lenny RachitskyOkay, so you made a bunch of changes, you had this manifesto, everyone's on board, you made a bunch of changes. Functional technology first, comparing the way that your say engineering team works today versus two or three years ago, what is most different?

Dhanji R. PrasannaNot everyone was on board, I'll tell you that. It was quite a painful transformation. I think that one of the things that I learned the most throughout this process is that Conway's Law can be really, really powerful. So it's the law that basically says you ship your org structure. So what you're organized as in terms of teams, in terms of collaborating groups and your operating model matters a lot to what you build.

And so I think that that was essentially the biggest change is we had a lot of momentum in each of these silos, be it Cash App, be it Afterpay, be it Square or even TIDAL or music streaming service. And no one was really talking to each other, no one was really aligned on technical strategy on what we even wanted to be five years from now as a collective team. And so all those things are different now. I'm not saying it's perfect, there's still a long road ahead of us, but we at least speak the same language.
We're all have access to the same tools, we share the same policies. So a certain level of senior engineer means the same thing across the whole company. People can move from one team to another's into an area of need. All of these things are very different. But to sum it up, I would say we're technically focused and we're focused on advancing technical excellence as a goal. And that just really wasn't that true two to three years ago. There were other things we were optimizing for then.

Lenny RachitskyMaybe going one level deeper in terms of how people actually work at a day. So if you're looking at an engineering team, say the average engineering team and maybe also the top most optimal engineering team, how is the way they work today different from a couple of years ago?

Dhanji R. PrasannaIn the small, certain teams that are very, very AI natives or teams that are building AI first everywhere are working much differently than before because they're using vibe code tools and they're essentially building without writing lines of code by hand, and that just wasn't true through the three years ago. I don't think it was true anywhere in the world. So that's dramatically different in teams that are still working with very heavy legacy code bases.

It's less true, but they're also encountering these background AI processes. So we have these tools that run 24/7 or run in the CI pipeline and they're analyzing vulnerabilities. They're looking at even bugs filed on tickets and trying to build patches while engineers are asleep. So they come in the next day and look at it. So I would say there are a number of ways in which they're different, but different teams have adapted in different ways depending on how close they are to the tools.

Lenny RachitskyOkay, so let me lean into that AI piece, which is I think where you guys are most ahead of a lot of other companies. You guys built your own agent I think is how you describe Goose. So there's a lot of talk about productivity gains through AI. There's this camp of people are like, you don't understand how much productivity there is to gain from AI. It's the future, this is the way it's all going to work.

We're all accelerating 10X. There's also this camp where people are like, I'm so overhyped, nothing's working. People talk about it. All these pilots are failing. Nobody's actually adopting this at scale. I feel like you're probably in that first camp. What sort of gains have you seen practically from AI tools on your teams?

Dhanji R. PrasannaOur number one priority is through automate Block, which means getting AI and getting AI forms of automation through our entire company. And we feel that that's just at the beginning of where the utility is with all these large language models, and I think we're going to continue to see that improve. But even now, we find engineering teams that are very, very AI forward that are using Goose every day are reporting about eight to 10 hours saved per week, and this is self-reported. And then we also have a number of check metrics to try and validate that.

So we look at PRs, we look at throughput of features, we look at a whole bunch of things and we have our data scientists come up with a complicated formula that tries to distill it all into something meaningful. And we feel across the whole company, we're probably trending towards 20 to 25% of manual hours saved. And I think that's just the start of all of this. I do feel that the more AI-native companies are doing a better job of realizing this.
So companies that started just with AI startups mostly, but there is some truth to this notion that AI isn't a panacea and it's growing as well in capability. So you need to ride that wave along with it. And I think a lot of the companies aren't realizing this. They're like, "Well, where's the value?" And the truth is the value is changing every day. And so you need to be adaptable and look at what the value is today and plan for what the value will be tomorrow and then slowly expand to the areas where it's most efficacious.
I'll give you an example. One area in which we find that it's really good is for non-technical teams to be able to build little software tools for themselves. So this has been one of the most surprising and energizing uses of Goose within Block is we'll have our enterprise risk management team build a whole system for self-servicing enterprise risk, and this is compressing weeks of work into hours, or ordinarily, they would be waiting for an internal apps team or something to go and build that and they would put that on their Q2 roadmap and everyone would be twiddling their thumbs until it all clicked into place, but now you can just go and do it.
And so a lot of these kinds of use cases we're seeing an enormous amount of productivity gain in the other area, which I'm really excited about is we have this other tool called Gosling, which is a goose for mobile effectively. So it operates your Android OS at a native level using the accessibility API. And we use that for automating UI tests.
So before, you would have to hire an army of contractors or QAs who would go and click through every screen, but now we can just bake those into automated tests and then give you a report at the end. So we're seeing a lot of advantages in those types of areas, but where you have a lot of depth and a lot of really strong people come together is where AI, I think still underperforms humans. And that's something that's probably going to get better over time, but it's also something where we should lean into as humans.
So when you have some very senior engineers and they're thinking about things like architecture and design and race conditions, orchestration, things like this, that's still an area where AI isn't quite there. And so I think the companies that aren't feeling the success in AI are trying to just throw these tools at their giant code bases and hoping good things will happen, and that's not how it's playing out. Eventually, I do think it'll get there, but right now we're still in the early utility phase.

Lenny RachitskyHoly moly, there's so much there in what you just shared. There's like five things I want to follow up on. Okay, so one is this metric you kind of alluded to, which is how you measure the impact of AI in your team. So it was human manual hours saved, is that how you describe it?

Dhanji R. PrasannaThat's correct. Yeah.

Lenny RachitskySo it's roughly a fourth of an engineer's time currently is being saved by AI tooling.

Dhanji R. PrasannaThat metric is across all teams. So that would be our support teams, our legal teams, our risk teams, all of them together.

Lenny RachitskyWow.

Dhanji R. PrasannaAnd then on the engineering side, it's very variable because like I said before, it matters how big and how complex the code base is. And so if you're building a totally new Greenfields code base or you're building an app for a new platform, then we're seeing those pretty aggressive gains, but in very complex code bases that already exist, those gains are not quite there yet.

Lenny RachitskyThat's amazing. And whenever I hear a stat like this, I think an important element that people need to think about is this is the worst it will ever be. This is the lowest, this is now the baseline. And so it may not sound that crazy yet, but it's going to get crazy. Okay, the other thing that you talked about is Goose, you haven't explained what Goose is. This is a huge deal. Explain what Goose is and how important this has become to you guys.

Dhanji R. PrasannaSo Goose is a general purpose AI agent. So you can think of it as a desktop tool or a program that you can download and install on your computer and then it has a UI. You can talk to it just like a chatbot and you can say anything from, "Hey Goose, organize my photos by category, and it has the ability to look within your photos and if there are a lot of trees, it'll organize them as nature photos. And there are a lot of people, it'll organize them as portraiture." All of this sort of stuff to writing software for you.

So it can do all of these tasks, and the way we've been able to do this is through something called a model context protocol or the MCP, which a lot of your listeners might've heard. And this is something that Anthropic came up with that we were a very early contributor to. And the model context protocol is very simply just a set of formalized wrappers around existing tools or existing capabilities. So if you have tools that you use in the enterprise, be it Salesforce or be it Snowflake or SQL, any of these things, you can wrap them in the MCP and then it exposes them to your LLM to be able to manipulate.
So until that point, the LLMs were not really able to do much other than chat, but Goose gives these brains arms and legs to go out and act in our digital world, and that's where we find it's had most impact and it's built on this fairly open protocol that anyone can implement. There have been an explosion of MCPs. Goose is entirely open source, by the way, so any of you can download it and extend it, write your own MCPs, and that's been our core successes through Goose.

Lenny RachitskyOkay. So essentially like Claude code with a UI, desktop app sort of thing built on top of Claude and OpenAI ChatGPT and a bunch of open source models. Is that right?

Dhanji R. PrasannaYeah, it can use any model. So we have a pluggable provider system and you can either bring your own API keys and use the Claude family models or OpenAI's family models, or you can use open source models and you can download them and use them directly or via Ollama and other, there are several tools that help you do that, but essentially it's taking the capability of these models to generate text and to interpret text and applying them to real world situations.

So one example that I really like is you can ask Goose to go and build your marketing report and it has MCPs to connect to Snowflake and Tableau and Looker. So it'll write SQL to pull out data from there, it'll do some analysis and a CSV so it can write Python code on your desktop to do all that. It will generate some graphs using some JavaScript charting library that it knows about.
And then finally, it'll put this all into a PDF or Google Doc or whatever and it can even email it for you or upload it somewhere. And it's doing all of this on its own, by the way. No one's sitting here telling it that, you're just saying, "Hey, I want this report, I want this emailed here, I want these pretty charts." And it's orchestrating across all these systems.

Lenny RachitskySo essentially at Block, instead of using Claude or ChatGPT directly or even Cursor and all these apps, they use Goose?

Dhanji R. PrasannaYeah, we allow our engineers and our general employee population to use any tools that they want. Goose is the one that's most well-integrated into all of our systems because it's built on the MCP and it's so easy to create an MCP for an existing system. So for example, if you're using a issue tracking tool and you want some AI automation added to it, before Goose, our teams would have to wait for the vendor to build that AI capability in there, or maybe there's some way in which OpenAI or Anthropic or Google would provide a general purpose capability where we could plug those in. But with Goose, that's no longer necessary with a few lines of code that an MCP represents. All these systems are orchestratable with AI basically overnight, and Goose can write its own MCPs. So it's pretty bootstrappable as well.

Lenny RachitskyAnd this is open source and basically you've spent all this time building this thing, any other company can now implement it and build on all the work you've done?

Dhanji R. PrasannaYeah, and we have a lot of companies using Goose pretty actively. I don't want to name too many names, but from our competitors to our close partners, a lot of them are using Goose pretty regularly on their teams. I know Databricks talks about it a lot, but everyone you can think of in this mid-tech tier is using Goose in some form.

Lenny RachitskyThat's insane. This feels like it could've been a massive business of its own, some of the fastest growing companies in the world, basically this is their product and you've built it and given away.

Dhanji R. PrasannaYeah, we believe in the power of open source and one of our core missions is to increase openness, and that means contributing to open protocols and contributing to open source. And as a tech company, we're built on a lot of open source software. I think pretty much every tech company is whether you're talking about Linux or Java or MySQL or any of these essential components, and so we feel like we have a strong imperative to give back.

We want to build things that not only are good for us and our customers, but that outlast Block and outgrow Block, that's certainly a core value for us and has been from the beginning even long before this whole AI phase. So yeah, Goose follows in that proud tradition and yeah, we're very excited that its had the success it's had.

Lenny RachitskyWhat's the story with the name Goose, by the way? Can't help but ask.

Dhanji R. PrasannaGoose is a Top Gun reference. So our engineer that came up with it. He also looks exactly like Goose, so it's kind of crazy if you put them side to side, he's going to be really embarrassed with my sharing this, but that's the reason why they call it Goose, and then we lent into the whole bird theme after that.

Lenny RachitskyThat's incredible. There's a story I heard you share on a different podcast where there's an engineer who takes this to the extreme and has Goose watch him. Talk about that, share that story.

Dhanji R. PrasannaYeah, absolutely. So he is very, very AI-focused and he's trying to extract all these crazy ideas from Goose and Goose can do all of the things that I described through specific interactions with tools, but it can also just watch your screen so it understands how to process images and process the things that it's looking at through screenshots. And so he built this system where it's essentially just watching everything he does all the time and he'll be talking to a colleague on Slack or an email and they'll be discussing some feature that they think is useful to implement.

And then a few hours later he'll find that Goose has already tried to build that feature and opened a PR for it on Git and all sorts of other wacky things like that. So it'll try to nudge him out of a workflow. If he's running over on a meeting and he's late for something else, it comes up with these creative things that he didn't program or he didn't write prompts for, but that it thinks will help him improve his productivity or improve his work day. So yeah, it's pretty crazy. You have to have the stomach for it to be that level of tied into your working tools, but it kind of shows you what's possible with tools like this.

Lenny RachitskyClearly this is where things are going. Once this gets good enough, I love this guy is just trying it. So it's basically watching him work and anticipating what he should be doing and does the work for him as a first draft so that he's like, "Oh, the PR is already done on this thing. We were just talking about it at this meeting." That's incredible.

Dhanji R. PrasannaExactly.

Lenny RachitskyHow good is it? Where's it at? If you had to go zero to a hundred of like, "Okay, going to, all you have to do is now think and talk and that'll just do your job."

Dhanji R. PrasannaYeah, so voice is the other big part of it. It has voice processing capability, so it's always listening to what he's saying as well and trying to interpret that. I would say that this is mostly an experiment, given that he's on our core Goose team and he contributes to Goose, so he has a day job. This is a kind of thing on the side that he was developing.

So once this evolves into more of a native feature of Goose itself or other tools that we use in the enterprise, I think it can have a lot of legs, but it's already pretty good. It's probably cutting down enormous amounts of busy work that he has to do. So for example, one thing he'll do is he'll say, "Oh, I have a meeting conflict. I can't make it that time, or I have to go pick up my kid."
And Goose will automatically reschedule that meeting without him ever sitting in front of his calendar and clicking through 10 times. Yeah, so these are things that I think we were waiting for the calendar vendor to build as features into calendar, but we don't need to do that anymore because AI is able to orchestrate this for us.

Lenny RachitskyThis isn't that guy that had four jobs at four different startups that he was able to paralyze all his work and hire people.

Dhanji R. PrasannaNo, it's not. He's someone that I've worked with for a long time and he's been at Block for a long time. He just loves experimenting and he embodies that culture of experimentation just like our creator of Goose who did the same thing.

Lenny RachitskySo let me pull on that thread a little bit. You're kind of seeing a glimpse of where things are going. You're very ahead of the curve in a lot of ways at Block. How do you think things will look in a couple of years in terms of how engineers work, how product teams work that's different from today?

Dhanji R. PrasannaI think a lot of it is dependent on the improvement of LLM performance, but I can tell you the way I'm trying to change how I work and how I'm trying to change our immediate team's way of working. So I think vibe coding has been an interesting, exciting thing, which is you talk to a chatbot essentially and it goes and builds software for you, but I think this is highly limiting.

It's very ping pong. You do something, you wait for three or four minutes and it comes back with something sort of half-baked and you have to nudge it and guide it and massage it to get where it needs to be. I think that we're going to see much more autonomy. So where we're working on a couple of experiments with Goose, with the next version of Goose where we're really trying to push it to work not just for two or three or five minutes at a time, our median session length is five minutes and on average, seven, but we're trying to push it to hours.
We're trying to say, "Hey, all these LLMs are sitting idle overnight and on weekends while humans aren't there, there's no need for that." They should be working all the time. They should be trying to build in anticipation of what we want if we go back to the earlier part of the conversation. But also I think that they should be able to build in ways that were never possible before.
Before as humans, we had limited resources, limited bandwidth, and a lot of coordination overhead. So we would have to choose the best path to try in an experiment, and I don't think we need that anymore. We need instead to be able to describe multiple different experiments in a great amount of detail. And then maybe we go to sleep and then in the morning, all those experiments are built and we can sort of throw away five or six of them.
So one of the things that I do regularly, so I write code every day, but one of the things that I do regularly is just throw away huge, huge amounts of code, and it's kind of hard for me because I've never done that before. I mean obviously engineers love deleting code, but this is different. You build a whole new system or a whole new feature and you're like, "Ah, it doesn't feel exactly right. I'm just going to delete and start over."
So I think you're going to see a lot more of that way of working. And I think that you're going to see instead of us, for example, refactoring an app to have a different UI or to evolve into its new version, we're just going to rewrite that app from scratch. And one of the things I'm really pushing our teams to think about is what would our world look like if every single release, RM minus RF deleted the entire app and rebuilt it from scratch? And so we can't really do that today, but I think this shows you some of the direction of what's possible and where these tools are taking us.

Lenny RachitskyWhat's interesting about that is that there's this common rule in software engineering and just product, don't ever just rewrite. Don't try to rewrite your thing. You're going to forget all of the small improvements and tweaks and bug fixes people have made over the years, and you think it's going to be the simple straightforward thing. It ends up being now it's like a year or more of just getting it back to where it was. And so interesting that AI now can make that possible, and what you're saying is that's actually maybe the way you should be working.

Dhanji R. PrasannaI think so. And I think that the trick is getting the AI to respect all of those incremental improvements, yeah, and sort of bake those in as a part of the specification, if you will. Yeah.

Lenny RachitskyAlso, the point you made about this agent, just you give it a bunch of ideas that builds them overnight and then you could see, I imagine it goes even further up the stack and comes up with the ideas and then starts building them and then you're like, "Okay, oh, that was a great idea. Now I can see it immediately in the same workflow."

Dhanji R. PrasannaYeah, that's true. I was actually literally trying what you're saying just last week. And so I have this new version of Goose that we're working on and I was asking it to come up with ideas to improve itself and implement it overnight. And sometimes-

Lenny RachitskySlip problem.

Dhanji R. Prasanna... Sometimes it kind of goes off the script entirely and you have to sort of pull it back a bit. So I think we're not quite at that era where it's completely self-improving and completely autonomous, but I do think we're in a transition phase where we can give it that nudge and say, "Hey, here's my wishlist of 10 things that I wish you could do. Go and figure out the best way to do them." And it's successful I would say on 60% of those things, if the features are well enough described and it struggles on the remaining 40 where you have to kind of intervene and massage it. Yeah.

Lenny RachitskyOh man, I'm just imagining this feature where you give it the goal of drive revenue and growth and then it's just like, "Okay, everyone's fired. Here's your paychecks. I'll take it from here."

Dhanji R. PrasannaI don't think we're going to be there. I do think we're going to need a lot of human taste to anchor these AIs so they don't go off script to be honest. And that's really where our design lead and our design teams are pushing us to think, and that's a differentiator that I think will push us beyond this era of AI slop that everyone's talking about. So yeah, it's very much anchoring it into a thing that matters to people and the thing that's tasteful and useful and has value.

Lenny RachitskyTo make that even more concrete, is there an example of something maybe AI was trying to, or a team was trying to pitch where you had to just know this is where humans are going to step in and keep things on track?

Dhanji R. PrasannaI'd say it was more around things like process automation or a lot of times I'll get this sort of request where a team will say, "We need to buy this new tool from this vendor because our current tool is entering X, Y and Z." Another team will say, "No, no, no, we can just use Goose to build an app that will do the same thing for us in half the time or less." And then as a human, you're sitting there thinking, "Is any of this necessary? If we just change the process, do we even need to think about building tools?" And this is the thing that AI isn't good at, it's not able to have this portfolio judgment or judgment across a global sense of what's important and what matters.

So a lot of times, I tell teams just question the base assumption, particularly our InfoSec teams because they'll twist themselves into knot sometimes trying to secure something and you'll be like, "We'll just ask the team that's building it to do it differently or to not build that at all if it doesn't matter, and then you won't have to increase your surface area of securing it." So I think those are the areas where it's better for a human to use judgment and AI has not done a great job.

Lenny RachitskyYou make this point about building your own software, your own tools instead of buying stuff. This is a big question with AI, is it's going to replace all these SaaS apps to Salesforce over. Is there a sense of just either how much money you guys have maybe saved building your own stuff, or have you built a new-found respect for the existing SaaS software that everyone's using and pays lots of money for?

Dhanji R. PrasannaI think there's a trap in getting away from your core purpose as a company. And our core purpose is economic empowerment. So getting customers or merchants or artists the ability to make a sale or pay their rent or upload their latest creation to TIDAL. And I think that anything that serves that purpose, we should encourage and we should invest in, but if we're just purely looking at dollars versus dollars, then that's pulling us off that purpose.

The savings and costs that there might be in replacing a vendor tool by something you build in-house is probably not worth it in the mental bandwidth that you've lost and the amount of the team's technical focus that's being taken away. So yeah, I would say it just keep coming to the thing that matters to you as a company and then the rest will follow from that.

Lenny RachitskyYeah, I think people forget just how much maintenance it takes to keep something you've built. Like, "Okay, cool, we built it in a weekend and now it's years of endless maintenance and requests and support." And also to your point, it feels like it comes back to the always motto of just focus on your core competencies and then buy everything else.

Dhanji R. PrasannaYeah, it's the classic 80/20 problem, and we have that enough with the apps that we build for our customers. We'll build some great experiments that really resonate, and then we have to spend a lot of time ironing out the long tail of problems. So in Cash Card, for example, we built the entire functionality of Cash Card, I would say pretty much in a weekend or maybe a week of integration and work.

And then it took a really long time to iron out all these edge cases where someone would tip twice the value of the bill and then it would completely break something in the back end, or people would use it as a gas station and they have a different way of billing your card. So yeah, it's very much that. And to your point, I would always come back to what is the reason we're doing this? Why does it matter to us and to our customers? And if it doesn't clearly satisfy that, I would just push it off as a not interesting thing.
Persona helps combat these threats with automated user business and employee verification. Whether you're looking to catch candidate fraud, meet age restrictions or keep your platform safe, Persona helps you verify users in a way that's tailored to your specific needs. Best of all, Persona makes it easy to know who you're dealing with without adding friction for good users. This is why leading platforms like Etsy, LinkedIn, Square and Lyft trust Persona to secure their platform persona is also offering my listeners 500 free services per month for one full year, just head to withpersona.com/lenny to get started, that's withpersona.com/lenny.
Thanks again to Persona for sponsoring this episode. One of the biggest parts of the conversation around AI is hiring jobs, things like that. So I have two kind of this two-part question. One is just how has the rise of all these AI tools, this increased productivity impacted the way you plan head counts and hire? And then what do you look for that's different in people you're hiring now that AI is such a big part of the way you guys work?

Dhanji R. PrasannaI don't think that things have progressed far enough that it's really impacted in a fundamental way how many people you would need to build an app of the scale of Cash App, for example. I think what's changed for us is much different and it has nothing to do with AI, it's what we talked about earlier is moving from our GM structure to a functional structure. And in our GM structure, our incentives were always to think of engineering headcount as a commodity.

And so we would just add more engineers if we wanted to build more features and the classic mythical man person month trap or whatever it's called. And I think that moving to a functional structure completely changes that and you're like, "Well, we can leverage common platforms, common modules, we can bring in experts from across the company to advise us on how better to do this."
And so those kinds of things I think have made it much different and how we hire and we no longer see engineers as a commodity to just add 100 people to go and build the next product in Cash App. But on the AI side, we're very much looking for people that are embracing these tools and that are eager to try and learn from it. We're not looking for people who are amazing AI practitioners on the get-go.
I think we have those people and we're interested in those people if they ever want to work with us. But I'm much more keen on looking for that college grad who just really is eager to learn about these tools and open to it, or even the veteran who has embraced these tools and figured it out. And that's kind of where we're optimizing for who we look for rather than a specific set of skills.

Lenny RachitskySo essentially the biggest change is just looking for people that are embracing AI, not being like, "No, I don't need this stuff. I'm an amazing engineer. I don't need to use Cursor or Goose or all these things."

Dhanji R. PrasannaYeah, a learning mindset is how I would put it. This is something that Jack our CEO talks about a lot is he wants us to be a learning first company. So everything we do, every experiment that we ship, what can we learn from it and did we feel that we gave it our best shot? And I think that that's more important to him than even sort of coming up with the right business answer every time.

Lenny RachitskyWhat about when you're interviewing? Are you encouraging engineers to use AI tools as they're doing exercises? How did that change over the past year or two?

Dhanji R. PrasannaYeah, we're starting to do that now. So traditionally we would just use CoderPad or something like that to wipe boards or a problem or even program it in Pseudocode or near Pseudocode. But now we're looking at can you use Vibe code to build something? How comfortable are you with these tools or how are you thinking about evolving with them as well?

But it's early days yet I would say that it's not clear to me that necessarily how someone knows how to use, be it Goose or Cursor or any of these other tools matters that much to whether they're a good engineer. I still think that things that we interviewed for in the past, a critical mindset, the ability to really understand deeply the technical nature of a problem is still much more important than whether you're a fully AI native programmer or not.

Lenny RachitskyAnother question that I've always been thinking about a lot of people wonder is what level of engineer is most benefiting from these tools? You could argue it's the junior engineers now, they could just get all this work done. You could argue it's senior engineers because they know so much more about how things work and now they could just orchestrate thousands of agents doing their bidding. What have you seen in terms of which level is benefiting most?

Dhanji R. PrasannaYeah, so two answers to that. One is you're definitely right that the more senior and the more junior they are, the more comfortable or the more eager they are to adopt these AI tools. And I think that's for a variety of reasons, including some of them that you named. I think the senior people really understand in great depth how everything works.

And so they're almost relieved that this tool exists that can go and do all these things that they've done a million times before and couldn't be bothered. And then the junior people are like my niece and nephew on a BlackBerry or something, they're just blitzing through things, not BlackBerry in the early days and iPhones now, they're blitzing through a text message when I'm still seek and destroying through my keyboard, shows you how old I am.
So I think there's that, but I think the non-technical people using AI agents and programming tools to build things is really what's been surprising and really amazing. And I think that speaks to how these roles are going to evolve in the future. The lines are going to be blurred between whether you're in legal or in risk or in engineering and design even. And so I think that the people that are able to embrace it to optimize for their particular work day and their particular set of tasks are really who are showing the most impact from these tools.

Lenny RachitskyIt's interesting. No one talks about that element of engineering productivity, which is the reduction of asks from all the other parts of the company to build random one-off things. That feels like a huge productivity gain for engineers.

Dhanji R. PrasannaIt is massive, although I think that it's a little bit like the analogy of if you build a bigger highway, you'll just get more cars on the road. So I think the fact that everyone's building software means that there's more software to be built, more coordination to happen, and everyone's more eager to ship things faster and with greater results. And so we're just seeing an overall uptake in velocity and the ask for more features, if that makes sense. Yeah.

Lenny RachitskyAbsolutely. And it connects to your point about you're not slowing hiring. What I'm hearing is just headcount, hiring desires for more engineers, more product people is not slowing at all. You're basically, it's as if AI wasn't really there.

Dhanji R. PrasannaWe're being more thoughtful about it. So like I said, we were looking at as a commodity in the GM era, and now that we're functional, it's much less about how many engineers we need as a function of the number of features we have in Square or Cash App and in the functional org structure, we think of it much more as what are the areas of optimization? Where can we build depth and what really accelerates our priorities through things like modularization reuse and going deep into platforms.

Lenny RachitskyI love this hot take of if you're trying to be more productive, forget AI, just re-org into a functional structure.

Dhanji R. PrasannaIt's not wrong in some ways. So here's another really interesting example where we are trying to improve our build times and you were using Goose and a lot of other tools to help us with this too, and they've done remarkable things. So we have this really cool tool that analyzes our test suites and selects the right test to run for changes that were made.

So we cut down basically 50% of test runs this way, which is pretty great, and we're not warming the planet as much with all these unnecessary CPU cycles being wasted on tests. But then things like offloading tests to the cloud or simply just deleting tests that don't make sense anymore, probably save you two to three times that.
So there is still a portfolio approach that you need to take for lack of a better term. It's like that example I told you earlier about should we buy a vendor tool? Should we build this in-house? It's like, "Well, do we even need to do this process at all?" So in some ways, structure matters more than the efficacy of the tools you have.

Lenny RachitskyWise words makes me think about Elon has this whole process for optimize stuff and one of the steps is like, "Do we even need this thing before we start out optimizing and automating it?" Before I zoom out and ask about just general lessons that you've learned over the course of your career, is there anything else that you think might be really valuable or useful to folks that are trying to lean in further into AI or just help their teams think a little bit more forward thinking?

Dhanji R. PrasannaI would say really try and use these tools yourself. So the way in which I think we've been able to drive most of the adoption is Jack uses Goose, I use Goose, our executive team all have used Goose and use it regularly and use other AI programming tools and assistance as well, and we do it every single day.

And so we learn a lot about how our own workflow can change, and that's going to tell you so much more about how are you going to change your organization's workflow than if you're reading a bunch of think pieces on LinkedIn or Harvard Business Review or whatever it is, and then trying to get your teams to follow suit. So I think we do this with everything. It's feel it, use the product yourself, feel it, understand its strengths and weaknesses and its ergonomics, and then figure out how to apply it to your teams.

Lenny RachitskySomething I've found helpful in doing that, which I completely agree with, which is stop reading about it, stop listening to us talking about it, just build some stuff. The thing that I found really helpful there is have a specific task or problem you want to solve for yourself because that really motivates you and makes it very real.

For example, just the other day, I was trying to pull images out of a Google Doc. Google Doc, it's like I think of it as Hotel California. You put images in there, but there's no way to get them back out unless you do some crazy stuff. So I just went to Lovable and like Bill an app, or I can give you a Google Doc URL and let me download the images real easily and bam. Perfect.

Dhanji R. PrasannaYeah, great example. I did something like this a couple months ago as well, where my son has a whole bunch of therapies, he has additional needs, and so I was trying to gather the receipts for all these therapies and share them with my wife and she will claim it from our insurer, and I was really struggling to do this because they're in various forms.

There are screenshots in some cases or PDFs or whatever. So I asked Goose to do this and it was all sitting on my laptop and Goose figured out that it could put all of these receipts into my Apple Notes app into a single note. It converted it to HTML so it would sync seamlessly to my phone and then I could email it or share it with her from there.
And that's just something I just never would've thought of. And it did this using Apple Script, so it just controlled my computer for me in the background. Yeah, so these are surprising ways in which these tools help us, and the more you use them to solve real problems to your point, the more you understand what their strengths are and where you can deploy them.

Lenny RachitskyI love this example. So did you just go to Goose and be like, "Here's the problem I have, how would you solve it?"

Dhanji R. PrasannaYeah, pretty much. I said, "I have all these receipts there in Google Drive, so we have similar origin problem there and I need to get them into a single form and I need to collate the totals and do all this." So it tried a few approaches first. It tried to download them and it tried to read them using a PDF reader and this and that. And then the thing about Goose that I think a lot of the other AI agents learn from us as well is if it tries a few things and fails, it'll back up and it'll try a different route and it'll just keep going until it makes some progress.

And that's what it did. Then it picked Apple Script as a way to do it because it had the MCP extension to control my computer, and this is the same thing that our engineer, we were talking about the other day uses to watch his screen and things like that, but this was a very focused problem and it managed to do that. So yeah, it's surprising what these tools can do and allowing them the flexibility to do that is a big part of learning how to use them.

Lenny RachitskyThat's cool. I love the, by the way, can you run Goose as a regular person? Can you just download Goose and use that instead of Claude?

Dhanji R. PrasannaYeah, absolutely. Yeah. You can just download it from our URL. We can share it in the show notes for you and yeah, you can install it. It comes for Mac and Windows and Linux I believe. It's an electron app, so it'll work on all of them. It also has a command line, so for people who are more comfortable using that, we have that UI as well.

Lenny RachitskyWow, you really are competing with these massive foundational model companies building. What's the simplest way to compare Goose to something else? Is it like this Claude code, this simplest comparison or something else?

Dhanji R. PrasannaI think it's a bit different than Claude Code because at its core, Goose is a platform that implements MCPs. So MCPs give it this dynamically extensible nature so it can do all of these things for you, whether it's automating things like we were talking about with Google Docs and notes and things like that, or it can do straight up programming tasks for you using other MCPs.

It can index code and do it that way. So it's really more of an extensible platform. So I would say it sits somewhere between your classic AI assistant where you just ask it, "What's the weather today? Can you calculate how many months it's been since this date?" Or whatever it is, to the more focused cursors and Claude codes of the world.

Lenny RachitskyBasically, it's everything combined wholly and free. You pay for the LM tokens, but yeah.

Dhanji R. PrasannaYeah, there's not like an open source models which-

Lenny RachitskyOh my God, this is crazy. What a cool team to be on building Goose at Block. Must having must be having so much fun. Oh man. Okay. Let me zoom out a little bit. So you've been CTO in LinkedIn right now for just about two years. What's something that you wish you knew before you stepped in this role? If you could go back a couple years and just whisper a few tips and tricks or lessons into your ear, what would they be?

Dhanji R. PrasannaI think maybe two different things. One is just the power of Conway's Law, like we talked about before. It's like how difficult it is to change outcomes without changing the structure of relationships between people in an organization. And I think I always kind of knew that at some level, but really appreciating it in a visceral way is big. The other thing that I really learned the hard way maybe is you only hear about it when things are going wrong.

So when things are going well, you kind of have this eerie silence and you're like, "Well, am I doing the right things here? Am I focusing on the right problems?" So having a bit of judgment, having a bit of time to step back and look at things holistically, those are things that you really need to make time for and do on a regular basis, which I wish I had known when I took up the role.

Lenny RachitskyLooking back at your time at Block, I keep trying to, I almost say Square because I'm so used to that over the air, but I know Block is the name of the broader company and Square is just one. Just so people understand, Square is one business unit, one product within Block.

Dhanji R. PrasannaCorrect, yeah, we have Square, Afterpay, Cash App and TIDAL are four major brands, and then we also have Bitkey and Proto that are focused on Bitcoin for us and we chip hardware in those two brands.

Lenny RachitskyOkay, great. I think that some people are like, what are you guys talking about? Okay, cool. So reflecting back on your time at Block, what's maybe the most counterintuitive lesson you've learned about building products or building teams that goes against what most people believe, say common startup wisdom?

Dhanji R. PrasannaI think code quality is one. Being an engineer. I learned this very early on and it keeps coming true over and over and over again. A lot of engineers think that code quality is important to building a successful product. The two have nothing to do with each other, but my favorite example is YouTube. I was working at Google around the time YouTube was acquired and I just remember there was this whole wash of angst about how horrible the YouTube code base is and how terrible their architecture is, and they're storing videos as blobs in MySQL and whatnot.

And you could argue that YouTube is the most successful product at Google by a long way, maybe more successful than many of their others combined. And so it really has very little to do with how well it was architected because the flip side of that Google video, which is product that I don't know if people remember, it existed before YouTube. It supported more formats, it supported higher resolution.
You could upload hour long videos, YouTube had none of this. It just had the one or two minute quick video thing and it's far and away, blown away its competition. And so I think just keeping that front and center is why are we building these tools or these apps or these products? They're for people to solve a specific problem. So in our case, it's for a square merchant to make a sale, to sell coffee to you or to sell something they've made. And that's really what's important.
It's not really important how well our Android platform performs unless it's serving that need. And so I think that's been a really hard one for me over my career. And I continually encounter engineers who think we need to refactor, we need to do this in a better way. And then I'm like, "No, all this code could be thrown away tomorrow. So just focus on what we're trying to build and whom we're trying to build for."

Lenny RachitskyThat is an incredible insight and lesson. This YouTube story is so fun and such a good example. You're saying they were storing the video content in a MySQL set like row and column as a blob data.

Dhanji R. PrasannaYeah, this is what, I didn't actually look the code so I couldn't verify it, but this was the common wisdom. And then they had an entirely Python stack that was incredibly slow compared to the state-of-the-art C++ and Java servers that we had hyper-optimized at Google back in those days.

Lenny RachitskyThat is hilarious. It makes me think about also companies when you look inside a company, if you work at a company, you're just like, "This is just pure chaos. No one knows what's going on. This is just about to all fall apart." And that's basically what it's like at every successful hyper-growth company.

Dhanji R. PrasannaYeah, there's some truth to that for sure. Yeah.

Lenny RachitskyAnd so I think again, it's just there's so much more that is more important to the success of a business. And it's what you said is are you solving a real problem for people? Can you get in their hands? Can you continue solving real problems for them? It's not about the quality of the code, it's not how well you operate internally.

Dhanji R. PrasannaAbsolutely. I think on Cash App we had that as well. So in the early days of Cash App, I was head of engineering from when we were about 10 engineers to 200 plus and took us to about 10 plus or 20 million users thereabouts. And there was a very similar thing there. From the outside it looked like everything was really chaotic. It's like people would build random experiments and ship them and it just didn't look like we were following strict policies on things like software life cycle and stuff like that, and it was kind of true.

And my philosophy was always, we have all these brilliant engineers and I'm going to do more harm than good by trying to harness them into very strict blinkered areas. If they want to spin their wheels building something that is a complete waste of time for a little bit. But at the same time, if they're delivering these amazing things on the flip side, then I'll almost allow that. I'll be okay with that.
And it's a fine balance because engineers can really go off and into rabbit holes if you let them. But yeah, there's a certain amount of creativity that chaos breeds and you have to know how to build controlled chaos in some ways. So you have to create a foundation that isn't liable to rupture. You have major liability problems or something like that, or you're going to lose money in our case. And so as long as those things are bedded down and you allow your engineers to have the freedom to experiment and iterate and do the things that energizes them, that's the ideal.

Lenny RachitskySpeaking of controlled chaos, one of your titles during your time at Block, I guess this was while you were actually at Square, was Mad Scientist for four and a half years.

Dhanji R. PrasannaYeah, that was a time when I was working part-time, mostly because I had very young kids with lots of additional needs and I was a consultant on various different projects and I was trying to help some wacky things get off the ground. And yeah, I'm really grateful to Block that they afforded me the freedom to have that role in my career as well.

Lenny RachitskyMaybe one more question before I take us to Fail Corner, which I'll explain. So you've shared a few lessons of things you've learned over the course of your career. Are there any other, just let's say core leadership lessons that you've learned that you think have been important to you being successful at the work that you've done?

Dhanji R. PrasannaI think start small with everything. If you try to boil the ocean to make a cup of tea, I don't know who said that, but it's a really a useful phrase that I keep coming back to. You'll never get there. So if you're making a cup of tea, just make the cup of tea. You don't need to boil all the water that there is.

Lenny RachitskyThat sounds like really not delicious tea. Ocean water.

Dhanji R. PrasannaYeah, I think there's another one of, I think Carl Sagan said, "If you want to make an apple pie from scratch, you have to first invent the universe." So it's like narrow your scope to the thing that's in front of you and that's achievable. And so that I think is really important and that's one of our core tenets and always has been even when we were just Square in the early days, start small.

Lenny RachitskyIs there an example that maybe worked really well or maybe didn't work?

Dhanji R. PrasannaYeah, Goose started small. It was just an engineer working on their own time trying to build something that was useful and that satisfied a thesis that they had. So Brad, our creator of Goose, believed very early on, I think long before we heard the buzzword going around that agents would be how we unlock value from LLMs. And he built a proof concept and he shared it with a bunch of people. He shared it with Databricks and Anthropic, got them excited and learned a lot from them.

And so it just sort of built momentum from there. And even internally, it was quite a similar thing. Cash App itself was like that and Cash App started more or less as a hack week sort of idea and grew into a bigger and bigger and bigger thing. So a lot of our projects start with these small experiments that we try to then build on top of. We became the very first company that was a public company to launch a Bitcoin product. And that was again a hack week idea that actually Jack and me and another engineer worked on.

Lenny RachitskyThat was the hackathon team? You and Jack Dorsey and an engineer?

Dhanji R. PrasannaYeah, it was the three of us.

Lenny RachitskyUnreal.

Dhanji R. PrasannaYeah, and it was great. We went and bought a cup of coffee, a blue bottle, and it was bought using Bitcoin over cash card. And I'll tell you those in hindsight, probably the most expensive cup of coffee.

Lenny RachitskyWhat was Bitcoin at? 20,000?

Dhanji R. PrasannaI think it was 6,000 or 7,000 back then. I don't know.

Lenny RachitskyIt's like 120,000 now. Great.

Dhanji R. PrasannaBut yeah, it's an example of how you get to a working useful product to people if you focus on a small thing first in a build.

Lenny RachitskyAnd just to double down on this counter too. "Okay, we have a big idea, we're just going to put a bunch of resources on it and go big immediately."

Dhanji R. PrasannaYeah, absolutely. And I've been part of teams like that too. So in my career, I worked at Google on this product called Google Wave, which was trying to be everything to everyone and we were 70, 80 engineers building this thing before it even really had any users outside Google. And so I think that's an example of something that started big, tried to go big on day one and probably lacked some of that meeting the earth where reality lies and adapting accordingly.

Lenny RachitskyI remember Google Wave. Absolutely. It was beautiful. A lot of hype. I don't remember what it was for specifically, but it looked really nice.

Dhanji R. PrasannaYeah, a lot of learnings from that one for me. Yeah.

Lenny RachitskyWhat else? Any other big lessons?

Dhanji R. PrasannaThose two are the big ones, but I would also say question base assumptions on everything. Sometimes we get into traps where we are as professionals, hyper focused on what we're building that day, that week, that month. And we don't stop to think should we even build this at all? Or what's the purpose of building this?

Could we build something completely different that would matter more to our core reason for being? So I would say, yeah, question the sort of base assumptions. It's somewhat of a cliche, but you really need to remind yourself to apply it over and over and over again.

Lenny RachitskyI had a colleague of yours on the podcast back in the day, IO, who worked with you on Cash App.

Dhanji R. PrasannaYeah.

Lenny RachitskyHe's a friend of mine, he's amazing. He had a quote along those lines of just like, I forget exactly what it was, but it was just get to the bare metal of the thing that you're working on, just touch the thing that you're building and go to the base of it to really understand what's going on. And I imagine that was really important with Building Cash App and Cash Card.

Dhanji R. PrasannaYeah, IO is one of the best product people I've ever worked with and one of my closest friends actually. So absolutely with him, and you on that one, yeah.

Lenny RachitskyOkay. I'm going to take us to a recurring segment on the podcast I call Fail Corner. You already shared one example of a product that failed that you worked on. I'm curious if there's another, and the question is just what's the product you worked on that did not work out? Because people listening to this hear all these amazing successful people come on the podcast, share all these stories of success, endless success, but they don't hear the stories when things don't work out. And so this question is just, "What's a product you worked on that didn't work out and what did that teach you?"

Dhanji R. PrasannaIt's a very valuable point. My career has basically been a string of failed product on top of failed product. And I think that, "Yeah, the Google wave example's there." I worked for Hot Minute on Google+, which was another epic failure.

Lenny RachitskyGood one.

Dhanji R. PrasannaI worked at this social networking startup called Secret, which burned hot for a bright minute and then blew up. And then there was an email startup that we did, and that was, again, very promising, and then that fizzled. So the co-founder of Canva and I worked on that one. So there's been a whole string of failures, but at each point, I think I learned something and I learned that I need to never make that class of failures or errors again.

And so Cash App was probably the big success for me that a product that I worked on that was very early on and grew to be this giant business and product that people love. So yeah, been my career is essentially taking the learnings from all these failures, getting some humility out of it in the process too, coming into things, willing to listen to other people's points of view, critical points of view, and not just thinking that I have all the answers, yeah.

Lenny RachitskyAnd I bet all these products that failed had really beautiful code. A lot of really good architecture decisions were made. Some of them, some of them were awful in every way. So many reasons for it to fail. Incredible. Dhanji, is there anything else that you wanted to share or I don't know, double down on before we get to our very exciting lightning round?

Dhanji R. PrasannaI would say I think that we're in this era of a lot of change and people are scared or reticent or uncertain about where things are going. And I think that look at the things that matter to you. For us, it's open source, open protocols, improving access for everyone. I've been very lucky in my career to only work on products that are either free or almost free to anyone or they have a free tier and then you pay for some premium services and that are usable by everyone. So anyone can become a Square seller.

I remember even in the early days, people used it to pay each other as a peer-to-peer money transfer system and that's why we built Cash App and that was really successful on the back of that. So I think it's really look at the things that are important to you and optimize for them. It's not really that important that the technology trends are growing in a certain way because technology is here to serve us, and if we have an important reason for being and an important purpose, then we can make that technology serve us. And that's much more important than being deep with the technology or being at the forefront of every trend.

Lenny RachitskySuch great advice when there's so much to pay attention to and so much happening. So stressful to feel like I'm just not aware of all the things. I'm not as good as all these people I'm seeing on social media, but what's happening with AI, I'm just so behind. What I'm hearing from you is just like what is actually important to you? And just do that. Don't feel like you need to be the best at everything that's happening on top of all the latest AI news.

Dhanji R. PrasannaYeah, exactly. And if it's not meaningful and fun, then you shouldn't be doing it probably.

Lenny RachitskyWith that Dhanji, we've reached our very exciting lightning round. I've got five questions for you. Are you ready?

Dhanji R. PrasannaOkay. Shoot.

Lenny RachitskyI see so many books behind you. So I love this first question. I'm excited to see what you pick. What are two or three books that you find yourself recommending most to other people?

Dhanji R. PrasannaYeah, so I very much of the opinion that you shouldn't read books that are about your daily work or your professional life. I read fiction, I read the classics, I read poetry, philosophy, history. These are the books I really enjoy. And I think it expands your mind and gives you creative ideas and helps you question things about the human condition.

And that's much more valuable than some self-help book or some get good at being an engineering manager book. So yeah, having said that, the Master in Margarita by Mikhail Bulgakov is one that I really love. It's a masterpiece of Russian literature. And then I've always been drawn to Tennyson's poetry and I find that in the times when I'm most uncertain or grieving, Tennyson's poetry has always resonated with me and helped me find a center.

Lenny RachitskyWow. Never heard these recommendations before. I'm really excited to check these out. Very cool for a CTO of a big tech company. What is a favorite recent movie or TV show you've really enjoyed?

Dhanji R. PrasannaAlien Earth I think is pretty awesome. It's by Noah Hawley who did the Fargo TV series. And so it's someone with all of these incredible skills in high art filmmaking who's doing a pulp sci-fi show, and it just looks stunning and it feels stunning and it captures all of that essential alien pulpiness that makes it so interesting and fun. So I really like that, and I'm also watching Slow Horses, which I think is one of the better shows on TV.

Lenny RachitskyLove Slow Horses. The new season's Out, think the fifth episode just dropped the day we're recording this. So I love that show. Alien Earth also just watched it, so creepy and just like all these slimy, gooey little creatures just crawling around.

Dhanji R. PrasannaYeah, I just love the aesthetic and they captured something essential about the original Alien and yeah, they do it, but every scene in Alien Earth feels like you're watching a painting or something or someone's reading a novel to you. It's really unfolds very thoughtfully.

Lenny RachitskyI've never watched any alien content in my life and I really enjoyed Alien Earth. I will say the ending, I was just like, it felt like it kind of slowed down a bit. I'm just like, "All right, I guess I see where it's going now." But it was really fun to watch. Okay, next question. Do you have a favorite product you really enjoyed? Sorry, a favorite product you've recently discovered that you really enjoy? It could be an app, could be an gadget, could be some kitchen thing.

Dhanji R. PrasannaWell, I'm a gamer. I love playing games. So for me it's the Steam Deck, the Steam Deck OLED, which is their latest version. It's like this gorgeous piece of hardware that lets you play the best games out there, but it's totally extensible and customizable. And in this era where we're constantly told by big tech companies that we need to lock everything down, we need to lock down the user experience and customizability in order to have things work for people.

I think Valve showed that's totally unnecessary and totally wrong, and you can build the Steam Deck. You can install competing app stores, you can install Windows on it. You can treat it like a computer, write programs, which I have done to run on it. So yeah, I think it's an incredible thing and it looks beautiful and it works great. So yeah, big fan.

Lenny RachitskyDo you have a favorite life motto that you find yourself coming back to often in work or in life?

Dhanji R. PrasannaIf you're not waking up in the morning feeling energized about what you're going to do that day in your professional life, then change something, quit if that's what it comes down to, or find a new way of doing what you're doing. Just don't accept what's meted out to you. So that's how I've tried to do things, and sometimes it works, sometimes not, but yeah, it's a good thing to ask yourself.

Lenny RachitskyI really love this advice. It's really hard to do that for a lot of people. Is there anything that has helped you get over that fear of just like, "Oh man, I'm going to quit this thing. I don't know where I'm going to go next."

Dhanji R. PrasannaThe main thing is telling yourself that a year from now, you're going to look back on what looks like a monumental problem, a life-changing thing, and you're going to be like, "Oh, that was so trivial." A lot of times we get into these traps where we're overthinking something or really nervous about making a change, but in hindsight, those don't seem that big.

And all the time that's passed since and all the events that have happened teach you that there's more to the world and it's never too late to do something useful or never too late to do something that's for yourself and improving yourself. So yeah, I think just kind of remembering that things are not as big or bleak or decisive as they seem in the moment is always important.

Lenny RachitskyFinal question. So you were a mad scientist at Square for many years. Do you have another favorite mad scientist from pop culture or real life?

Dhanji R. PrasannaThat's an interesting one. I think the image that always comes to my mind is Doc Brown from Back to the Future. I feel like he's the canonical mad scientist of my generation anyway, but there've been a lot in video games and stuff too, but he was the one that was like, "I'm just going to do this crazy thing because I almost have this burning desire, need to do it, and whether I want to or not, I must build this time machine." And he spends the entire movie trying to fix the problems that it creates. But yeah, he has always been a really fun character for me.

Lenny RachitskyYou know what? I think about Pinky from Pinky in the Brain.

Dhanji R. PrasannaOh yeah, that's a good one too. Yeah.

Lenny RachitskyOh man. Dhanji, this was awesome. You were wonderful. Thank you so much for being here. Two final questions before we actually wrap up. Where can folks find you online if they want to reach out, learn more about say Goose or anything else going on at Block? And how can listeners be useful to you?

Dhanji R. PrasannaCheck out our GitHub pages for Goose and all of the other open source projects we have at Block. So there's a lot that's useful there. We do a lot on Android open source as well, so check that stuff out. You can always find me on LinkedIn, so feel free to connect. I'm very happy to be contacted.

And I would say the way people can be useful is, again, going back to this era we're in of a lot of change and uncertainty, I think people that demand more of their companies, of their employers, of their teams, demand something better. At Block, we always ask, "Can we default to making this open source? Can we build this for people that are not just us or our customers? Can everyone benefit?"
And I think that's particularly important in this era of AI where everyone's locking themselves in walled gardens and trying to capture parts of the platform that are emerging. So yeah, just demand more of people. The internet was created as a promise for open sharing of information to the benefit of all, and I think that AI should realize that for us. And so yeah, just demand that of people.

Lenny RachitskyA really beautiful way to end it. Dhanji, thank you so much for being here.

Dhanji R. PrasannaThank you, Lenny. I really appreciated it. Thank you.

Lenny RachitskyI appreciate you.

Dhanji R. PrasannaCheers.

Lenny RachitskyBye everyone. Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennyspodcast.com. See you in the next episode.

章节 02 / 09

第02节

中文 译稿已完成

Lenny Rachitsky现在围绕 AI 带来的生产力提升,有两派声音特别明显。 一派觉得这事被严重低估了,很多东西已经开始起作用,而且会越来越夸张;另一派则觉得完全被吹过头了,大家都在讲,但真正大规模落地的并不多。

Dhanji R. Prasanna我们确实看到了非常明显的成果。

那些对 AI 特别积极、真正把它用进日常工作的工程团队,通常会反馈每周大约能省下 8 到 10 个小时。
而且每次听到这种数字时,我都会提醒大家一件事:这已经是它最差的时候了。现在只是基线。真正的价值每天都在变,所以你得一路跟着那条浪一起往前走。

Lenny Rachitsky我之前在另一档播客里听你讲过一个特别夸张的故事,说有个工程师会让 Goose 盯着自己工作。

Dhanji R. Prasanna对。比如你正在 Slack 或邮件里和同事讨论一个“也许值得做”的功能。几个小时之后,你就会发现 Goose 已经试着把那个功能做出来了,甚至还在 Git 上开好了一个 PR。

Lenny Rachitsky那到底哪一层级的工程师,从这些工具里获益最大?

Dhanji R. Prasanna最让人意外、也最让人兴奋的,其实不是工程师,而是那些非技术岗位的人。他们开始用 AI agent 和编程工具自己搭东西。

谁最容易从这些工具里拿到最大价值?往往是那些愿意围绕自己的一天、围绕自己那组具体任务去做优化的人。

Lenny Rachitsky那你觉得再过几年,工程师的工作方式会和今天有什么根本不同?

Dhanji R. Prasanna我最大的感受是:这些 LLM 晚上和周末都在闲着,但人类不在的时候,它们根本没必要闲着。它们应该一直在工作,应该提前去构建那些我们接下来可能会想要的东西。

Lenny Rachitsky那从“做产品”和“带团队”这两个维度看,你学到的最反直觉的一条经验是什么?

Dhanji R. Prasanna很多工程师会觉得,代码质量和成功产品之间高度相关。但在我看来,这两件事根本不是一回事。

Lenny Rachitsky今天的嘉宾是 Dhanji Prasanna。

Dhanji 是 Block 的 CTO,管理着超过 3500 人的团队。在他的带领下,Block 已经成了当下最 AI-native 的大型公司之一,某种程度上,他们已经做到了很多工程和产品负责人都在各自公司里努力想做到的事。
这次对谈里,我们会聊到他们内部开源的 agent `Goose`。按他们自己的测量,它平均每周能帮员工省下 8 到 10 个小时,而且这个数字还在继续上升。
我们也会聊 AI 到底是怎样让他们的团队更高效,以及究竟哪些团队吃到的红利最大。有意思的是,答案并不是工程团队。
另外,我们还会聊,为了让整个公司真正转向 AI-first,他们在文化和组织上做了什么;以及一项特别“无聊”的内部调整,它带来的生产力提升甚至超过了很多 AI 工具本身。
此外还会聊到他做 Google Wave、Google Plus、Cash App 时的一些经验,等等。
如果你想看一家真正高度 AI-forward、技术驱动的大公司会长成什么样、怎么运作,这期会很值得听。
如果你喜欢这档播客,别忘了在你常用的播客应用或 YouTube 上订阅,它帮助很大。
后面的 Product Pass 和赞助口播我就压缩略过。
Dhanji,非常感谢你来,欢迎来到播客。

Dhanji R. Prasanna谢谢你,Lenny,很高兴来到这里。

Lenny Rachitsky我想先从一封信开始。我听说你当时给 Jack Dorsey 写过一封信,说服他以及整个 Block 必须更严肃地对待 AI。

我记得你把它叫作自己的 `AI manifesto`,而且看起来它真的起了作用。我们后面会聊很多因为那封信而发生的变化。
所以先从最直接的问题开始:你当时到底写了什么?那封信发出去之后,接下来又发生了什么?

Dhanji R. Prasanna大概两年半前,Jack 就已经很清楚地感觉到,很多东西必须要变了。他对整个行业正在转向哪里,其实已经有了某种判断。

所以他每周都会把公司大约 40 位最高层的管理者拉进一个房间,大家一起把当下所有重要的事过一遍。后来他把我也加进了那个小圈子。
在那个过程中,我慢慢发现:我们讨论了很多深层的、也很相关的问题,但几乎没有人真正把 AI 当成重点。
所以我就写了那封信。
说实话,这封信后来有点被神化了,但它本身其实没那么复杂。大意就是:我觉得我们应该认真做这件事,而且要集中做;我们得跑在前面,成为一家真正 AI-native 的公司,因为整个行业就是在往这个方向走。

Lenny Rachitsky这里得帮大家补一个背景:你当时还不是 CTO,对吧?更像是一个资深工程负责人。

Dhanji R. Prasanna对,事实上我那时还是 part-time,因为我刚有了孩子,正在慢慢回到工作状态,主要是帮一个工程团队处理一些事。

后来 Jack 来到悉尼,和我待了两天。我们就一直边散步边聊,在悉尼城里上上下下走了很多路,把这些想法彻底聊透。再后来,他就把这个职位给了我。我觉得这是个一生可能就一次的机会,所以我接了。

Lenny Rachitsky这有点像“你最好小心自己擅长什么”的故事了。

那等 Jack 也认同了、Block 高层也认同了“我们必须更大力度地做 AI、必须更深地思考 AI 会如何改变我们如何构建”的方向之后,你具体做了哪些大动作?
如果从“其他公司现在也在想该怎么做”这个角度看,你最先推进的那些改变是什么?

Dhanji R. Prasanna一开始,我最核心的目标,是让 Block 重新像一家 technology company 那样思考。

因为很长一段时间里,我们有点出现了 identity drift,也就是身份感漂移。我们总在说自己是 financial services company,有些人叫我们 FinTech,类似这样的表述很多。
但我最早加入那家当时还叫 Square 的公司时,我们对自己的理解,一直都是 technology company,和 Google、Facebook 这些公司是同类。
所以我想把这种状态拉回来。
我做的第一件事,就是推一系列围绕“技术优先”展开的项目。包括把公司里最顶尖的一批 IC 拉到一起交流,也包括启动一批 special project。每个项目大概配 2 到 5 个工程师,总共做了八九个项目。与此同时,我们还重新启动了公司级 hack week。
这些动作叠在一起,慢慢点燃了一点火花:大家开始重新感觉到,“我们又在认真造技术了,我们又在试着去推前沿了。”
事情就是这样开始的。
然后后面才有了更多步骤,比如我们把公司从原来的 GM structure,改成了 functional org structure。我认为,这是让 Block 真正转向更 AI-native 公司的关键一步。

English No English text found
No English transcript text was found for this chapter.
章节 03 / 09

第03节

中文 译稿已完成

Lenny Rachitsky如果给那些正在挣扎、或者还在想怎么做这件事的公司一个简化版结论,我现在听出来的是两点。

第一,你得先把自己看成一家 technology company。当然这不一定适用于每家公司,但这里一个很重要的前提是:我们是在构建技术,而不是一家金融公司、地产公司,或者别的什么行业公司。
第二,团队组织方式也得跟着变。比如工程师应该汇报给真正懂工程、也真正重视工程的 engineering leader,而不是某个可能并不真正理解工程的 GM。

Dhanji R. Prasanna对,差不多就是这样。

而且我不想过度类比,但 Jobs 回到 Apple 时,其实也做了类似的事。他把 Apple 重新改成 functional organization。
我们当时并不是照着哪套现成 playbook 来做,而是在摸索过程中逐步发现:如果真想让团队更 tech-focused,想把我们的 DNA 拉回自己的根上,就必须这么做。
而对我来说,那个根说到底就是 engineering first、design first,这也是我理解的“technology first”。
所以如果给别的公司一句建议,那就是:先找到你的 DNA,然后用一种尽量简单、清晰的方式,围绕它来优化组织。

Lenny Rachitsky好,所以你写了 manifesto,推动了一堆变化,把公司改成 functional,也强调 technology first。

如果把今天的工程团队和两三年前相比,最根本的不同是什么?

Dhanji R. Prasanna先说一句,不是所有人一开始都买账。这其实是一次挺痛苦的转型。

整个过程中,我学到最深的一件事之一,就是 `Conway's Law` 真的非常强大。它的意思大致是:你最后交付出来的东西,往往就是你组织结构的映射。也就是说,你怎么组织团队、怎么协作、怎么运作,会深刻决定你最终造出什么。
所以我觉得最核心的变化,就是以前每个 silo 都有自己的惯性。Cash App 有 Cash App 的惯性,Afterpay、Square,甚至 TIDAL 这个流媒体业务,也都各有各的节奏。
彼此之间几乎不怎么交流,也没有在技术战略上真正对齐,更别说对“五年后整个团队到底想成为什么”有共同理解了。
现在这些东西至少都变了。
我不是说已经完美了,我们前面还有很长的路,但至少现在大家说的是同一种语言。
我们都能用同一套工具,共享同一套 policy。某个 senior engineer 的定义,在整个公司里是统一的。人也可以在不同团队之间流动,去支援真正需要的地方。
这些都和以前非常不一样。
如果让我用一句话总结,就是:现在我们是真的把“技术聚焦”和“技术卓越”当成明确目标在推进。
而这件事,放在两三年前并不成立。那时候我们优化的是别的东西。

Lenny Rachitsky如果再往下钻一层,回到“人每天到底怎么工作”这个层面。

比如你去看一个普通工程团队,或者一个状态最好的工程团队,他们今天的工作方式和两三年前相比,最明显的差异是什么?

Dhanji R. Prasanna如果说的是那些非常 AI-native、或者几乎到处都在 AI-first 构建的团队,那他们的工作方式和以前已经完全不一样了。

因为他们现在在用 vibe coding 工具,很多时候几乎已经不是靠手打一行行代码来构建,而是用另一种方式在“写软件”。
而这件事,三年前在世界上几乎任何地方都还不存在。
当然,如果你面对的是很重的 legacy codebase,这种变化就没那么彻底。
但即便如此,他们现在也会遇到很多“后台 AI 流程”。比如我们有一些工具会 24/7 跑着,或者直接跑在 CI pipeline 里,帮你分析漏洞、看 ticket 里的 bug,甚至在人睡觉时尝试自动打 patch。工程师第二天来上班,再去看它晚上做了什么。
所以我会说,变化是多层次的,只是不同团队离这些工具有多近,决定了他们改变得有多深。

Lenny Rachitsky那我们就顺着 AI 这条线往下聊,我觉得这正是你们相对很多公司最领先的地方。

你们还自己造了一个 agent,也就是 Goose。现在关于 AI 生产力提升的讨论里,也有两派声音:一派说 AI 会把效率放大到极致,我们都要 10 倍提速;另一派则说,全是 hype,试点项目都在失败,根本没人真正大规模用起来。
我猜你更偏第一派。那你们自己在团队里,实际看到了什么级别的收益?

Dhanji R. Prasanna我们现在的头号优先级之一,叫 `automate Block`,意思就是要把 AI 以及基于 AI 的自动化真正铺进整家公司。

而且我们觉得,现在还只是这些大语言模型实用价值的开头,后面只会继续变强。
但即便是现在,那些非常 AI-forward、每天都在用 Goose 的工程团队,已经会 self-report 说自己每周大概能省下 8 到 10 个小时。
当然,这个数字本身是 self-reported,所以我们还会配很多校验指标。
比如我们看 PR、看 feature throughput、看很多别的东西,再由 data scientist 搞一套比较复杂的公式,把这些信号压缩成一个尽量有意义的指标。
从全公司的角度看,我们感觉现在大概已经朝着 `20%-25% manual hours saved` 这个量级在走了。
而且我觉得这还只是开始。
我确实觉得,那些更 AI-native 的公司,在拿到这波收益上做得更好。最典型的当然还是那些 AI startup。
但与此同时,也有一点是真的:AI 不是 panacea,它的能力本身也还在不断成长。
所以你必须随着它的能力变化一起调整。很多公司之所以感受不到价值,是因为他们总在问:“价值到底在哪?”可问题是,这个价值每天都在变。
所以你要做的,不是等一个固定答案,而是持续适应:先看今天的价值在哪,再去为明天的价值布局,然后逐步把 AI 扩展到那些当前最有效的场景里。

English No English text found
No English transcript text was found for this chapter.
章节 04 / 09

第04节

中文 译稿已完成

Lenny Rachitsky所以如果简单比喻一下,它有点像一个带 UI 的 Claude Code,底下能接 Claude、OpenAI ChatGPT,还有一堆开源模型,是这个意思吗?

Dhanji R. Prasanna对,它基本可以接任何模型。

我们做的是一个可插拔的 provider system,所以你可以自己带 API key,接 Claude 家族、OpenAI 家族;也可以接开源模型,直接下载本地跑,或者通过 Ollama 之类工具去跑。现在能帮你做到这一点的工具已经有不少了。
本质上,它就是把这些模型“生成文本、理解文本”的能力,真正接到现实世界的工作流里去。
我特别喜欢的一个例子是:你可以让 Goose 帮你生成营销报告。
它可以通过 MCP 去连 Snowflake、Tableau、Looker。然后它会自己写 SQL 拉数、做分析、生成 CSV,也能在你的桌面上写 Python 做数据处理。接着再用它知道的 JavaScript charting library 画图。
最后,它还能把这一整套东西整理进 PDF、Google Doc,甚至直接帮你发邮件或上传到指定位置。
而且整个过程基本是它自己 orchestrate 的。不是你一步一步告诉它怎么做,你只是说:“我想要这份报告,想发到这里,图表要好看一点。”然后它就会自己跨多个系统把事情串起来。

Lenny Rachitsky所以在 Block 里,大家不是直接去用 Claude、ChatGPT,或者 Cursor 这些工具,而是会直接用 Goose?

Dhanji R. Prasanna其实我们允许工程师和普通员工用任何他们想用的工具。

只是 Goose 在我们的系统里整合得最深,因为它建立在 MCP 之上,而 MCP 又让你为已有系统写一个对接层变得非常容易。
比如说,你有个 issue tracking 工具,想给它加上一层 AI 自动化。放在 Goose 之前,你通常只能等那个 vendor 自己把 AI 功能做进去,或者等 OpenAI、Anthropic、Google 提供一个足够通用的能力让你勉强接上。
但有了 Goose,这件事就不需要等了。你只要写很少几行代码,把它包成一个 MCP,这些系统几乎一夜之间就变成了可被 AI 编排的对象。
而且 Goose 连自己的 MCP 都能写,所以它本身也非常具备 bootstrap 能力。

Lenny Rachitsky而且它还是开源的。也就是说,你们花了这么多时间把这套东西做出来,其他公司现在也可以直接拿去用,甚至在你们的成果上继续扩展?

Dhanji R. Prasanna对,而且现在已经有很多公司在非常积极地用 Goose 了。

我不想点太多名字,但从我们的竞争对手,到很近的合作伙伴,很多都在团队里频繁使用 Goose。Databricks 公开提过它,基本上你能想到的这一层中大型技术公司,很多都在某种形式上使用 Goose。

Lenny Rachitsky这太离谱了。感觉它本来完全可以自己长成一家超级大的公司。现在世界上增长最快的很多公司,产品本质上做的就是这类事情,而你们已经做出来并且直接开源了。

Dhanji R. Prasanna我们非常相信 open source 的力量。

而且我们有一个很核心的使命,就是提升 openness。所以我们会主动去贡献开放协议,也会贡献开源项目。
作为一家技术公司,我们本来就是站在大量开源软件之上的。说到底,几乎所有技术公司都一样。不管是 Linux、Java、MySQL,还是别的基础组件,大家都建在这些东西之上。
所以我们一直觉得,自己有一个很强的责任去回馈这套生态。
我们想做的不只是对自己和客户有用的东西,也希望做出那种能活得比 Block 更久、影响范围比 Block 更大的东西。这是我们一直以来的价值观,在 AI 之前就是这样。
所以 Goose 其实只是延续了这个传统。我们也很高兴它现在有这样的扩散效果。

Lenny Rachitsky顺便一定要问一句,`Goose` 这个名字到底怎么来的?

Dhanji R. Prasanna它其实是个《壮志凌云》梗。

起这个名字的那位工程师,长得也和电影里的 Goose 特别像。如果把两个人照片放在一起,真的很离谱。他知道我这么说肯定会很尴尬,但这确实是名字的来源。后来我们就顺着整个“鸟类主题”继续玩下去了。

Lenny Rachitsky太好笑了。我之前还听你在别的播客里讲过另一个故事,说有个工程师把 Goose 玩到了极致,让它盯着自己工作。你展开讲讲。

Dhanji R. Prasanna对,他是一个非常非常 AI-forward 的人,一直在试着从 Goose 身上榨出各种疯狂玩法。

Goose 当然可以像我刚才说的那样,通过工具去执行任务,但它也可以直接观察你的屏幕。它能理解图像,也能通过截图去理解它看到的东西。
于是他就做了一套系统,让 Goose 基本一直盯着他的工作过程。比如他正在 Slack 或邮件里和同事讨论某个可能值得做的功能,
几个小时后,他就会发现 Goose 已经试着把那功能做出来,并且在 Git 上开好了 PR。
还会发生很多类似的怪事。比如如果他某个会议快超时、后面还有别的事情,Goose 会自己想办法 nudging 他离开当前流程。这里面很多行为都不是他预先写好 prompt 的,而是 Goose 自己觉得这样也许能提升他的效率、让他的工作日更顺。
所以,这已经相当疯狂了。
当然,你得有那个心理承受能力,愿意让工具如此深地接进你的工作流。但它确实能让你看到:这种系统到底能走到哪里。

Lenny Rachitsky这显然就是未来会去的方向。

一旦它足够好,整个模式就会变成:它一边看你工作,一边提前猜你接下来要什么,然后直接把第一版做出来。你会突然发现:“哦,我们刚刚开会聊到这事,PR 居然已经在那了。”
太离谱了。

Dhanji R. Prasanna对,就是这个意思。
语音其实也是这里很大的一部分。它具备 voice processing capability,所以也会一直听他说的话,并尝试理解上下文。

不过我会说,目前这更多还像一个实验。毕竟那位工程师本来就在 Goose 核心团队里,他也会给 Goose 贡献代码,所以这更像他在主业之外做的一个 side project。
但一旦这种能力逐步变成 Goose 本身的原生功能,或者进到企业里更多工具里,我觉得它会非常有潜力。
即便放在现在,它也已经足够好,至少已经替他砍掉了大量琐碎工作。
比如一个很典型的场景是:他说一句“我有会议冲突,那时间去不了”,或者“我得去接孩子了”,
然后 Goose 就会自动把那个会议重排掉,根本不需要他自己打开日历点来点去十次。
以前这类功能,我们总觉得得等日历厂商自己把它做进去。但现在已经不用等了,因为 AI 已经能替我们完成这种编排。

Lenny Rachitsky这不是那个同时打四份工、把工作都并行掉的家伙吧?

Dhanji R. Prasanna不是不是。他是我合作很多年的老同事,也在 Block 待了很久。他就是特别喜欢实验,而且身上很能体现我们现在这种 experimentation culture。Goose 的创建者也是这样的人。

Lenny Rachitsky那我们把这个话题再往前拉一点。

你们在 Block 某种程度上已经看到了未来的一角,也确实比很多公司更早一点在那条曲线上。那你觉得再过几年,工程师和产品团队的工作方式会和今天最本质地差在哪?

Dhanji R. Prasanna这很大程度上还是取决于 LLM 本身能力提升得有多快。

但至少我可以说说,我现在正试图怎样改变自己的工作方式,以及我想怎样改变身边核心团队的工作方式。
我觉得 vibe coding 很有意思,也很让人兴奋。你对着聊天机器人说话,它就去帮你写软件。但我觉得这件事本身其实还是太受限了。
现在的交互太像 ping-pong 了。你说一句,它去做;三四分钟后回你一个半成品;然后你再 nudging、再引导、再一点点修,才能把东西推到可用状态。
而我觉得,接下来我们会看到更高程度的 autonomy。
所以我们正在 Goose 的下一代上做一些实验,目标不再是让它一次只工作两三分钟、五分钟。
现在我们的 median session length 大概是 5 分钟,平均差不多 7 分钟;但我们想把这个数字推到“几个小时”。
我们会直接去问:为什么这些 LLM 晚上和周末要闲着?人类不在的时候,它们完全可以继续工作。
它们应该一直在构建,提前去尝试实现那些我们接下来会想要的东西。回到前面那个话题,它们甚至应该能用过去根本做不到的方式去构建。
以前做人类团队时,我们的资源有限、带宽有限,而且协调成本非常高。所以面对一个问题,我们通常只能选最值得赌的一条实验路径去试。
但我觉得现在不一样了。
现在更合理的方式是:你把多种实验方向详细描述出来,然后也许你去睡一觉,第二天起来,这些实验已经都被做出来了。你只需要挑选,甚至直接扔掉其中五六个不好的版本。
我自己现在就经常这样干。我每天都写代码,但最近一个非常不同的习惯是:我会直接扔掉大量、大量的代码。
这对我来说其实挺不习惯的,因为以前我从来不是这样工作。工程师当然一直都喜欢删代码,但这次不一样。现在是你把整套系统、整块功能都做出来了,然后看一眼说:“嗯,感觉还是不对。”然后直接删掉,重新来。
所以我觉得,未来你会看到越来越多这种工作方式。
你会看到人们不再去“慢慢重构一个旧 App,让 UI 变一下、让它进化到下一个版本”,而是直接从头重写。
我现在一直在逼我们团队去想一个问题:如果每次 release 时,我们都能直接 `rm -rf` 整个 app,然后从头把它重建一遍,那我们的世界会是什么样?
当然,今天我们还做不到,但这个问题至少能帮助你看见:这些工具真正要把我们带去哪里。

English No English text found
No English transcript text was found for this chapter.
章节 05 / 09

第05节

中文 译稿已完成

Dhanji R. Prasanna我觉得是的。关键在于,怎么让 AI 真正尊重那些历史上逐步积累出来的小改进,并把它们一并写进新的 specification 里。

Lenny Rachitsky还有你前面讲的那个 agent 场景也很有意思。你给它一堆想法,它一晚上都帮你做出来。那再往前一步,它会不会自己开始往上游走,自己冒出点子、自己开始构建,然后第二天你一看:咦,这个想法居然真不错。

Dhanji R. Prasanna会,确实会。

事实上,我上周就在试你说的这个方向。我手里有个 Goose 的新版本,我们就在让它自己想办法改进自己,然后一晚上实现出来。

Lenny Rachitsky有点“打滑”问题,是吧。

Dhanji R. Prasanna对,有时候它会彻底跑偏,你得再把它拉回来一点。

所以我觉得,我们还没到“完全自我改进、完全自治”的时代。
但我们已经处在一个过渡期:你可以给它一个明确 nudging,比如说,“这是我希望你能做到的 10 件事,你自己找最好的实现路径。”
如果特性描述得足够清楚,它大概能把其中 60% 做成。剩下那 40%,你还是得介入、修、揉、再重新引导。

Lenny Rachitsky天啊。我脑子里已经出现一个功能了:你给它一个目标,比如“给我增长收入、提升增长”,然后它直接说:“好的,所有人都裁掉,工资单我已经发好了,后面交给我。”

Dhanji R. Prasanna我不觉得我们会走到那一步。

我反而觉得,我们会越来越需要大量的人类 taste,去把这些 AI 锚定住,别让它们彻底跑偏。
这也是我们的设计负责人和设计团队一直在推动我们认真思考的方向。我觉得这会是我们跨过当下这波 `AI slop` 时代的关键差异点。
说到底,还是得把它锚定在人真正关心的东西上,锚定在有品位、有用、并且真的有价值的结果上。

Lenny Rachitsky如果说得再具体一点,有没有什么场景是你们必须明确知道:这里一定得由人来接手,把事情拉回正轨?

Dhanji R. Prasanna这种情况更多出现在 process automation 这类事情上。

比如经常会有团队来找我说:“我们得去买一个新 vendor tool,因为当前这个工具在 X、Y、Z 几个方面不行了。”
然后另一边又会有人说:“不用买,我们直接用 Goose 半天就能搭个内部应用,把这事解决掉。”
而作为一个人类,你这时候会坐在那想:等等,这件事真的有必要吗?如果我们只是把流程本身改一下,是不是根本连工具都不用建?
AI 现在最不擅长的,就是这种 portfolio judgment,也就是从更全局的角度判断“什么真的重要、什么根本不值得做”。
所以很多时候,我会让团队先去质疑最底层的假设。
尤其是我们的 InfoSec 团队,有时会把自己拧成一个死结,拼命想把某件东西保护到极致。这时候你可能反而会说:“不如直接让业务团队换个做法,或者干脆别做这个功能。如果这件事本来就不重要,你就不需要再扩大安全面去保护它。”
所以我觉得,这类问题现在还是更适合人类来做判断。AI 在这上面还做得不够好。

Lenny Rachitsky你刚才也提到过一个点:很多时候你们会自己造工具,而不是买现成 SaaS。

AI 时代大家老在讨论,会不会最后把一堆 SaaS 应用都干掉,Salesforce 这些是不是也会被替代。那你们自己会不会感觉到,自己造这类东西到底省了多少钱?还是反过来,你们反而对现成 SaaS 软件多了一层新的尊重?

Dhanji R. Prasanna我觉得这里有个陷阱,就是很容易偏离公司真正的核心目的。

我们的核心目的是 `economic empowerment`,也就是帮助客户、商户、创作者赚到钱、付得起房租,或者把他们最新的作品传到 TIDAL 上。
凡是能服务这个目的的事情,我们都应该鼓励,也应该投入。
但如果你只是停留在“这东西内部做比外面买省多少钱”的账面比较上,那你其实已经被拉离这个核心目的了。
单纯因为觉得“自己造也许能省点 vendor 成本”,就用内部工具去替换外部工具,很多时候根本不值。因为你损失掉的是团队的 mental bandwidth,也是团队本来该放在核心技术上的注意力。
所以我的建议一直都是:反复回到那件最重要的事上。对你们公司来说,真正重要的到底是什么?剩下的事情,围绕这个判断自然会有答案。

Lenny Rachitsky对,我觉得大家常常低估一件事:你自己造出来一个东西之后,真正昂贵的不是“周末把它做出来”,而是接下来几年无穷无尽的维护、请求和支持。

而且就像你说的,最终还是那句老话:聚焦自己的 core competency,别的能买就买。

Dhanji R. Prasanna对,这其实就是经典的 80/20 问题。

而我们在给客户做产品时,也已经反复经历过这种事。你会做出一个非常酷、用户也很喜欢的实验,但后面却得花很长时间去把那一长串尾部 edge case 一点点磨平。
比如 Cash Card,当初我们几乎就是用一个周末、最多再加一周整合工作,把整个核心功能做出来了。
但后来却花了很久去处理各种边角问题。比如有人会给出账单两倍的小费,结果后端某处直接被打穿;或者有人在加油站刷卡,而加油站的 billing 方式和别的商户又完全不同。
所以现实永远是这样。
说到底,我还是会回到同一个问题:我们为什么要做这件事?它对我们和客户到底意味着什么?
如果这个问题回答不清,那我一般就会把它归类成“不值得投入”的事情。
(Persona 赞助口播已压缩略过)

Lenny RachitskyAI 讨论里还有一个永远绕不开的话题,就是招聘和岗位变化。

所以我想把问题拆成两个部分:
第一,这些 AI 工具带来的生产力提升,实际会不会改变你们规划 headcount 和招聘的方式?
第二,在今天这样一个 AI 已经深度进入工作流的环境里,你们招人时会特别看重什么?

Dhanji R. Prasanna我不觉得事情已经发展到那种程度,足以从根本上改变“做一个 Cash App 这个规模的产品到底需要多少人”。

对我们来说,真正改变招聘方式的,其实不是 AI,而是前面聊过的那件事:从 GM structure 转成了 functional structure。
在 GM 结构下,我们天然会把工程 headcount 当成一种 commodity。也就是说,如果想多做一些 feature,那就多加点工程师。
这其实就是典型的 mythical man-month 陷阱。
而转到 functional structure 之后,逻辑完全变了。你会开始想:我们能不能复用共用平台、共用模块?能不能把公司里别的地方的专家拉进来,给我们提供更好的方法?
所以从那之后,我们招人的方式也跟着变了。我们不再把工程师当作那种“多加 100 个人,就能多做 100 个 feature”的资源。
但在 AI 这一边,我们会特别看那些愿不愿意拥抱这些工具、愿不愿意用它们学习的人。
我们并不是非要招“开局就是 AI 高手”的人。那样的人如果愿意加入,我们当然欢迎。但我更在意的是:不管是刚毕业的大学生,还是已经很资深的人,只要他真的愿意去试、愿意去学、愿意和这些工具一起进化,那就是我们更想找的人。
我们优化的,是这种倾向,而不是某组固定技能清单。

English No English text found
No English transcript text was found for this chapter.
章节 06 / 09

第06节

中文 译稿已完成

Lenny Rachitsky回头看你在 Block 的这段时间,我总忍不住差点说成 Square,因为这个名字我已经叫太顺口了。不过为了让大家更清楚一点,Block 是整个公司的名字,Square 只是其中一个业务、一个产品。

Dhanji R. Prasanna对,没错。我们现在四个主要品牌是 Square、Afterpay、Cash App 和 TIDAL;另外还有 Bitkey 和 Proto,这两个品牌主要做比特币相关的业务和硬件。

Lenny Rachitsky好,这样就清楚多了,不然大家可能会一直想“你们到底在说哪个”。那如果回头看你在 Block 的经历,有没有什么关于做产品或带团队的经验,是特别反直觉的?那种和大家常说的 startup 常识不太一样的。

Dhanji R. Prasanna我觉得其中一条就是代码质量。

作为工程师,我很早就学到了这一点,而且它后来一次又一次被验证:很多工程师会觉得,代码质量和产品成功之间有强关联,但其实这两件事并没有那么直接的关系。
我最喜欢举的例子是 YouTube。我在 Google 的时候,正好赶上 Google 收购 YouTube。那时候公司里有一种很强烈的焦虑,大家都在说 YouTube 的代码库有多糟、架构有多差,说他们居然把视频当 blob 存在 MySQL 里,诸如此类。
但你完全可以说,YouTube 是 Google 最成功的产品之一,甚至可能比很多别的产品加起来还成功。
所以产品成功与否,其实跟它被架构得有多漂亮,并没有很多人想象中那么大的关系。反过来看 Google Video,那是 YouTube 之前 Google 自己做过的产品,不知道现在还有多少人记得。它支持更多格式、更高分辨率,甚至可以上传长达一小时的视频,而当时的 YouTube 根本没有这些能力。
YouTube 当时其实就是一个只能发一两分钟短视频的产品,但最后它还是把竞争对手远远甩开了。
所以我一直提醒自己一个最核心的问题:我们到底为什么要做这些工具、这些应用、这些产品?它们是拿来给人解决具体问题的。对我们来说,就是帮助一个 Square 商户完成一笔交易,卖出一杯咖啡,或者把他做出来的东西卖给你。这才是真正重要的。
除非 Android 平台的性能问题直接影响到这个目标,否则它本身并不是最重要的事情。
这也是我职业生涯里一直觉得最难的一件事。我总会遇到工程师说:“我们得重构,我们得用更好的方式重写。”
而我的反应常常是:不用,这些代码明天全扔掉都可以。先把注意力放回我们究竟在造什么,又是在为谁造。

Lenny Rachitsky这真的是一个很厉害的洞察。YouTube 这个故事也太有意思了。你的意思是,当时大家真的认为他们把视频内容直接以 blob 的形式塞进 MySQL 行列结构里?

Dhanji R. Prasanna对,这是当时很普遍的说法。当然我自己没亲眼看过代码,所以没法确认到那个程度,但那时大家普遍就是这么理解的。

而且他们整套栈还是 Python。放在当年,跟 Google 内部那些被我们极限优化过的 C++ 和 Java 服务相比,Python 栈看起来慢得不得了。

Lenny Rachitsky太好笑了。这也让我想到,很多时候你进入一家公司内部,都会有一种感觉:这里完全是一团混乱,谁都不知道发生了什么,感觉马上就要散架。

但现实又像是,每一家真正做成的超高速增长公司,内部某种程度上都差不多是这个样子。

Dhanji R. Prasanna这话确实有一定道理。

Lenny Rachitsky所以归根结底,决定业务成功的因素里,有太多事情都比“代码写得是不是漂亮”更重要。

你刚才说得特别好:关键是你有没有在为用户解决真实问题?你能不能把东西交到他们手里?能不能持续帮他们解决问题?重点不是代码质量,也不是你内部运转得有多规整。

Dhanji R. Prasanna完全同意。Cash App 早期其实也是这样。

我当时负责 Cash App 的工程,从团队大概 10 个工程师的时候一路带到 200 多人,用户规模也从早期增长到上千万级别。那个阶段看起来也很乱。从外面看,会觉得所有人都在做各种随机实验,做好了就直接上线,看起来一点也不像是在严格遵守什么软件开发生命周期之类的流程。某种程度上,这个印象也没错。
我当时一直抱持的理念是:我们有这么多聪明的工程师,如果我试图把他们都关进非常狭窄、非常受限的框里,最后造成的伤害很可能比帮助更大。
如果他们偶尔会在一些最后证明完全不值得做的东西上空转一阵子,我可以接受。因为与此同时,他们也会在另一面交付出很多真正惊艳的成果。
当然,这是一种很微妙的平衡。因为如果你完全放开,工程师的确会钻进各种兔子洞里。
但某种程度上,混乱会催生创造力。你得知道怎么构造一种“可控的混乱”。
也就是说,你得先搭一个不会轻易崩掉的地基。不能出现重大责任风险,不能在我们的场景里莫名其妙亏钱。只要这些底座被压稳,同时又允许工程师去实验、去迭代、去做那些真正让他们有能量的事情,那就是我理想中的状态。

Lenny Rachitsky说到“可控的混乱”,你在 Block 那段时间还有个很传奇的头衔。好像当年在 Square 时,你做过四年半的 “Mad Scientist”。

Dhanji R. Prasanna对。那段时间我其实是 part-time,主要是因为我的孩子当时还很小,而且有不少额外需求。

所以那时我更像一个顾问,会参与各种不同项目,帮助一些很奇怪、很疯狂的点子真正落地。我一直都很感谢 Block,愿意给我这样的空间,让我职业生涯里能有这样一段经历。

Lenny Rachitsky在我把你带进 Fail Corner 之前,再问一个问题。你前面已经分享了不少职业经验。除了这些之外,还有没有什么更底层的领导力经验,是你觉得对自己一路走到今天特别重要的?

Dhanji R. Prasanna我觉得一个特别重要的原则就是:凡事从小做起。

如果你想为了泡一杯茶去把整片海洋都烧开,我忘了这句话是谁说的了,但它真的是一句我会反复回来的提醒。那样你永远到不了终点。你只是要泡一杯茶,那就把这杯茶泡出来,不需要把世界上所有的水都烧开。

Lenny Rachitsky那听起来会是一杯非常难喝的茶,海水味的。

Dhanji R. Prasanna对。还有一句类似的话,我记得好像是 Carl Sagan 说的:“如果你想从零开始做一个苹果派,你得先发明整个宇宙。”

所以重点是,把范围缩小到眼前这个可实现、可操作的事情上。这一点非常重要。它也是我们一直以来的核心原则。哪怕在早年还只是 Square 的时候,我们就一直强调:start small。

Lenny Rachitsky有没有什么例子,是这套方法特别奏效的,或者相反,没有这么做就吃亏了?

Dhanji R. Prasanna有,Goose 就是个很好的例子。

它最开始只是一个工程师在自己时间里做的小项目,想验证一个他自己的判断,做出一个真正有用的东西。Goose 的创造者 Brad 很早就相信,也许早在整个行业还没开始反复喊 “agent” 这个词之前,他就已经觉得:agent 会是我们把 LLM 价值真正释放出来的关键路径。
于是他先做了一个 proof of concept,分享给很多人看,也拿给 Databricks、Anthropic 这些团队交流,从他们那里得到启发、学到东西。
之后它就这样一点点长出势能。
公司内部很多重要产品其实也是这么长出来的。Cash App 本身就是类似路径,最开始差不多就是一个 hack week 的想法,后来才一点点变成越来越大的产品。
我们很多项目都是先从这种很小的实验开始,再在上面继续叠起来。包括我们后来成为第一家推出比特币产品的上市公司,那件事最开始其实也是个 hack week 点子。当时参与的人就是 Jack、我,还有另一位工程师。

Lenny Rachitsky等等,那次 hackathon 的三人组就是你、Jack Dorsey,再加一个工程师?

Dhanji R. Prasanna对,就我们三个。

Lenny Rachitsky太离谱了。

Dhanji R. Prasanna是啊,很好玩。我们当时真的去 Blue Bottle 买了一杯咖啡,用 Cash Card 加比特币完成支付。现在回头看,那大概是史上最贵的一杯咖啡之一。

Lenny Rachitsky那时候比特币多少钱?两万美元?

Dhanji R. Prasanna我记得那时候大概六七千美元吧,不太确定。

Lenny Rachitsky现在都 12 万了。太夸张了。

Dhanji R. Prasanna但这个例子很能说明一件事:如果你先把注意力放在一个足够小、但已经能工作、已经对人有用的东西上,你就更容易真正把产品做出来。

Lenny Rachitsky也就是再强调一次那个反直觉点:别因为想法很大,就一上来砸一堆资源狠狠干。

Dhanji R. Prasanna对,完全是这样。

我职业生涯里也参与过这种项目。比如我在 Google 时做过 Google Wave,它试图对所有人做所有事情,在真正有外部用户之前,就已经有七八十个工程师在上面开发了。
所以那是一个非常典型的例子:起步太大,一开始就想 all in,也缺少那种先接触现实、再根据现实反馈调整的能力。

Lenny Rachitsky我记得 Google Wave。没错。当时看起来特别漂亮,话题度也很高。我现在都不太记得它具体是干什么的了,但我记得它看起来非常厉害。

Dhanji R. Prasanna对,那件事给了我很多教训。

Lenny Rachitsky还有别的吗?有没有别的重大经验?

Dhanji R. Prasanna前面那两条已经是最大的了,但我还会再加一条:凡事都要追问最底层的假设。

我们作为专业人士,很容易陷进一个陷阱:过度聚焦自己这一天、这一周、这个月正在做的东西,却没有停下来问一句,我们到底为什么要做它?甚至,这件事真的有必要做吗?
有没有可能,做一个完全不同的东西,反而更符合我们存在的核心理由?
所以我会说,去质疑底层前提。虽然这听起来很像一句陈词滥调,但你真的得反复提醒自己,把它一次又一次地用出来。

Lenny Rachitsky我以前还请过你一位同事上播客,IO,当年也和你一起做过 Cash App。

Dhanji R. Prasanna对。

Lenny Rachitsky他是我朋友,非常厉害。他有一句话跟这个思路很像,我记不清原话了,但大意就是:要摸到你正在做那件事的 bare metal,真正接触你正在构建的东西,回到底层去理解究竟发生了什么。

我猜这在做 Cash App 和 Cash Card 时应该特别重要。

Dhanji R. Prasanna对,IO 是我合作过最优秀的产品人之一,也是我非常亲近的朋友之一。所以这一点我完全同意。

English No English text found
No English transcript text was found for this chapter.
章节 07 / 09

第07节

中文 译稿已完成

Lenny Rachitsky好,接下来我要带你进入我播客里一个固定环节,叫 Fail Corner。

你前面已经提过一个你参与过、但最后没做成的产品。我想再多问一个。问题其实很简单:你做过哪个最后没有跑出来的产品?因为很多听众在节目里听到的,往往都是这些非常成功的人上来讲一连串成功故事,但他们很少听到那些事情没成的时候到底发生了什么。所以这个问题本质上就是:你做过哪个没做成的产品,它又教会了你什么?

Dhanji R. Prasanna这是个特别有价值的问题。

如果老实说,我的职业生涯某种程度上几乎就是一串失败产品叠着另一串失败产品。Google Wave 算一个。我还在 Google+ 上短暂待过一阵,那也是一次很史诗级的失败。

Lenny Rachitsky这个例子不错。

Dhanji R. Prasanna我还在一家叫 Secret 的社交创业公司做过。它曾经短暂地非常火,但很快又炸掉了。后来我们还做过一个邮件创业项目,起初也很有希望,但最后也熄火了。那个项目是 Canva 的一位联合创始人和我一起做的。

所以一路走来,失败其实是一串接一串的。
但我觉得,每一次失败我都学到一些东西,也学会了下次不要再犯同一类错误。
对我来说,Cash App 大概算是最重要的一次成功:那是一个我很早期就参与进去的产品,后来长成了一个巨大的业务,也成了很多人真正喜欢的产品。
所以如果回头看,我的职业生涯本质上就是:把这些失败里学到的东西带进下一次尝试,同时在这个过程中,也逼着自己长出更多谦逊。
你会更愿意听别人的看法,尤其是那些批判性的看法;你也不再理所当然地觉得自己拥有全部答案。

Lenny Rachitsky我敢打赌,这些失败掉的产品里,很多代码都写得很漂亮,架构决策也都做得很“对”。

有些可能是这样,有些可能从头到尾哪儿都不行。产品失败的原因永远很多。太真实了。
Dhanji,在我们进入激动人心的 lightning round 之前,还有没有什么你特别想补充、或者想再强调一下的?

Dhanji R. Prasanna我想说的是,我们正处在一个变化非常剧烈的时代。很多人会害怕、迟疑,或者对未来方向感到不确定。

这时候,最重要的是去看那些真正对你有意义的东西。对我们来说,是开源、开放协议,以及让更多人获得更好的访问能力。
我一直觉得自己职业生涯挺幸运,因为我参与过的产品,要么是免费的,要么几乎所有人都负担得起,或者至少都有免费层,之后才对一些高级服务收费,而且它们本质上都是对所有人开放的。任何人都可以成为 Square 的卖家。
我还记得在很早期的时候,人们甚至会拿它来做点对点转账,这也是后来我们做 Cash App 的起点之一,而那个方向最后非常成功。
所以我觉得,关键是先看清楚什么东西对你真的重要,然后围绕它去做优化。
技术趋势本身往哪个方向长,其实没有那么重要。因为技术归根结底是为人服务的。如果我们本身有一个重要的存在理由,有一个真正重要的目标,那我们就可以让技术来服务这个目标。
这件事,比你是不是最懂技术、是不是站在每一波趋势最前面,更重要得多。

Lenny Rachitsky这建议太好了。现在值得关注的东西实在太多,变化也太快,人特别容易焦虑,觉得自己好像没跟上所有新东西,看着社交媒体上的人,总会想“是不是大家都比我懂 AI,我是不是已经落后太多了”。

我从你这里听到的更像是:先问自己,真正重要的到底是什么。然后就去做那件事。没必要逼自己在所有最新 AI 新闻和所有新工具上都做到最强。

Dhanji R. Prasanna对,完全就是这个意思。

而且如果一件事既没有意义,也不好玩,那你大概率就不该做它。

Lenny Rachitsky好,Dhanji,我们正式进入激动人心的 lightning round。我会连续问你五个问题,准备好了吗?

Dhanji R. Prasanna来吧。

Lenny Rachitsky我看到你身后有很多书,所以我对第一个问题特别期待。你最常推荐给别人的两三本书是什么?

Dhanji R. Prasanna我其实一直有个很明确的观点:最好不要总读那些和你日常工作、职业生活直接相关的书。

我更爱读小说、经典文学、诗歌、哲学、历史。这些才是我真正喜欢的阅读内容。我觉得它们更能打开人的思维,给你创造性的灵感,也会帮助你去重新思考人的处境到底是什么。
这比什么自助书、什么“如何成为一个更好的工程经理”的书,对我来说价值更大。
如果真要推荐的话,米哈伊尔·布尔加科夫的《大师与玛格丽特》是我特别喜欢的一本,它是俄罗斯文学里的杰作。
另外,我一直很喜欢丁尼生的诗。尤其是在我感到不确定、或者经历悲伤的时候,丁尼生的诗总能和我产生很深的共鸣,也能帮助我重新找到内在的重心。

Lenny Rachitsky哇,这些推荐我以前从没在节目里听到过。我真的很想去看看。对于一家大科技公司的 CTO 来说,这份书单也太不一样了。

最近有没有你特别喜欢的电影或电视剧?

Dhanji R. Prasanna我觉得《Alien Earth》特别棒。

它是 Noah Hawley 做的,他之前也做过《Fargo》电视剧。所以这是一个拥有非常强烈艺术表达能力的创作者,跑来做一部偏通俗、偏类型化的科幻剧。
它的视觉真的非常惊艳,气质也很强,而且把《异形》系列那种最核心的、带点低俗 pulp 感的魅力抓得特别好,所以我很喜欢。
我最近也在看《Slow Horses》,我觉得它是现在电视上最好的剧之一。

Lenny Rachitsky我也很喜欢《Slow Horses》。新一季已经出了,我们录这期的时候,第五集好像刚刚更新。《Alien Earth》我也刚看过,真的又 creepy 又恶心,到处都是那种黏糊糊、湿漉漉的小生物在爬。

Dhanji R. Prasanna对,我特别喜欢它的审美。他们确实抓住了最早那部《异形》里一种很本质的东西。

而且《Alien Earth》里几乎每一场戏都像在看一幅画,或者像有人在给你读一部小说。它展开得很克制,也很讲究。

Lenny Rachitsky我以前从来没看过任何《异形》相关内容,但《Alien Earth》我真的看得很开心。不过我得说,结尾的时候我会有点感觉它节奏慢下来了,好像“好吧,我知道你接下来想怎么收了”。但整体还是很好看。

好,下一个问题。最近有没有你新发现、而且特别喜欢的产品?可以是 app、电子设备,或者厨房小工具。

Dhanji R. Prasanna我是个 gamer,我很喜欢打游戏。所以对我来说,最近最喜欢的产品是 Steam Deck,尤其是新版的 Steam Deck OLED。

它是一件非常漂亮的硬件产品,能让你玩到现在最好的游戏,同时又高度可扩展、可定制。
在这个时代,大科技公司总在告诉我们:为了让产品“正常工作”,必须把一切都锁死,必须把用户体验和可定制性一起封住。
但我觉得 Valve 证明了,这套说法完全没必要,而且本质上也是错的。
Steam Deck 就是一个反例。你可以安装竞争对手的应用商店,可以装 Windows,可以把它当成一台真正的电脑来用。我自己都在上面写过程序、跑过东西。
所以我觉得它是个非常不可思议的产品。它长得也漂亮,用起来也很好。我是它的超级粉丝。

Lenny Rachitsky你有没有一句自己常常会回到的 life motto?无论是工作里还是生活里。

Dhanji R. Prasanna如果你每天早上醒来,对自己当天要做的专业工作完全提不起劲,那就去改变点什么。

如果最后需要的是辞职,那就辞;如果不是,那就换一种方式做你正在做的事。总之,不要只是被动接受别人分配给你的生活。
我一直尽量这么活。有时有用,有时也不完全成功,但我觉得它始终是一个值得反复问自己的问题。

Lenny Rachitsky我真的很喜欢这条建议。但对很多人来说,这其实非常难。有没有什么东西,能帮助你克服那种“天啊,我真的要离开这个东西了,可我根本不知道下一步去哪”的恐惧?

Dhanji R. Prasanna最有用的一件事,是提醒自己:一年以后,当你回头看今天这个似乎像天塌下来一样的问题时,你大概率会觉得,“原来这件事这么小”。

很多时候,我们会陷进一种过度思考,或者特别害怕改变。但等你真的走过去,再回头看,会发现那些事并没有当下感觉那么巨大。
时间往前走之后,发生的很多事情会提醒你:世界远比你当下看到的那一点大得多。
永远不会太晚去做一件有用的事,也永远不会太晚去做一件真正对自己有益的事。
所以我觉得,时刻记住:很多事情并没有当下看起来那么大、那么糟、那么决定性,这一点非常重要。

Lenny Rachitsky最后一个问题。你以前在 Square 做过好多年的 “Mad Scientist”。那在流行文化或者现实世界里,你自己最喜欢的另一个 mad scientist 是谁?

Dhanji R. Prasanna这问题挺有意思。

我脑子里第一个冒出来的形象一直是《回到未来》里的 Doc Brown。我觉得他几乎就是我们这一代人心中最标准的 mad scientist。
当然电子游戏里也有很多这种角色,但他是那个让我觉得,“我就是非得做这件疯狂的事不可”的典型人设。像是心里有一团火在烧着他,不管愿不愿意,他都必须把这台时光机造出来。然后整部电影里,他都在想办法修补这台机器带来的各种问题。
所以对我来说,他一直都是个特别有趣的角色。

Lenny Rachitsky你知道吗,我想到的是《Pinky and the Brain》里的 Pinky。

Dhanji R. Prasanna哦,对,这个也很好。

Lenny Rachitsky太有意思了。Dhanji,这期聊得太好了,真的非常感谢你来。

最后正式收尾前还有两个问题:如果大家想在线上找到你,想了解 Goose,或者想进一步看看 Block 现在在做什么,可以去哪里?以及,听众可以怎样帮到你?

Dhanji R. Prasanna可以先去看我们 Goose 和其他开源项目的 GitHub Pages。Block 其实还有很多很有用的开源项目,尤其是在 Android 开源这块,也有不少东西值得看看。

你也可以在 LinkedIn 上找到我,欢迎来连接,我很愿意和大家交流。
至于大家怎么帮到我,我还是想回到前面说的那件事:我们正处在一个变化巨大、也充满不确定性的时代。我觉得最重要的是,人们应该对自己的公司、雇主和团队提出更高要求,要求一个更好的方向。
在 Block,我们会不断追问:这件事能不能默认做成开源?能不能不仅是为我们自己或客户做,而是让更多人都受益?
尤其在 AI 这个时代,这一点格外重要。因为现在几乎每个人都在试图把自己锁进围墙花园里,试图提前占住新平台的一部分入口。
但互联网最初被创造出来,本来就是一个开放共享信息、让所有人都能受益的承诺。我觉得 AI 也应该替我们兑现这个承诺。
所以如果要说一句最直接的话,那就是:去向人们要求更好的东西。

English No English text found
No English transcript text was found for this chapter.
章节 08 / 09

第08节

中文 译稿已完成

Lenny Rachitsky这个收尾方式太好了。Dhanji,非常感谢你今天来。

Dhanji R. Prasanna谢谢你,Lenny。我真的很感激这次对话,谢谢。

Lenny Rachitsky我也非常感谢你。

Dhanji R. Prasanna干杯。

Lenny Rachitsky各位拜拜,非常感谢收听。如果你觉得这一期对你有帮助,欢迎在 Apple Podcasts、Spotify,或者你常用的播客 App 里订阅这档节目。也欢迎顺手打个分、留条评论,这真的会帮助更多听众发现它。你可以在 `lennyspodcast.com` 找到往期节目,或者了解更多关于这档播客的信息。我们下期见。

English No English text found
No English transcript text was found for this chapter.
章节 09 / 09

第09节

中文 译稿已完成

Lenny Rachitsky这个结尾真漂亮。Dhanji,非常感谢你今天来。

Dhanji R. Prasanna谢谢你,Lenny。我真的很感激这次聊天,谢谢。

Lenny Rachitsky我也很感谢你。

Dhanji R. Prasanna干杯。

Lenny Rachitsky各位再见,感谢收听。如果你觉得这一期有帮助,欢迎在 Apple Podcasts、Spotify,或者你常用的播客 App 里订阅这档节目。也欢迎给节目打分、留评论,这会帮助更多听众找到它。你可以在 `lennyspodcast.com` 查看往期内容,或者了解更多节目信息。我们下期见。

English No English text found
No English transcript text was found for this chapter.