Dhanji's most counterintuitive career lesson: engineers think code quality drives a successful product, but the two have nothing to do with each other. His favorite example is YouTube — reportedly storing videos as blobs in MySQL on a slow Python stack, widely mocked at Google, yet it blew away the better-architected Google Video (which supported more formats and higher resolution). Focus on the problem you solve for people, not the elegance of the code.

Engineers believe code quality builds successful products; Dhanji says the two are unrelated
YouTube was reportedly storing videos as blobs in MySQL on a slow Python stack
Google Video was better-architected (more formats, higher resolution) and lost anyway
The point of the code is to solve a specific problem for people — the code could be thrown away tomorrow

“A lot of engineers think that code quality is important to building a successful product. The two have nothing to do with each other.”
Dhanji R. Prasanna · 1:02:00

“how horrible the YouTube codebases and how terrible their architecture is and they're storing videos as blobs in my SQL and whatnot.”
Dhanji R. Prasanna · 1:02:30

#myth buster#code quality#product#youtube

Hot Take· 3

Hot Take19:30

Why AI Skeptics Fail: Throwing Tools at Giant Codebases

Dhanji's explanation for why some companies see no AI value: they throw tools at their giant existing codebases and hope for the best. AI still underperforms humans where senior engineers do deep work — architecture, design, race conditions, orchestration — so that's where humans should lean in. He believes it'll improve, but says we're still in an early utility phase.

AI still underperforms humans on architecture, design, race conditions, and orchestration
Failing companies just point tools at massive legacy codebases and hope
Value is changing daily — you have to ride the wave and plan for tomorrow's capability
We're still in the 'early utility phase'

“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…”
Dhanji R. Prasanna · 19:30

“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…”
Dhanji R. Prasanna · 20:00

#ai limitations#hot take#engineering#adoption

Hot Take26:30

Block Built a Product Rivals Charge For, and Gave It Away

Lenny points out Goose could have been a massive standalone business — some of the fastest-growing companies sell essentially this product. Dhanji says Block gave it away on principle: increasing openness is a core mission, and as a company built on open-source software (Linux, Java, MySQL) they feel an imperative to give back and build things that outlast and outgrow Block. He notes competitors and partners, including Databricks, use Goose regularly.

Goose could have been a large standalone business but was open-sourced
Openness is a stated core mission; giving back to open source is an imperative
Goal is to build things that outlast and outgrow Block
Competitors and close partners use Goose actively; Databricks talks about it a lot

“This feels like it could have been a massive business of its own.”
Lenny Rachitsky · 27:00

“increase openness and that means contributing to open protocols and contributing to open source”
Dhanji R. Prasanna · 27:30

#open source#goose#strategy#hot take

Hot Take33:00

What If Every Release Deleted the App and Rebuilt It?

Dhanji wants agents working the way humans can't — overnight and on weekends, building multiple experiments in parallel so you wake up and throw five of six away. He pushes his teams to imagine rm -rf'ing the entire app and rebuilding from scratch every release. It directly contradicts the old rule of never rewriting, but he argues AI makes it possible if you get the AI to respect and bake in all the incremental improvements.

LLMs sit idle overnight and on weekends — they should be building in anticipation of what we want
Describe many experiments in detail, sleep, and throw away the ones that don't feel right
He regularly throws away huge amounts of code, not just deleting but rebuilding whole systems
The provocation: what if every release deleted the entire app and rebuilt it from scratch?
The trick is getting AI to respect the incremental improvements as part of the spec

“all these LLMs are are sitting idle overnight and on weekends while humans aren't there. Like, there's no need for that.”
Dhanji R. Prasanna · 33:30

“one of the things that I do regularly is just throw away huge huge amounts of code.”
Dhanji R. Prasanna · 34:30

#future of engineering#ai agents#hot take#goose

Explainer· 1

Explainer08:00

Why Block Killed Its GM Structure to Go AI-Native

Block had run its brands (Square, Cash App, Afterpay, Tidal) as a GM structure — a portfolio of independent companies with their own CEOs, engineering, and design teams. Dhanji argues that to go deep on technology and AI you need singular focus, so they collapsed everything into a functional org: all engineers under one head of engineering, all designers under one head of design. He frames it as returning Block to its identity as a technology company, not a fintech.

GM structure ran brands as separate companies with separate engineering and design practices
Functional structure: single head of engineering, single head of design across the whole company
A given seniority level now means the same thing company-wide; engineers can move to areas of need
He explicitly compares it to Steve Jobs reorganizing Apple to be functional on his return
Framed as recovering Block's DNA of putting engineering and design first

“all engineers report into one single team. Now all designers report in one single team and there's single head of engineering, single head of design…”
Dhanji R. Prasanna · 10:30

“this is what Jobs did when he came back to Apple as well. He reorganized Apple to be functional.”
Dhanji R. Prasanna · 11:00

#org design#functional org#engineering leadership#block

Story· 4

Story05:30

The AI Manifesto Letter That Made Him CTO of Block

About two and a half years ago, Dhanji was a part-time senior engineer who noticed that Block's ~40 top executives were discussing everything except AI in their weekly meetings. He wrote Jack Dorsey a short letter arguing Block should go all-in on AI, centrally. It took on a life of its own — Jack spent two days walking around Sydney with him and offered him the CTO role.

He was part-time at the time, having just had a kid, helping one engineering team
The letter's core argument: do it, do it centrally, be ahead of the game as an AI-native company
Jack got ~40 top execs into a weekly room and added Dhanji to the group
Jack flew to Sydney, they walked and talked for two days, then he offered the CTO job

“no one was really paying attention to AI. And so that's when I wrote that letter.”
Dhanji R. Prasanna · 06:30

“I think we should do this. I think we should do it centrally. And it's important for us to uh be ahead of the game…”
Dhanji R. Prasanna · 06:30

#ai strategy#leadership#block#career

Story16:00

The Numbers: 8-10 Hours Saved a Week, 20-25% of Manual Hours

Block's top AI-forward engineering teams self-report saving 8 to 10 hours per week using Goose, validated against check metrics like PRs and feature throughput. Across the whole company — support, legal, risk, engineering — Dhanji says they're trending toward 20-25% of manual hours saved, roughly a quarter of an engineer's time, with gains far larger on greenfield code than on complex legacy codebases.

8-10 hours/week self-reported by the most AI-forward engineering teams
Validated with check metrics: PRs, feature throughput, a data-science formula
Company-wide (support, legal, risk, engineering) trending toward 20-25% of manual hours saved
Roughly a quarter of an engineer's time currently saved by AI tooling
Gains are aggressive on greenfield/new-platform code, weaker on large complex legacy codebases

“Our number one priority is to automate block which means getting AI and getting uh AI forms of automation through our entire company”
Dhanji R. Prasanna · 16:00

“reporting about 8 to 10 hours saved per week. Uh and this is self-reported and then we also have a number of check metrics to…”
Dhanji R. Prasanna · 16:30

#ai productivity#metrics#goose#engineering

Story17:30

The Most Surprising Win: Non-Technical Teams Building Their Own Tools

Dhanji says the most surprising and energizing use of Goose is non-technical teams building software for themselves. Their enterprise risk management team built a whole self-service risk system, compressing weeks of work into hours instead of waiting for an internal apps team to slot it into a Q2 roadmap. He also cites Gling, a 'Goose for mobile' that drives Android at the OS level via the accessibility API to automate UI tests that once needed armies of QA contractors.

Enterprise risk team built a self-service risk system, compressing weeks into hours
Removes the wait for an internal apps team and its roadmap queue
Gling is a 'Goose for mobile' that operates Android natively via the accessibility API
Gling automates UI tests previously done by armies of QA contractors clicking every screen

“we'll have our enterprise risk management team build a whole system for self-serviceing enterprise risk and this is compressing like weeks of work into hours”
Dhanji R. Prasanna · 18:00

#ai productivity#no-code#goose#automation

Story28:30

The Engineer Who Lets Goose Watch His Screen All Day

One Block engineer on the core Goose team built a system where Goose watches everything he does via screenshots and voice, all the time. When he and a colleague discuss a feature on Slack, a few hours later Goose has already tried to build it and opened a PR. It also nudges him when he's running over on meetings and reschedules conflicts. Dhanji frames it as an experiment that shows where things are going once the tooling gets good enough.

Goose processes screenshots and voice to watch his workflow continuously
It builds features discussed in Slack/email and opens PRs unprompted, hours later
It nudges him out of workflows when he's late and reschedules meeting conflicts automatically
Still an experimental side project by a core Goose team member, not a shipped feature
Points to a future where calendar/tool vendors' features get orchestrated by AI instead

“he'll find that Goose has already tried to build that feature and open a PR for it on on Git”
Dhanji R. Prasanna · 29:30

#ai agents#goose#future of work#automation

Q&A· 1

Q&A48:30

Which Level of Engineer Benefits Most From AI?

Asked whether junior or senior engineers gain most from AI tools, Dhanji says both ends are the most eager adopters — seniors are relieved to offload work they've done a million times, juniors blitz through like kids on a phone. But the real surprise is non-technical people using AI agents to build things, which he says signals how blurred the lines between legal, risk, engineering, and design will become.

The most senior and most junior engineers are the most eager adopters, for different reasons
Seniors are relieved to hand off work they've done many times; juniors move fast and fearlessly
The biggest surprise is non-technical people building software with AI agents
Role lines between legal, risk, engineering, and design will blur

“the non-technical people using AI agents and programming tools to build things is really what's been surprising”
Dhanji R. Prasanna · 49:30

#ai adoption#engineering#future of work#hiring

Tool· 1

Tool21:30

What Goose Is: An Open-Source Agent Built on MCP

Goose is Block's general-purpose AI agent — a downloadable desktop app (also CLI) with a pluggable model provider system that works with any model. Its power comes from the Model Context Protocol (MCP), Anthropic's standard for wrapping existing tools like Salesforce, Snowflake, or SQL so an LLM can manipulate them. Goose gives LLMs 'arms and legs' to act, can chain across systems to build and email a full marketing report, and can even write its own MCPs. It's entirely open source.

General-purpose agent as a desktop app plus a command line, for Mac/Windows/Linux (Electron)
Pluggable providers: bring your own keys for Claude/OpenAI, or run open-source models via Ollama
Built on MCP (from Anthropic), which Block was an early contributor to
MCP = formalized wrappers around existing tools, exposing them to the LLM
Can orchestrate SQL pulls, Python analysis, charts, and a PDF/Google Doc it emails for you
Entirely open source; Goose can even write its own MCPs

“until that point the uh LLMs were not really able to do much other than chat but goose gives these brains arms and legs to…”
Dhanji R. Prasanna · 23:00

“Goose is entirely open source by the way. So any of you can download it and extend it, write your own MCPS.”
Dhanji R. Prasanna · 23:30

#goose#mcp#ai agents#open source

Takeaway· 4

Takeaway12:00

Conway's Law: You Ship Your Org Structure

The biggest lesson of the transformation was how powerful Conway's law is — your team structure and operating model determine what you build. Block's silos (Cash App, Afterpay, Square, Tidal) each had momentum but weren't talking to each other or aligned on technical strategy, so nothing cohesive got built across them.

How you're organized into teams and collaborating groups shapes the product you ship
Each silo had its own momentum but no shared five-year technical vision
Post-reorg, teams share tools, policies, and language even if it's not perfect yet
Changing outcomes requires changing the structure of relationships between people

“Conway's law can be really really powerful.”
Dhanji R. Prasanna · 12:00

“So what you're organized as in terms of teams in terms of collaborating groups and and your operating model matters a lot to what you…”
Dhanji R. Prasanna · 12:30

#conways law#org design#engineering culture

Takeaway40:00

Build vs Buy: The Dollars Aren't the Point

On whether AI lets you replace SaaS by building your own tools, Dhanji warns against drifting from your core purpose. Block's purpose is economic empowerment; anything serving that is worth investing in, but chasing pure dollar savings by replacing vendor tools usually isn't worth the lost mental bandwidth and technical focus. He and Lenny land on the classic 80/20: build resonates fast, then you pay a long tail of maintenance and edge cases.

Judge build-vs-buy against core purpose, not dollar-for-dollar savings
In-house replacements often aren't worth the lost mental bandwidth and technical focus
Maintenance is the hidden cost — 'built it in a weekend' becomes years of support
Cash Card was built in roughly a weekend but took ages to iron out edge cases (double-tipping, gas-station billing)

“the savings and cost that there might be in replacing a vendor tool by something you build in house is probably not worth it in…”
Dhanji R. Prasanna · 41:00

“it feels like it comes back to the uh always motto of just focus on your core competencies and then buy everything else.”
Lenny Rachitsky · 42:00

#build vs buy#saas#product strategy#takeaway

Takeaway52:00

Structure Matters More Than the Efficacy of Your Tools

Block used Goose to build a tool that selects the right tests for a change, cutting 50% of test runs. But Dhanji notes that offloading tests to the cloud or simply deleting tests that no longer make sense saves two to three times more. The lesson, echoing his build-vs-buy point: question whether the process needs to exist at all. Sometimes org structure matters more than how good your tools are.

A Goose-built tool selects the right tests per change, cutting ~50% of test runs
Offloading to the cloud or deleting pointless tests saves 2-3x more than that
Portfolio judgment — do we even need this process? — beats tool efficacy
Lenny's framing: to be more productive, forget AI and just reorg into a functional structure

“I love this hot take of uh if you're trying to be more productive, forget AI, just reorg into a functional structure.”
Lenny Rachitsky · 52:00

“simply just deleting tests that don't make sense anymore probably save you two to three times that.”
Dhanji R. Prasanna · 53:00

#engineering productivity#org design#testing#takeaway

Takeaway1:08:00

Start Small: Don't Boil the Ocean to Make a Cup of Tea

Dhanji's core leadership tenet is to start small and narrow your scope to what's achievable in front of you. Goose started as one engineer's proof of concept; Cash App and Block's first-ever public-company Bitcoin product both began as hack-week ideas. He contrasts this with Google Wave, where 70-80 engineers built an everything-to-everyone product before it had real users.

Narrow scope to the achievable thing in front of you rather than boiling the ocean
Goose began as one engineer (Brad) building a proof of concept on a thesis about agents
Cash App and Block's first Bitcoin product both started as hack-week ideas
The first Bitcoin purchase was a Blue Bottle coffee bought over Cash Card — 'the most expensive cup of coffee' in hindsight
Counter-example: Google Wave went big on day one with 70-80 engineers and no outside users

“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.”
Dhanji R. Prasanna · 1:08:30

#start small#product strategy#leadership#takeaway

Frameworks in this episode

Code Quality Doesn't Equal Product Success

Conway's Law Reorg: Go Functional Before You Go AI

Drive AI Adoption By Using It Yourself On A Real Problem

Question the Base Assumption Before Build-or-Buy

Ride the AI Value Wave

Start Small, Don't Boil the Ocean

Insights & moments

⚡Myth Buster· 1

Code Quality Has Nothing to Do With Product Success

◆Hot Take· 3