MoreRSS

site iconLenny RachitskyModify

The #1 business newsletter on Substack.
Please copy the RSS to your reader, or quickly subscribe to:

Inoreader Feedly Follow Feedbin Local Reader

Rss preview of Blog of Lenny Rachitsky

How to debug a team that isn’t working: the Waterline Model

2026-03-03 21:45:17

👋 Hey there, I’m Lenny. Each week, I answer reader questions about building product, driving growth, and accelerating your career. For more: Lenny’s Podcast | Lennybot | How I AI | My favorite AI/PM courses, public speaking course, and interview prep copilot

Subscribe now

P.S. Get a free full year of Lovable, Manus, Replit, Gamma, n8n, Canva, ElevenLabs, Amp, Factory, Devin, Bolt, Wispr Flow, Linear, PostHog, Framer, Railway, Granola, Warp, Perplexity, Magic Patterns, Mobbin, ChatPRD, and Stripe Atlas by becoming an Insider subscriber. Yes, this is for real.


Molly Graham is the epitome of the type of person I love to collaborate with. She spent decades working closely with some of the most successful leaders in tech, including Mark Zuckerberg, Sheryl Sandberg, Chamath Palihapitiya, and Bret Taylor, and more recently (through her Glue Club community), she’s guided hundreds of leaders through the chaotic, lonely, and overwhelming journey inside early-stage and fast-growing companies. Drawing from these experiences, she is able to find patterns in what works and doesn’t and, more than anyone else I’ve met, is able to translate these lessons into powerful and memorable metaphors.

In her piece below, which I suspect will become as iconic as “Give Away Your Legos,” she builds on our recent podcast conversation to unpack a management framework that will change how you tackle team challenges: the Waterline Model.

Let’s get into it.

For more from Molly, check out her Substack and LinkedIn, and her Glue Club community. You can listen to this post in convenient podcast form: Spotify / Apple / YouTube.


There’s a moment most leaders recognize. You’ve set a clear goal (or so you think), your team’s bought in (or so they say), yet timelines keep slipping, execution is messy, and you’re having the same conversations over and over. When that happens, it’s tempting to jump straight to people-based explanations: “This team just doesn’t work well together.” “That person isn’t strong enough.” “We need better execution.”

Sometimes that’s true. But after two decades of working inside companies like Google, Facebook, and the Chan Zuckerberg Initiative, and supporting leaders at companies like Stripe, Anthropic, OpenAI, Microsoft, and Gamma, I’ve come to believe that blaming people for problems that are actually structural is one of the biggest leadership traps there is.

I’ve learned to slow down in these moments and use a simple diagnostic tool I picked up early in my career: the Waterline Model.

I first learned how to use this tool when I was leading 75-day wilderness expeditions in Patagonia and Alaska for the National Outdoor Leadership School at age 22. Out there, when a team isn’t working, things fall apart fast. People get cold, hungry, tired, scared. There’s no hiding behind process or politeness, and there’s definitely no time for vague diagnoses like “the vibe is off.” You have to identify the source of what’s disrupting the team—not just the symptoms—and fix it quickly.

We learned the Waterline Model1 as instructors and taught it as part of the curriculum to students. Since then, I’ve used it anytime a team is underperforming, missing goals, or struggling more than they should be. More than anything, it has helped me avoid misdiagnosing problems, cycling through people unnecessarily, and wasting time fixing the wrong thing. At its core, the Waterline Model is a way to diagnose where a problem is actually coming from before you decide what to do about it.

In this post, I’ll walk through the model and show you how to use it as a practical diagnostic tool when a team is underperforming. We’ll look at the four levels where problems tend to show up—structure, dynamics, interpersonal, and individual—and how to work through them in the right order. By the end, you should be better equipped to slow down in those “something’s off” moments, identify the real source of friction on a team, and fix the right problem instead of defaulting to people changes.

How the Waterline Model works

Here’s the basic picture. Imagine a boat moving across the water—that boat is your team. The boat’s destination is your goal: hitting a KPI, winning a major new customer, shipping a product. Sometimes the water is calm and the boat is moving forward smoothly. Other times, it feels like you’re rowing through a hurricane and no one can quite explain why.

When I use this model, I’m able to move beyond the natural human instinct to automatically blame the people. The Waterline Model helps me investigate one question: What’s going on below the surface that’s making things harder than they should be?

This model gives you four places to look, in order, and it comes with a memorable rule of thumb: snorkel before you scuba. Start at the top, always. Snorkeling means checking the shared systems first—goals, roles, and decision-making—before you start diagnosing personalities.

At the top, just below the surface, is structure. This is the stuff that helps people know what they’re doing, why they’re doing it, and how success is defined: vision, goals, context, expectations, role clarity, and org design. In my experience, this is where a huge percentage of issues on teams actually shows up.

The next layer is dynamics—how the team works together day-to-day. This is where I look at how decisions get made, how conflict shows up and gets resolved, and how information flows (or doesn’t). Even with clear goals and roles, teams can struggle here. Structure and dynamics are systems shared by everyone on the team, so you can most directly affect the collective team performance at these levels.

Below that is interpersonal—tension between two people, lack of trust, unresolved conflict, style clashes. These issues are real, but they’re often caused or amplified by problems higher up.

And at the very bottom is individual—what’s happening inside a single person: skill gaps, stress, confidence, values, life stuff.

All four layers matter. Any one of them can make the water choppy.

But the Waterline Model and “snorkel before you scuba” remind me to start with the issues that impact the most people—closest to the surface—and only go deeper once I’ve ruled things out. Before you decide someone is the issue, you need to know that structure and dynamics aren’t pushing them toward exactly the behavior you’re frustrated by.

Let’s walk through each level and use common examples of issues on underperforming teams to show how you can use the model.

Structure: the most common culprit

A few years ago, I was asked to take over a struggling marketing team: “Go figure out what this team actually does, and why we’re spending so much money without seeing results.”

The temptation in a situation like this is to diagnose the people—who is a high performer, who is dragging people down—but the Waterline Model has taught me to start by evaluating the structure. So instead, I asked each person on my new team how they would describe their role, what goals they thought the team was responsible for, and what numbers they believed they personally owned and were expected to move. Almost immediately, those questions surfaced structural issues.

The team’s answers were wildly inconsistent. Individuals had no idea what their goals were or which metric the team was responsible for. People defined their roles in ways that were far too narrow, or disconnected, to make sense. What leadership thought the team was responsible for, and how success was measured, were very different from how people understood their own jobs.

In this case, it was impossible to determine whether the individuals were the right fit, because they were operating inside a deeply broken structure. If I had automatically assumed people were the problem, I probably would have fired the whole team and started over again. And then I’d likely have ended up with the same issues all over again. But once I realized this was a structural problem, the fix was clear.

I started by re-clarifying the team’s mandate, the goals the team actually owned, individual role definitions, and what success looked like for each role. Only after that work was complete did it make sense to evaluate whether each individual was a good fit for their role.

That clarity surfaced a few real fit issues. But it also immediately improved performance for most of the team—simply because people finally knew what their job was and what was expected of them. People are often smart and motivated, but (to use the boat analogy) they’re rowing in different directions because the structure isn’t doing its job. Structural clarity alone often resolves more issues than you’d expect.

Dynamics: teams behaving rationally inside bad systems

Dynamics are the cultural norms you’ve built for how the team actually works together day-to-day. What’s experienced, not what’s written down. You can have clear goals and roles and still find yourself with decisions bottlenecked at the top, endless debate with no resolution, or constant confusion about who has input versus who actually decides.

As an example, one member in Glue Club came to us with a familiar story: “My founder is constantly frustrated that the team is moving more slowly than they want. But when people try to move quickly or ship things or make decisions, the founder swoops in and unmakes decisions at the last minute or second-guesses people’s judgment. It doesn’t feel safe to move quickly.”

This wasn’t a structure problem. Goals were clear, roles were defined, and, on paper, people had decision rights. But in practice, decisions weren’t stable. Work would move forward, then get reversed later. Context would change after the fact. People learned that even if they did what was asked, they could still be wrong.

The team adapted in a very rational way: They slowed down. They added extra layers of alignment. They escalated decisions that technically didn’t need to be escalated. They optimized for not being wrong instead of for progress.

From the outside, it looked like a performance problem. From the inside, it felt like self-protection. The dynamics of this team taught people that speed is risky, and that was the problem.

People adapt quickly to what’s rewarded, punished, tolerated, or ignored. Over time, the team learns how to survive inside the system a leader creates, whether implicit or explicit. Dynamics problems show up when a team’s behavior makes sense given the environment—even if the results are exactly what you don’t want.

Dynamics problems often show up as process issues, but they’re rarely solved by process alone. They usually trace back to the signals leaders send through their behavior: what gets rewarded, what gets second-guessed, and what happens when things go wrong. That’s why dynamics issues can feel harder than structural ones. Fixing them doesn’t require a re-org or a new doc; it requires leaders to be consistent about how decisions are made, how disagreement is handled, and when they intervene. It requires a hard look in the mirror at how your behavior or the behavior of those above you is causing people to respond.

The good news is that when those signals change, behavior changes quickly. Teams adapt fast to new rules, especially when they’re enforced through action, not words. That’s the leverage at the dynamics level: change the rules of interaction, and people will respond.

Interpersonal: don’t assume interpersonal conflict, but don’t ignore it either

When something feels off on a team, leaders almost always leap to this layer first—“those two people hate each other.” To be fair, a lot of the time that instinct isn’t wrong; it’s just incomplete.

Very often, what looks like interpersonal conflict is actually being caused by something higher up the waterline. Roles aren’t clear, ownership overlaps, or individual or team incentives are not aligned. Two people are stepping on each other’s toes because the structure put them there. In those cases, the conflict isn’t really about the relationship. It’s a structural problem wearing a human face.

But interpersonal dynamics can absolutely destroy teams all on their own. You can have clear goals, clean roles, solid decision-making, etc., and still have two leaders who fundamentally don’t trust or like each other. And when that’s true, it always shows up in the business eventually, through slowed decisions, hoarded information, and teams quietly picking sides.

Once you’ve ruled out structure and dynamics issues, you move to interpersonal, and this is the moment where management gets more direct. At this level, the fix isn’t redesigning the system but, rather, addressing the relationship itself. That usually means naming the tension explicitly, grounding the conversation in how it’s affecting the work, and being clear about what needs to change for the relationship to function. You can make building a solid relationship with a business partner an expectation of someone’s role—something you judge their performance on, particularly if it’s business-critical.

This is the more familiar work of team leadership and management. Sometimes that work leads to repair. Sometimes it becomes clear that trust won’t be rebuilt in a reasonable time frame, and a change has to be made.

Individual: only make it about the person after the system is sound

If your goals are clear, the role is cleaned up, the dynamics are working well, and someone is still not performing, then you’re likely looking at an actual individual issue. At that point, the work is no longer diagnostic. It’s about making a decision.

Individual issues can be personal. Someone going through a tough time outside of work may not be able to meet the expectations of the role right now. Your job as a manager is to decide whether the person can successfully fulfill the role, given the current circumstances.

Evaluate the person against the role as it exists today. Decide whether the gap is coachable in the time frame the business can afford. If it is, invest and be explicit about what needs to change. If it’s not, change the role or make a clean exit. What doesn’t work is lingering in ambiguity.

That’s the leverage at the individual level: once the system is sound, clarity and decisiveness are kinder than dragging things out.

Start at the top. Always. If your team isn’t working well, here’s what the Waterline Model tells you to do:

Read more

How to debug a team that isn’t working: the Waterline Model

2026-03-03 21:02:55

If you’re a premium subscriber

Add the private feed to your podcast app at add.lennysreads.com

When their team underperforms, most managers jump straight to blaming people. Molly Graham—who’s worked alongside Mark Zuckerberg, Sheryl Sandberg, and Chamath Palihapitiya—explains how that’s one of the biggest leadership traps there is. In this episode, she shares the Waterline Model: a diagnostic model to help uncover the real source of team problems, before touching an org chart.

Listen now: YouTube | Apple | Spotify

In this episode, you’ll learn:

  • Why blaming people for structural problems is one of the biggest leadership mistakes

  • The four layers of the Waterline Model, and why that order matters

  • Why you should always “snorkel before you scuba”

  • How self-preservation can be a rational response to a faulty environment

  • How to make clean, decisive calls when you finally reach the individual layer

Read the post

Read more

🎙️ This week on How I AI: 5 OpenClaw agents run my home, finances, and code & How Coinbase scaled AI to 1,000+ engineers

2026-03-03 00:02:20

Every Monday, host Claire Vo shares a 30- to 45-minute episode with a new guest demoing a practical, impactful way they’ve learned to use AI in their work or life. No pontificating—just specific and actionable advice.

5 OpenClaw agents run my home, finances, and code | Jesse Genet

Brought to you by: Optimizely—Your AI agent orchestration platform for marketing and digital teams

Jesse Genet is a homeschooling parent and entrepreneur who operates five specialized OpenClaw agents, each on its own Mac Mini, to manage homeschool curriculum, family finances, scheduling, development projects, and household operations. She treats each agent like a new hire: defined role, scoped access, decision log, and progressive trust. In this episode she shares how she photographs curriculum books to auto-generate lesson plans, builds custom apps with zero prior terminal experience, partitions sensitive data across machines, and bridges the digital and physical world by inventorying every toy and supply in her house.

Detailed workflow walkthroughs from this episode:

• How I AI: Jesse Genet’s 5 OpenClaw Agents for Homeschooling, App Building, and Physical Inventories: https://www.chatprd.ai/how-i-ai/jesse-genets-5-openclaw-agents-for-homeschooling-app-building-and-physical-inventories

• Automate Homeschool Lesson Planning and Material Creation with an AI Agent: https://www.chatprd.ai/how-i-ai/workflows/automate-homeschool-lesson-planning-and-material-creation-with-an-ai-agent

• Build a Custom ‘Slop-Free’ Kids’ TV App Without Coding Experience: https://www.chatprd.ai/how-i-ai/workflows/build-a-custom-slop-free-kids-tv-app-without-coding-experience

• Create an AI-Powered Inventory of Your Physical Items: https://www.chatprd.ai/how-i-ai/workflows/create-an-ai-powered-inventory-of-your-physical-items

Biggest takeaways:

  1. Treat your AI agent like a new hire, not an extension of yourself. Jesse’s entire agent management philosophy comes from her experience hiring employees. She gives agents their own identities, separate data access, and communication channels—never full access to her email or accounts. Progressive trust is the model: start limited, expand as the agent proves reliable.

  2. Physical partitioning is a real security strategy. Running each agent on its own Mac Mini sounds extreme, but it solves a real problem: preventing one agent from accidentally leaking sensitive data through another agent’s communication channel. The finance agent can read bank statements but can’t text anyone. The scheduling agent can text, but has no financial data. This is a practical framework anyone managing multiple agents should think through.

  3. Photos are the most underrated input for AI agents. Jesse’s core workflow is shockingly simple: take a photo, send it to the agent, get structured output. She photographs lesson activities, book pages, physical supplies, and curriculum materials. The agent handles all the heavy lifting of logging, categorizing, and connecting that information. No typing, no structured input—just photos.

  4. You don’t need to be technical to build real software with a coding agent. Jesse had never opened a terminal before six months ago. With Cole, her coding agent, she built a custom kids’ TV app, iterated over four days, and deployed it to a Google TV Streamer. Her approach: describe what you want, push back when the agent says something isn’t possible, and keep going.

  5. Inventory your physical world so AI can reach into it. One of Jesse’s most powerful moves was photographing all her educational supplies and having Sylvie build an inventory. Now when she asks for a lesson plan, the agent can say, “Also, pull out the tracing board from the cupboard.” This bridges the gap between the digital agent and the physical world in a way that’s immediately useful.

  6. Use “decision files” to prevent agents from relitigating settled questions. Jesse maintains a decisions file in Obsidian that each agent knows about. When she makes a final call, she flags it, and the agent knows not to revisit it. This is a simple, powerful pattern for anyone dealing with agents that keep second-guessing or re-asking about things you’ve already resolved.

▶️ Listen now on YouTube | Spotify | Apple Podcasts

How Coinbase scaled AI to 1,000+ engineers | Chintan Turakhia

Brought to you by:

  • WorkOS—Make your app enterprise-ready today

  • Rovo—AI that knows your business

Chintan Turakhia leads engineering at Coinbase, where he’s helped turn a 1,000-plus-person org into an AI-native team. In this episode, Chintan shares how Coinbase got 100 engineers to ship 75 PRs in 15 minutes, cut PR review time from 150 hours to 15, and built internal agents that turn user feedback into shipped features in minutes. Claire and Chintan dive into the “speed run” tactic that broke through skepticism, how to identify and replicate AI power users, and why the best engineering leaders are getting more hands-on with code in the AI era.

Detailed workflow walkthroughs from this episode:

• How I AI: Chintan Turakhia’s Playbook for AI Adoption at Coinbase: https://www.chatprd.ai/how-i-ai/playbook-for-ai-engineering-adoption-at-coinbase

• Use ChatGPT to Become Your Own Personal Wine Sommelier: https://www.chatprd.ai/how-i-ai/workflows/use-chatgpt-to-become-your-own-personal-wine-sommelier

• Build an Automated User Feedback to Pull Request Pipeline: https://www.chatprd.ai/how-i-ai/workflows/build-an-automated-user-feedback-to-pull-request-pipeline

• Create a Data-Driven AI Adoption Playbook Using Cursor: https://www.chatprd.ai/how-i-ai/workflows/create-a-data-driven-ai-adoption-playbook-using-cursor

Biggest takeaways:

  1. Organize “speed runs” to kickstart widespread AI adoption. Coinbase gathered 100 engineers for a 15-minute session where everyone used AI tools to push 75 PRs simultaneously. The high success rate of merged PRs proved AI’s effectiveness at scale and transformed the team’s mindset about what they could accomplish.

  2. Show, don’t tell, when driving AI adoption in engineering teams. Chintan spent months personally using Cursor daily, discovering use cases and techniques before asking his team to adopt it. By tackling real bugs and showing concrete wins, he built credibility that made adoption natural rather than forced.

  3. Focus AI adoption on eliminating “soul-sucking” work first. Rather than tackling complex engineering challenges, Chintan targeted the tedious tasks engineers hate: writing unit tests, fixing linting issues, and managing Git commands. Engineers naturally want to build better things faster, and removing friction from their workflow created immediate buy-in.

  4. Create public channels to showcase AI wins. Coinbase established a “Cursor Wins” Slack channel where engineers shared their successes. This visibility created organic FOMO and peer learning as engineers saw colleagues shipping more code with less effort.

  5. Measure the entire feedback-to-feature cycle time, not just lines of code. Coinbase reduced PR review times from 150 hours to 15 hours and built systems to capture user feedback and convert it to shipped features in minutes rather than weeks. This end-to-end acceleration creates a virtuous cycle where faster shipping leads to more user feedback and continuous improvement.

  6. Engineering leaders should be writing more code, not less. Chintan’s calendar is now nearly empty, as AI has eliminated coordination overhead and meetings. Instead, he spends more time writing code, fixing bugs, and exploring technical approaches.

  7. Use AI to analyze AI adoption patterns. Chintan used Cursor itself to analyze Cursor usage data, identifying natural user cohorts from inactive to super-users. This meta-application of AI allowed him to create targeted guidance for each segment, helping engineers progress from light usage to power usage. The analysis revealed that agent-heavy users were 16x more productive with AI than other users, providing concrete data to drive further adoption.

▶️ Listen now on YouTube | Spotify | Apple Podcasts


If you’re enjoying these episodes, reply and let me know what you’d love to learn more about: AI workflows, hiring, growth, product strategy—anything.

Catch you next week,
Lenny

P.S. Want every new episode delivered the moment it drops? Hit “Follow” on your favorite podcast app.

How Coinbase scaled AI to 1,000+ engineers | Chintan Turakhia

2026-03-02 21:03:27

Chintan Turakhia is Senior Director of Engineering at Coinbase, where he’s led the transformation of a 1,000-plus-engineer organization to embrace AI tools at scale. When tasked with rewriting Coinbase’s self-custody wallet into a consumer social app in just six to nine months, Chintan turned to AI as a force multiplier. His team has achieved remarkable efficiency gains, including reducing PR review times from 150 hours to just 15 hours, and dramatically compressing the cycle from user feedback to shipped features.

Listen or watch on YouTube, Spotify, or Apple Podcasts

What you’ll learn:

  1. How to drive AI adoption in large, established engineering organizations

  2. The “speed run” technique that got 100 engineers to push 70 PRs in 15 minutes

  3. How to identify and replicate the behaviors of AI power users

  4. Why engineering leaders must get hands-on with AI tools to drive adoption

  5. How to build custom AI agents that integrate with your existing workflows

  6. The metrics that actually matter when measuring AI’s impact on engineering velocity

  7. How to compress the cycle from user feedback to shipped features


Brought to you by:

WorkOS—Make your app enterprise-ready today

Rovo—AI that knows your business

In this episode, we cover:

(00:00) Introduction to Chintan

(02:38) How Coinbase approached rewriting their app with AI assistance

(08:00) The importance of leadership conviction and hands-on demonstration

(10:30) The “PR speed run” technique that transformed team adoption

(17:57) Measuring success

(19:20) Demo: Real-time feedback-to-feature implementation

(23:14) Using Cursor to analyze AI adoption patterns

(33:15) Quick recap and appreciation

(36:00) Demo: Building a live feedback capture system using AI transcription

(40:50) Using custom Slack bots to automate engineering workflows

(47:10) Advice for driving AI adoption within your organization

(50:00) Personal use case: AI for wine selection based on taste preferences

(55:23) Lightning round and final thoughts

Tools referenced:

• Cursor: https://cursor.sh/

• Linear: https://linear.app/

• Slack: https://slack.com/

• ChatGPT: https://chat.openai.com/

• Claude: https://claude.ai/

• GitHub Copilot: https://github.com/features/copilot

Other references:

• Coinbase: https://www.coinbase.com/

• React Native: https://reactnative.dev/

• How custom GPTs can make you a better manager | Hilary Gridley (Head of Core Product at Whoop): https://www.lennysnewsletter.com/p/how-custom-gpts-can-make-you-a-better-manager

Where to find Chintan Turakhia:

LinkedIn: https://www.linkedin.com/in/chintanturakhia/

X: https://x.com/chintanturakhia

Base App (formerly Coinbase Wallet): https://base.app/

Where to find Claire Vo:

ChatPRD: https://www.chatprd.ai/

Website: https://clairevo.com/

LinkedIn: https://www.linkedin.com/in/clairevo/

X: https://x.com/clairevo

Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email [email protected].

The design process is dead. Here’s what’s replacing it. | Jenny Wen (head of design at Claude)

2026-03-01 21:31:18

Jenny Wen leads design for Claude at Anthropic. Prior to this, she was Director of Design at Figma, where she led the teams behind FigJam and Slides. Before that, she was a designer at Dropbox, Square, and Shopify.

We discuss:

  1. Why the classic discovery → mock → iterate design process is becoming obsolete

  2. What a day in the life of a designer at Anthropic looks like, including her AI tool stack

  3. Whether AI will eventually surpass humans in taste and judgment

  4. Why Jenny left a director role at Figma to return to IC work at Anthropic

  5. The three archetypes Jenny is hiring for now

  6. Why chatbot interfaces may be more durable than most people expect


Brought to you by:

Mercury—Radically different banking

Orkes—The enterprise platform for reliable applications and agentic workflows

Omni—AI analytics your customers can trust

Where to find Jenny Wen:

• X: https://x.com/jenny_wen

• LinkedIn: https://www.linkedin.com/in/jennywen

• Substack: https://jennywen.substack.com

• Website: https://jennywen.ca

Referenced:

• Figma: https://www.figma.com

• Anthropic: https://www.anthropic.com

• v0: https://v0.app

• Navigating a Design Career with Jenny Wen | Figma at Waterloo: https://www.youtube.com/watch?v=OHcBPMh2ivk

• Claude Cowork: https://claude.com/product/cowork

• Use Claude Code in VS Code: https://code.claude.com/docs/en/vs-code

• Claude Code in Slack: https://code.claude.com/docs/en/slack

• Lex Fridman’s website: https://lexfridman.com

• Head of Claude Code: What happens after coding is solved | Boris Cherny: https://www.lennysnewsletter.com/p/head-of-claude-code-what-happens

• OpenClaw: https://openclaw.ai

• OpenAI’s CPO on how AI changes must-have skills, moats, coding, startup playbooks, more | Kevin Weil (CPO at OpenAI, ex-Instagram, Twitter): https://www.lennysnewsletter.com/p/kevin-weil-open-ai

• Marc Andreessen: The real AI boom hasn’t even started yet: https://www.lennysnewsletter.com/p/marc-andreessen-the-real-ai-boom

• Socratica: https://www.socratica.info

• Anthropic’s CPO on what comes next | Mike Krieger (co-founder of Instagram): https://www.lennysnewsletter.com/p/anthropics-cpo-heres-what-comes-next

• Radical Candor: From theory to practice with author Kim Scott: https://www.lennysnewsletter.com/p/radical-candor-from-theory-to-practice

• Evan Tana’s ‘legibility matrix’ on X: https://x.com/evantana/status/1927404374252269667

• How to spot a top 1% startup early: https://www.lennysnewsletter.com/p/how-to-spot-a-top-1-startup-early

• Palantir: https://www.palantir.com

• Stripe: https://stripe.com

• Linear: https://linear.app

• Notion: https://www.notion.com

• Julie Zhuo’s website: https://www.juliezhuo.com

Sentimental Value: https://www.imdb.com/title/tt27714581

The Pitt on Prime Video: https://www.amazon.com/The-Pitt-Season-1/dp/B0DNRR8QWD

• Noah Wyle: https://en.wikipedia.org/wiki/Noah_Wyle

ER on Prime Video: https://www.amazon.com/gp/video/detail/B0FWZSDYRP

• Retro: https://retro.app

• Granola: https://www.granola.ai

Recommended books:

Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity: https://www.amazon.com/Radical-Candor-Kick-Ass-Without-Humanity/dp/1250103509

The Power Broker: Robert Moses and the Fall of New York: https://www.amazon.com/Power-Broker-Robert-Moses-Fall/dp/0394480767

Insomniac City: New York, Oliver Sacks, and Me: https://www.amazon.com/Insomniac-City-New-York-Oliver/dp/162040494X


Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email [email protected].

Lenny may be an investor in the companies discussed.


My biggest takeaways from this conversation:

Read more

🧠 Community Wisdom: Building your tech stack from scratch, surviving painful product demos, managing LLM credit costs, resources for new designers, and more

2026-03-01 01:16:48

👋 Hello and welcome to this week’s edition of ✨ Community Wisdom ✨ a subscriber-only email, delivered every Saturday, highlighting the most helpful conversations in our members-only Slack community.

Read more