The design process is dead. Here’s what’s replacing it. | Jenny Wen (head of design at Claude)
Description
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: https://mercury.com/ Orkes—The enterprise platform for reliable applications and agentic workflows: https://www.orkes.io/ Omni—AI analytics your customers can trust: https://omni.co/lenny *Episode transcript:* https://www.lennysnewsletter.com/p/the-design-process-is-dead *Archive of all Lenny's Podcast transcripts:* https://www.dropbox.com/scl/fo/yxi4s2w998p1gvtpu4193/AMdNPR8AOw0lMklwtnC0TrQ?rlkey=j06x0nipoti519e0xgm23zsn9&st=ahz0fj11&dl=0 *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 *Where to find Lenny:* • Newsletter: https://www.lennysnewsletter.com • X: https://twitter.com/lennysan • LinkedIn: https://www.linkedin.com/in/lennyrachitsky/ *In this episode, we cover:* (00:00) Introduction to Jenny Wen (04:23) Why the traditional design process is dead (06:33) The two new types of design work (10:00) How widespread this shift will be (13:00) Day-to-day life as a designer at Anthropic (18:45) Jenny’s AI stack (20:03) Why Figma still matters for exploration (22:25) Advice for working with engineers (24:19) How to maintain craft, quality, and trust in the AI era (27:35) Will AI ever have “taste”? (31:38) The future of cha
Summary
Generated by gpt-5.6-terraAt-a-Glance
- Verdict: Watch fully
- Core thesis: AI-driven engineering velocity is collapsing the traditional design handoff process and turning designers into shorter-horizon product directors, embedded implementation partners, and curators of emerging agent-native experiences.
- Why it matters: The interview offers direct operating patterns from Anthropic for designing amid agentic development: rapidly shipping research previews, preserving coherence without bottlenecking engineers, using coded prototypes, and identifying valuable but initially unintelligible internal ideas.
- Best use: Use this as a playbook for restructuring product/design work around fast agent-assisted implementation, particularly for OpenClaw- or agent-oriented product teams where interface, workflow, and control-plane decisions are evolving faster than formal planning cycles.
Executive Summary
Jenny Wen argues that the canonical design process—extended discovery, divergence/convergence, polished mocks, and downstream handoff—is no longer an appropriate default when engineers can run multiple coding agents and turn ideas into working software immediately. Design is splitting into two modes: execution support, where designers pair with engineers, explain principles, maintain coherence, and directly polish code; and directional work, where they create lightweight three-to-six-month visions or prototypes rather than elaborate multi-year design narratives.
Her central operating principle is not to slow high-velocity building with design gates. Teams should release valuable but unfinished products as explicitly labeled research previews, then earn user trust through visible responsiveness and rapid iteration. She uses Claude Cowork as the example: the external release was finalized in roughly 10 days, but rested on a longer history of internal explorations, interaction experiments, and prior prototypes. The lesson is that apparent overnight shipping usually reflects accumulated option-building followed by a compressed commitment phase.
Wen does not claim that craft, research, or Figma disappear. Research and mockups continue, but their share of a designer's time falls materially: from roughly 60–70% in mocking/prototyping a few years ago to 30–40%, with another 30–40% now spent jamming and pairing with engineers, plus direct implementation. Figma remains useful for divergent exploration and fine-grained visual alternatives because current coding agents tend to work linearly and over-invest in one route.
For the longer-term AI question, she expects models to improve substantially at taste and judgment, not merely coding. Yet humans remain accountable for deciding what should be built, resolving organizational disagreements, setting direction, and accepting responsibility for outcomes. Her hiring and management advice follows from this: favor adaptable multi-skilled “block-shaped” generalists, unusually deep specialists, and high-agency early-career builders; require managers to stay close to hands-on work; and treat seemingly low-leverage details such as dogfooding, bug filing, and personal team gestures as potentially high-leverage leadership signals.
Key Takeaways
- Claim: Traditional sequential design process and design-as-gatekeeping are being displaced by continuous, embedded collaboration with agent-accelerated engineering. | Evidence: Wen says engineers can now spin up “seven Claudes” and make scrappy versions of ideas immediately; she advises designers not to block that flow. Her own work now includes whiteboarding, reviewing working builds, explaining rationale, and polishing implementation directly in code. | Implication: Ken should design agent-product workflows so product/design is an active part of the build loop—providing principles, constraints, and final-mile quality control—rather than a document-producing approval function. | Caveat: She does not argue for eliminating research, prototyping, or mocks; the change is in their relative weight and sequencing, not their complete removal.
- Claim: Design work is stratifying into execution support and near-term direction-setting, while long-range product visions are becoming less reliable. | Evidence: Wen distinguishes supporting implementation from creating vision. She says former two-, five-, or ten-year design visions are increasingly replaced by three-to-six-month directional prototypes because model capabilities and market conditions are changing too quickly. | Implication: For agent systems, favor a rolling directional thesis with concrete prototypes and revisable assumptions over highly polished long-range roadmaps that lock in premature interface or architecture choices. | Caveat: The shorter planning horizon is especially acute at frontier AI labs; adoption elsewhere may lag due to entrenched processes and organizational resistance.
- Claim: Early releases can preserve—or even build—trust when the team clearly frames the product as a preview and visibly responds at high speed. | Evidence: Claude Cowork was released as a “research preview,” with known flaws, because Anthropic believed its existing value outweighed its limitations. Wen says the trust failure is not releasing early; it is releasing early and then failing to improve, acknowledge feedback, or demonstrate momentum. | Implication: When shipping agent features with uncertain UX or reliability, explicitly scope the promise, instrument feedback, publish improvements quickly, and avoid treating a public preview as a one-way launch event. | Caveat: This approach requires a genuine commitment and capacity to iterate after launch; “preview” labeling cannot compensate for neglect or a weak underlying value proposition.
- Claim: Mocking and research remain useful, but designers need a broader toolchain that includes coded prototyping and direct implementation. | Evidence: Wen estimates mockups/prototypes fell from 60–70% of her work to 30–40%; roughly 30–40% is now direct pairing with engineers, with additional time implementing polish. She uses Claude Code in VS Code for front-end changes and can invoke Claude remotely through Slack for small fixes such as an incorrect icon. | Implication: Treat design tooling as complementary: use canvases for divergent option generation and code/agents for convergent validation, implementation, and production polish. | Caveat: She still uses Figma because code agents currently encourage linear iteration, whereas Figma is better for exploring eight to ten competing directions and micro-level typography or interaction variants.
- Claim: The durable human role is shifting from producing artifacts to accountable decision-making about priorities, tradeoffs, and what matters. | Evidence: Wen expects AI to become better at taste, judgment, and design, but argues that the difficult part of software is often disagreement over what belongs in a feature rather than writing it. Even when Claude writes code, an engineer remains accountable for whether it works and belongs in the product. | Implication: Ken should concentrate human oversight in decision rights, evaluation criteria, accountability, and conflict resolution—not assume aesthetic judgment alone is a lasting defensible human function. | Caveat: She frames this as the current state rather than a permanent moat; she explicitly allows that models may eventually take on more of this judgment layer.
- Claim: Designers should act like internal venture investors by finding “illegible” prototypes with real energy and translating them into understandable products. | Evidence: Using Evan Tana’s legibility framework, Wen describes scanning internal work for ideas that seem confusing or frontier but attract strong interest. An internal dense “Claude Studio” prototype was initially hard to understand, yet its useful elements—Claude’s plans, to-dos, context, files, and skills—helped inform Cowork and the skills framework. | Implication: In an agent portfolio, monitor informal prototypes and anomalous internal adoption, then extract the underlying primitive or workflow rather than judging concepts solely by the polish or clarity of their first interface. | Caveat: An unintelligible idea is not automatically a good idea; the signal is unexplained user or builder energy around it, followed by deeper investigation.
- Claim: The most valuable design hires and managers are adaptable practitioners with direct technical and product proximity, not pure process custodians. | Evidence: Wen’s three preferred talent archetypes are “block-shaped” strong generalists with several high-level skills, deep specialists in the top tier of a craft or technical domain, and high-agency “craft new grads” who build constantly without entrenched rituals. She believes future managers must combine direction-setting with people leadership and should periodically operate as ICs, similar to engineering-manager rotations. | Implication: Evaluate team members on their ability to build, learn tools, articulate principles, and operate across boundaries; require design leadership to retain direct exposure to agent-enabled delivery rather than manage through legacy rituals alone. | Caveat: These are hiring preferences for a fast-moving frontier setting, where seniority alone may not map cleanly to current capability.
Detailed Brief
Cowork as a product-development case study
- Claims: The public form of Cowork emerged from many prior internal explorations rather than a single ten-day invention.; The team used release pressure to turn existing interaction fragments into an externally testable product, accepting that it was not necessarily the final or ideal form factor.; Wen sees Cowork evolving toward a shared task surface: a place where users see what Claude is working on, what needs their attention, and how tasks progress across surfaces.
- Evidence: The final externalization phase was approximately 10 days, but internal work had already explored agent harnesses, task-list formats, multiple-choice question interfaces, use-case education, and output previews.; The homepage was being iterated to present tasks Claude can perform and the work Claude is actively doing, including a randomizer for task ideas.; Wen describes one favored use case as giving Cowork an unstructured folder of material and having it turn that “garbage” into a useful artifact.
- Caveats: The conversation does not provide adoption, retention, quality, or business-performance data for Cowork.; Wen repeatedly frames the current Cowork interface as provisional and still under active discovery.
- Implications: Separate the visible shipping timeline from the hidden exploration timeline when assessing AI-product velocity claims.; For computer-use agents, task state, plans, context, files, and requests for user intervention are likely first-class UX primitives rather than secondary implementation details.
Management and team-culture operating lessons
- Claims: Wen rejects a simplistic distinction between high- and low-leverage managerial work: personally doing nitty-gritty product and culture work can create leverage because of the signal and context it produces.; A healthy team can exhibit light roasting and informality, but only when it rests on psychological safety, trust, and clearly maintained standards.; The desired management balance resembles radical candor: durable care and safety alongside direct challenge and high expectations.
- Evidence: Examples of seemingly low-leverage but valuable leadership behavior include senior leaders dogfooding deeply, filing bugs with logs, spending time with engineers on details, and personally making an anniversary card rather than delegating it.; Wen uses team members imitating her recurring critique phrase—“What are next steps?”—as a sign they are not afraid of her.; She compares her leadership stance to a “tough parent”: team members should know she will not fire them arbitrarily, but also that she is committed to strong work.
- Caveats: Roasting is presented as an emergent diagnostic of comfort, not a practice to mandate; forced informality can create exclusion rather than safety.; Personal involvement in details only creates leverage when it informs direction, raises quality, or demonstrates credible commitment—not when it becomes micromanagement.
- Implications: Use leadership participation in product testing and operational details to close the context gap created by autonomous agents and rapid shipping.; Assess culture by whether people can safely challenge leaders and receive high-standard feedback, not by whether a team appears casually friendly.
Notable Concepts & Terms
- Two modes of design work: Wen’s split between embedded implementation support and short-horizon vision-setting; it is her replacement for a linear design-to-handoff process.
- Research preview: A deliberate release contract: ship something materially useful before it is fully polished, disclose limitations, and prove trustworthiness through rapid feedback-driven improvement.
- Build trust through speed: Trust comes from users seeing that their feedback is heard and that a product visibly improves, rather than from delaying every release until it seems complete.
- Block-shaped generalist: An extension of the T-shaped person: someone strong across multiple distinct skills, enabling them to flex among design, product, technical, and implementation work.
- Craft new grad: An early-career candidate who is unusually capable, humble, technically curious, and prolific in making real things; Wen considers this under-hired profile especially suited to fast-changing work.
- Legibility framework: Evan Tana’s two-by-two for judging founders and ideas as legible or illegible; Wen repurposes it to identify confusing but energetically promising internal prototypes that design can translate into usable products.
- Claude Studio: An internal dense agent interface that initially looked confusing but helped surface useful Cowork primitives such as plans, to-dos, context, file visibility, and skills.
- Shared to-do list with Claude: Wen’s emerging UX framing for Cowork: a collaborative task surface showing autonomous agent work, user dependencies, and progress rather than only a chat transcript.
Operator Notes / Why Ken Should Care
- Adopt a release rubric for agent features: minimum user value, explicit preview limitations, feedback intake owner, response SLA, and a public or customer-visible iteration cadence.
- Require each product/design lead to maintain a direct weekly build loop with engineering or agents—reviewing working artifacts, editing code or prompts where appropriate, and extracting reusable design principles.
- Create a lightweight internal “illegible ideas” review: identify prototypes with unexplained enthusiasm or repeat use, document the underlying user/job signal, and test simpler interfaces around the core primitive.
- For agent-control UX, prototype task plans, live status, context/files accessed, intervention requests, and approvals as first-class components; do not rely only on conversational transcript history.
- Update hiring screens to distinguish process fluency from demonstrated agency: request working artifacts, tool experimentation, cross-functional depth, and examples of translating ambiguous concepts into products.
- Audit whether managers are sufficiently close to the current agent-enabled workflow; use hands-on rotations or scoped IC ownership before asking them to set process or staffing policy.
Source/Metadata
- Title: The design process is dead. Here’s what’s replacing it. | Jenny Wen (head of design at Claude)
- Transcript words: 18843
- Duration seconds: 4645
- Timestamp note: No timestamps or chapter markers were provided in the transcript.
Transcript
This design process that designers have been taught, we treat as gospel. That's dead. You as a designer actually do not have the time to make these beautiful mocks anymore. A big part of the design role now is helping engineers and teams execute, not just telling them, here's the design. A few years ago, 60 to 70% of it was mocking and prototyping. But now I feel the mocking-up part of it is 30 to 40%. You're better off not blocking that, letting them cook. It's not just designers who are feeling, oh yeah, we have to keep up with engineers. I think even engineers are like, how do we keep up with ourselves? How to keep up with all our agents. There are seven agents who are constantly running. The result of engineering changing a bunch is that design is forced to change. We used to go off and make this two-year, five-year, ten-year vision even. Now it becomes a vision that's three to six months out and isn't necessarily creating this beautiful depth. It's sometimes just creating a prototype that points people in the right direction. Boris on the podcast recently was saying Cloud Code is now helping him come up with ideas. We'll get better at taste and judgment and design. We might be holding on to that a little bit too much. Where will human brains continue to be valuable? At the end of the day, someone has to decide what is actually going to get built and what actually matters. Someone still needs to be accountable for the decision. What do you now look for when you're hiring designers? There's probably three archetypes of folks that are really interesting to me right now. Today's guest is Jenny Nguyen. Jenny was head of design for Cloud, is now leading design for Cloud Cowork. Prior to that, she was director of design at Figma, where she led the design teams behind FigJam and Slides. She was also a designer at Dropbox and Square and Shopify. And what I love about this conversation is that Jenny is living in the future of where design as a profession is heading. And she is here to give us a glimpse into what that looks like and how much things are going to be changing for designers. It is pretty wild and extremely interesting. A huge thank you to Know11 and Emily Lynn Hasham for suggesting topics and questions for this conversation. Don't forget to check out Lenny's Product Pass.com for an incredible set of deals available exclusively to Lenny's newsletter subscribers. Let's get into it after a short word from our wonderful sponsors. This episode is brought to you by Mercury, radically different banking loved by over 300,000 entrepreneurs, including me. I switched to Mercury from Chase over a year ago, and it is such a profoundly better experience. It's like an actual product person built a bank versus a banking person building a product. It is fast. It's elegant. It is super easy to set wires, to track my spending, to set up triggers, to move money around when accounts get low. We moved all of our invoicing to Mercury, and it is such a smoother experience than anything else we've tried. It's also really easy to grant people on your team just the right amount of access to help take work off your plate. It's free to get started. No in-person visits. No minimum balances. The product also flexes to all sizes of company, from startups to large enterprises. Just visit Mercury.com to learn more and apply online in minutes. Mercury is a fintech company, not an FDIC-insured bank. Banking services provided through Choice Financial Group and Column and any members FDIC. This episode is brought to you by Orcus, the company behind Open Source Conductor, the orchestration platform powering modern enterprise applications. Modern systems are built on microservices, APIs, and event-driven architectures. But legacy automation tools can't keep up. Siloed, low-code platforms, outdated process management, and disconnected API tooling break down under real-world scale and constant change. Orcus Conductor provides a production-grade orchestration layer for coordinating microservices, APIs, data pipelines, human tasks, and agentic workflows with deterministic control flow, retries, observability, and governance. Built for enterprise scale, Orcus supports visual and code-first development with built-in compliance and reliability. Through a built-in MCP gateway, AI agents handle reasoning and decision-making while safely accessing existing APIs and internal systems as MCP tools. This enables agents to operate across enterprise environments and scale from demos to production, orchestrating systems, agents, and humans together to deliver smarter outcomes faster. Learn more at orcus.io slash Lenny. That's O-R-K-E-S dot I-O slash Lenny. Lenny, thank you so much for being here, and welcome to the podcast. Yeah, excited to be here. I've been looking forward to this conversation because I spent a lot of time on this podcast talking about the future of software engineering, how much that role is changing, the role of product management, how much that role is changing. I haven't spent a lot of time on how design is changing. Clearly, it is also changing in a really big way. And you have such a front-row seat to where things are heading. I also know you have a lot of very strong opinions about where things are heading. So there's a lot of stuff I want to talk about. I want to just start with this broad question. How is the design process changing with the rise of AI? It's changing a lot. I think it's still also got a long way to go in terms of the way it's changing. I think we've actually seen engineering change a lot more in the past little while than design actually has. But I think the result of engineering changing a bunch is that design is forced to change. And so I think some context around this is I did a talk at a conference in Berlin a few months ago in September. And I called it, don't trust the design process, where I just said, hey, you know this design process that designers have been taught where you go off and do a bunch of research and discovery. And then you diverge, you converge, diverge, converge. And it's this process that we treated as gospel and tried so hard to preserve. And we were like, trust the process. That's dead. I think it was dying before the age of AI. But given now that engineers can go off and spin off their seven clods, I think as designers, we really have to let go of that process. And I think that's the big thing that's changing. But I think even in the past three to four months since I did that talk, that talk actually starts to feel pretty outdated to me, which is a little embarrassing. But especially with the big shift of Opus 4-6 and a bunch of folks really discovering and using cloud code over the holiday break, I think we're seeing this force to change our process happen even more. The way I see it now is there are basically two types of design work. And design work is becoming really stratified in this new world. So there's the first one, which is really just supporting the implementation and execution. So this is the one where engineers are using their seven clods to create all these features. And anybody can put an idea out there. And you can talk about an idea, and somebody, usually actually an engineer, because they're still better at implementing this stuff than we are, will just make a scrappy version of it. And you can try it out. And you as a designer actually do not have the time to make these beautiful mocks anymore or to lead in this way. And then I think there's the second kind of work that feels also really important, which is creating the sort of vision or direction for things. This one feels like the hardest to make time for. And it's one that we still did before. But I think the shape of it is very much changing. Because I think we used to go off and say, we're going to do this design vision. We're going to go off and make this two-year, five-year, whatever, ten-year vision even. And we're going to point us toward something. But the way that the technology is changing now, we actually don't know. We don't know what's going to happen in two years. There's too much changing. And it usually becomes a vision that's three to six months out and isn't necessarily something that is creating this beautiful deck that's beautifully story-told. It's sometimes just creating a prototype that points people in the right direction. And I think this kind of work is still really important in this world. Because in a world where people can spin off their seven clods, make whatever features they want in any kind of direction or implementation, you need to point them toward something in order to make sure that we're all making something that makes sense together and is also done in a way where it's efficient, right? And we're going to point us towards something. But the way that the technology is changing now, we actually don't know. We don't know what's going to happen in two years. There's too much changing. And it usually becomes a vision that's three to six months out. And isn't necessarily something that is creating this beautiful deck that's beautifully story told. It's sometimes just creating a prototype that points people in the right direction. And I think this kind of work is still really important in this world. Because in a world where people can spin off their seven clods, make whatever features they want in any kind of direction or implementation, you need to point them towards something in order to make sure that we're all making something that makes sense together and is also done in a way where it's efficient, right? If we're all working towards something that has one greater cause, it's much more efficient to do that than just random things. And so that's the big shift that I'm seeing. And I think I have opinions about it now. But ask me in three months and it might actually change even more. So what you're saying here is it's not you or the design field saying we need to change. It's engineering and the fact that you can build so quickly just forces the role of a designer to change. Because, as you said, engineers can just ship, ship, ship, ship, ship. And what you're finding here is you're better off not blocking that, letting them cook, as they say. And then there's this mode of helping them along as they ship, bring it together, make sure it all connects, guide them a little bit. Yeah, I think so. Yeah, I don't think there is one unifying voice that's saying, designers, we need to change right now. But there, yeah, there are the follow-on effects of engineering tooling really changing. I think we'll probably see design tooling change in this next year or so as well. But a lot of it right now is trailing that. And I think it's also really empowering for us, too, because as designers, we also now have access to a lot of these coding tools. And we can be a part of the process in a way where we're implementing stuff. I'm doing a lot of last-mile stuff where I'm implementing all the polish and working with engineers really closely to get the feature across the line. And also prototype stuff in actual code as opposed to relying on engineers to do that again. How true do you think this is at all companies, at, say, AI companies, non-AI companies? Someone may be hearing this. Okay, Anthropa, Claude, okay, they're at the bleeding edge, for one. Two, it's developer-y a little bit. But I think people might be feeling, okay, this is not going to happen at Salesforce. This is not going to happen at, I don't know, ServiceNow or whatever. So I guess, do you feel like this is where all teams are heading? Is it mostly AI, bleeding-edge companies? How widespread do you think the design process shift is going to be? So the talk that I did last year has really been the most resonant talk that I've done. And so I think it's something that people are starting to feel across the industry where they're like, oh, yeah, we can't do the old design process anymore. We are using tools like Claude Code and B0 and whatnot to start to spin up prototypes. And PMs are starting to spin up prototypes and stuff like that as well. So I think there's something there emerging. But the other interesting observation with that talk, too, was there was actually also a decent amount of backlash. People clearly have invested their entire careers in learning, teaching, and using this really stable design process. And I think there was a lot of discrediting, like, oh, yeah, we can't do without discovery. We can't do without these pieces of process. So I think there is still a piece of the industry that is not quite there yet in terms of this way of working, if that makes sense. Yeah. Yeah. Yeah. And a big part of this is, you could argue, the question is, what leads to the best, most successful products in companies? And you could argue it's spending time doing discoveries, research, mocks, iterating, beta testing. Or it could be just engineers ship stuff that's okay, not amazing, good enough. We learn, iterate, build, iterate. Is your sense that that second path is, not only is that just what everyone's doing, but that actually leads to the better product at this point? I think you have to choose and use your discussion. I think that's a good question. I think that's a good question. I think that's a good question. But that's a good question. But that's a good question. But that's a good question. But that's a good question. But that's a good question. But that's a good question. But that's a good question. But that's a good question. But that's a good question. But that's a good question. But that's a good question. But that's a good question. But that's a good question. way, which is where cohort came from and probably even cloud code at the beginning. And so, what's it just like to be a designer at Anthropic? Give us a day in the life of working at Anthropic at the center of the storm. A good amount of time at Anthropic is actually just catching up on what people, what's happening at the company. I think this is the company where I've worked at a few other companies around this size where I think there's just a lot of information and a lot of things going on, but I feel really compelled to keep up with it. There's stuff like model developments on the research side. And then at any given time, there are just so many different teams prototyping and trying different ideas out. And there's a bunch of different code names and stuff like that. And a lot of time I'm just trying to navigate and figure out what those projects are, because I think I'm just trying to spot and see, like, hey, what's coming up ahead for me? Because there's stuff from both the research team, but also some of our labs teams that are closer to research and trying out and prototyping stuff. And then there's stuff I want to try out. We have a bunch of prototypes and products internally that we can use, and I am just curious and I want to try those things out. And then I think there's also a lot of folks who internally have a lot of insights and opinions on where the industry is going. And some of those are just really interesting to read because a lot of these are philosophical debates or directions of the company and stuff like that. And yeah, I feel like I just want to keep up with these things. Whereas I think at a normal company, I'm like, it's fine. This is stuff that's happening outside of my reach. I don't really care as much, where here I think that it's both the volume and the kinds of things that are happening that I'm really interested in keeping up with. And then aside from that sort of keep-up, that's not a huge part of my job, but I do think it's a really interesting part of it. Well, it connects to the point you made earlier. A big part of the design role now is helping engineers and teams execute, not just telling them here's the mock, here's the design. It's helping them stay on track, helping them connect ideas, create a cohesive experience as it's happening. So that makes sense. Yeah. Yeah. Yeah. And I think part of it is just curiosity. It feels like I have this front-row seat to so much happening in the industry. Yeah. And so a lot of it is like, yeah, our Slack is a gold mine. I'm just excited to read through the things that people are working on and they're saying. I never thought about how there's already so much AI news to keep track of as a regular person. And then actually seeing what's happening inside a lab is a whole new set of stuff. Yeah. Feeds to watch. Yeah. I don't know. I think that is the best AI news, probably internally. If you're ever at one of these companies, in the Slack. Damn. Yeah. Yeah. The problem keeps getting harder. I'm just keeping track of what's going on. Okay. So, okay. So that makes sense. Yeah. Yeah. Yeah. And I think part of it is just curiosity. It feels like I have this front-row seat to so much happening in the industry. Yeah. And so a lot of it is, yeah, our Slack is a gold mine. I'm just excited to read through the things that people are working on and they're saying. I never thought about how there's already so much AI news to keep track of as a regular person. And then actually seeing what's happening inside a lab is a whole new set of stuff. Yeah. Feeds to watch. Yeah. It's like, I don't know. I think that the best AI news is probably internally, if you're ever at one of these companies, in the Slack. Damn. Yeah. Yeah. The problem keeps getting harder. I'm just keeping track of what's going on. Okay. So that's part of the job. What else? There is still some of the traditional, let me think about what's happening in the future and let me make some designs for that. That's something that, for example, this week I've allotted some time to, where I'm like, okay, cool. We have been in a lot of execution mode for cowork. And now I want to set aside some time to think about, hey, what do the next three months look like? And where could that actually go, given where the market's at, where the models are at, and what could that be? Because I think it still really helps to visualize that and show that to the team and point everyone in the same direction. And then I also spend a bunch of my day just jamming on stuff with engineers. A lot of it is just conversation, or whiteboarding, or going through something that they built and giving them feedback on it and being a designer in that kind of way. We're really consulting. And then I spend a part of my day in code, polishing, implementing stuff. Sometimes what happens is an engineer and I have worked through something, and they've implemented a first version of it. And I just go in and polish it with them. And that's a really fun part of my job that I think didn't exist as much a few months ago. Are you still doing elements of the traditional design process? Prototyping, user research, panels, I dunno, just going out and in, the whole thing you described. Yeah, we're still doing all of that to some extent. We have a user researcher on the team who is putting together both traditional studies as well as surveys. And the whole team is reading those studies and that feedback. We are still prototyping stuff. I'm still mocking stuff up. I think I just have a wider set of tools now. And I think the proportion of time I spend doing each thing has changed. Got it. Okay. So that's a really interesting takeaway. It used to be that was a huge, I guess, what would be the pie chart of what your life was before, where it's traditional thinking, planning, prototyping, mocking, research, and then feedback and execution and out today. Yeah. I think as a designer a few years ago, I would say maybe 60 to 70% of it was mocking and prototyping stuff up, and then spending the last 20 or so, some of the last 20 or so, doing the jamming with engineers, consulting with them, and the last 10% maybe doing coordination meetings, et cetera. But now I feel like the mocking-up part of it is 30 to 40%. And then there's that other 30 to 40% there that is now jamming and pairing directly with engineers. And then there's a slice, I don't know how much I have left, but there's a slice of it that is now implementation as well. Yeah. Like actually building and shipping. Yeah. Amazing. So, following that thread, what's in your AI stack? As a designer, I know you're a manager and I want to talk about how you actually are IC also. What's in your AI stack? What tools are you using in your role? What is in my AI stack? Well, we're going to throw up. Of course. So we're going deep on the cloud stack. Yeah. I am using, obviously, chats, cloud chat, but increasingly more and more cloud co-work. I've basically shifted all of my chat use cases over to co-work because I've been finding that it is better at these longer-running tasks. And most of the things I was asking cloud for are these longer-running tasks. And then there's cloud code. Of course I use it mostly with VS Code in the IDE because I'm usually tweaking front-end stuff, and it helps to be able to see the code and then talk to cloud as well. I've been trying to actually use cloud code more remotely, through both mobile and through Slack as well. It's really fun for somebody to say, oh yeah, this one icon's off or something, and you just @mentioned cloud and cloud does it, and then you pick up the PR and it's done. That's been really, really fun too. And yeah, I think we're a fully cloud house here. So yes, that's basically my stack. Are you still using Figma as a designer? I am still using Figma, yes. Yes. Okay. I was waiting to hear. Okay, so Figma is still part of your life. Being a former Figma, is that what you all were called? Yeah. Yeah. Okay. So I know there's this big debate on Twitter, just like, is code the future of design? Do we need Figma anymore? Do we need a designer? What's your sense? Figma is still important? I mean, as a former Figma, maybe I'm biased in that way, but I think there is still, when I use Figma, I'm like, yes, this is what I should be using. And it still fills a very good gap for me. I think a lot of that is actually just exploring a lot of different options. I think that's a really important part of the design process, to be able to think about eight to 10 different ways to do something. I think the best design happens when you're able to throw a bunch of ideas at the wall and curate, and push yourself to come up with a bunch of these different directions. Right now, coding, or right now working with some of these coding tools, doesn't lend itself super well to that because it's super linear. You can super invest in one direction, and you just iterate a lot on them, for example. So Figma has been really great at exploring all these different options, and I think it's still going to exist that way to some extent. And then I think there are really fine visual and interaction details that are also really great to be able to try out in Figma. Again, it's a lot of different directions, but it's micro directions. It's being able to think about different typography or styles. Having those in a canvas where you can just explore that specifically is still so, so helpful and is not something that I always want to go directly to code in. It's interesting. You still use an IDE because in engineering it's clearly shifting to command lines, agents, IDs are moving to not be cool anymore. And it makes a lot of sense. You just want to edit some CSS things, some color stuff. And so I could see why not just telling the agent, hey, just come on, change this one hex value. Just changing it is so much easier. Yeah. It's really annoying to be like, can you change this to this class, when you can just go in and change it to a different class. So that's interesting. I wonder if IDEs now become useful for designers and PMs, and engineers have moved on. Yeah, maybe. Yeah. Okay. So a lot of your time you spend working with engineers, giving them feedback, nudging them in the right direction. There's a sense, I feel, of just let go. Don't feel like you need to be this gatekeeper. But there's this piece of, okay, help them move in a direction that is cohesive and is creating products we're proud of. A lot of designers, I think, are in this boat right now. And so I could see why not just telling the agent, "Hey, just come on, change this one hex value." Just changing it is so much easier. Yeah. It's really annoying to be like, "Can you change this to this class?" when you can just go in and change it to a different class. So that's interesting. I wonder if IDUs now become useful for designers and PMs and engineers that have moved on. Yeah, maybe. Yeah. Okay. So a lot of your time you spend working with engineers, giving them feedback, nudging them in the right direction. There's a sense, I feel, of just your advice is, "Let go. Don't feel like you need to be this gatekeeper," but there's this piece of, okay, help them move in a direction that is cohesive and is creating products we're proud of. A lot of designers, I think, are in this boat right now. I'm just like, "Oh my God, I can't keep up with all these engineers shipping stuff all day." What's something you learned about either how to help your engineers get better at design so that it just ends up being better, or just keeping on top of this and not going crazy? Whenever I do work with engineers on projects, and it's more on a consulting basis, I do try to explain why I'm thinking the way that I'm thinking to help them extract principles, as opposed to me just being like, "No, I don't think this would go here." It's like, "No, I think we should have a button here because not everybody realizes you can prompt this." And here's an example where it comes from research and whatnot. So I also try to point engineers to our design system and stuff like that in code, because right now Claude is writing a lot of the code, and it's not always picking up stuff in the design system and whatnot. So as much as I can equip them with stuff that they can use in the future without me, that's helpful. And then on your point of trying not to go crazy, I think it's hard. I think it's really hard right now. And I see this a lot from both engineers and designers, where now that we're capable of doing so much, we want to do more. So I think it's not just designers who are feeling like, "Oh yeah, we have to keep up with engineers." I think even engineers are like, "How do we keep up with ourselves right now?" So that's something I'm hearing a lot. So true. Oh man, how to keep up with all our agents, our seven agents we're constantly running. Yeah. Okay. So then as a designer, we're in this profession. Craft and great experience and quality and trust are such a core part of the job to help instill that in the products, because that, in theory, leads to really successful products and companies. How do you think about maintaining craft, quality, trust, as your products are just shipping a thousand times a day and you're not able to stay on top of them and there's no designer involved? It's not that there's no designer involved. It's more just like there's almost too much for one designer to handle. But with this, I think about where the features or products are in the cycle of adoption versus early preview. So for example, we sometimes will launch things and we will say, "Hey, this is a research preview. It's early. It's going to have a bunch of these flaws." And we caveat that a bunch. I think quad cowork is actually a good example of this, where we labeled it a research preview and we put it out there knowing that, hey, this is similar to our models. This is the worst it's ever going to be, but we're going to put it out there because we believe internally, we've tried it a bunch, and there's something really powerful here that some people will benefit from. It might not yet be the easiest to work with. It might not be the highest quality. It might have some issues with it. But we're going to put it out there because we believe the benefits outweigh the cons. I think that is okay to do, especially when there is something really valuable with the product already and it's worth putting out there. But I think the promise you have to make your users is like, "Hey, we're going to put it out there, but we're going to iterate. We're going to take your feedback and we're going to iterate and we're going to make it better." And you have to commit to that. You have to show that to the world. You have to respond to people's feedback, and you have to show that you are continuously shipping and improving it. Because I think the way that you really lose trust around quality and releasing something early is if you release it early and then nothing ever happens. That is something that degrades a brand. But whenever you put something out early, it's possible to do that and maintain the brand of your company. And I think that's something that we've been doing pretty well. And I think if there's anything anyone listening can take away from it, it's like, yeah, we're continuing to do that. And I think that is actually really fun for me as a designer because you put something out there and you actually learn, and you get feedback about it immediately, and you know what to do next. The way I've heard you describe this is building trust through speed. Yeah, for sure. It's building trust through speed, but also just making people feel like they've been heard and that we're fixing things based on what they're trying to use it for. And their feedback is actually appreciated and used. Yeah. It's clear when the labs launch stuff, and y'all are very good at this. Everyone on the team is tweeting and responding to tweets and comments, and then shipping, "Hey, we fixed this yesterday. This is happening." So there's a clear sense of this is just today, and we know this is broken, and we will fix it. And then because cloud code can code very quickly, the fixes come very fast. Okay. So another big question that people are asking, that I ask a lot on this podcast, is around what skills become valuable. And another way I've been thinking about it, Lex put it this way recently, is where will human brains continue to be valuable as AI gets smarter? So we've gone through this progression of tab completing segments of code to 100 percent of code is written by AI now. It's crazy. Now AI is reviewing its own code. Boris on the podcast recently was saying cloud code is now helping him come up with ideas and decide what to build, which is like, okay, wow. Look at it go. The whole product development process slowly gets eaten up by AI. So the question is just like, where will human brains still be useful, at least until we have superintelligence? Do you think AI is going to get very, very good at taste, judgment, design? I think it will get better at taste and judgment and design, yeah. I think we might be holding onto that a little bit too much and saying like, "Oh yeah, a designer or somebody will always know the best thing to ship or the best version of this." But I do think AI's sense of taste will get better. I think someone still has to decide what is actually going to get built and what actually matters. And when I think about people saying like, "Oh, AI is just going to build this software for us," a lot of the hard parts of building software are actually not building it. If you think about the hardest times that you've had at work, it's probably things like you and some other person disagreeing about what should go into this feature or what shouldn't go into this feature. And those things still feel like, yes, AI can weigh in, but it can't necessarily solve this dispute between you and somebody else. And so there is something about deciding what actually goes into the things we build, which I guess is taste in some way, but maybe not taste in the way we think about aesthetic taste or whatnot. There's some sort of judgment around what to do next. Just watching how quickly AI took over coding, which I think a year ago, definitely two years ago, most people were like, "I don't think so. I don't think AI will get this good." And the best engineers in the world trust it so much, they're not even looking at the code anymore. And those things still feel like, yes, AI can weigh in, but it can't necessarily solve this dispute between you and somebody else. And so there is something about deciding what actually goes into the things we build, which I guess is taste in some way, but maybe not taste in the way we think about aesthetic taste or whatnot. There's some judgment around what to do next. Just watching how quickly AI took over coding, which I think a year ago, definitely two years ago, most people were like, I don't think so. I don't think AI will get this good. And that the best engineers in the world trust it so much, they're not even looking at the code anymore. That's where we got. It just made me reevaluate all these assumptions I've had about, okay, AI will never be as good as really good PMs or designers at judging what is great and deciding what to build. But I'm just starting to think, I think it will get there. Even an example you shared, it could give these two people trying to make a decision, here's all of the data you need to make a decision, and here's why this is the right answer. Just press yes, press one, and I'll go ahead and build it. Yeah. So I think we're just, yeah, to your point, I think we undervalue just how good it'll get at this stuff. Okay. So your sense is it'll get better, but your sense is we'll still need awesome designers to be involved, awesome PMs to help make these decisions, and engineers, of course. Yeah. Yeah. I think someone will still have to decide, oh, we want to build this kind of product, or given what the AI is presenting us, someone still needs to be accountable for the decision. The same way that, even though Claude can write all this code for you today, it is still an engineer who's accountable for, does that code actually work? Does this actually make sense in the product? Yeah. So I think there's that decision-making and judgment layer, which feels like maybe one day we won't have to do that, but it still falls on us. Yeah. It does make sense. It makes me think about the radiology example where there's always the sense that AI is going to take over that field of radiology and tell you what is going on. But the human is mostly useful for signing off on the decision because someone needs to be liable if they're wrong. Which isn't the best job in the world, but that's a different game as hell versus code. Yeah. Okay. Another ongoing question in AI and design is just, it feels like chatbots and terminals are just, I don't think anyone expected this to be the lasting user interface to AI, like chatbots. Okay, no, no, this is just a temporary stop along the journey. But now it's even further, and just terminals. Do you have thoughts on, I don't know, do you think there will be a next step in how we interface with AI, or do you think chatbots and terminals are mostly where we end up? There will likely be a combination of both, both UIs and interfaces that you are interacting with, clicking with, and that feel more tactile. We are already seeing this and playing with this within Claude, the chatbot. So we recently released a bunch of these widgets that let Claude elicit and ask you questions and also show you things like the weather and stocks and whatnot in interactive ways. And I think those have had a really good reception because people still like to see UIs and touch them and click them. And they are much more efficient than typing something to Claude. But at the same time, when we really leaned into this chatbot paradigm, I think it just gave us this whole world of flexibility that we didn't get with these baked-in UIs. So my read here is, I don't think chat is ever going away because this opened up this new way of infinite ways to work with the model and to talk to the computer that we just didn't have before. But I think that it will still be more direct for very specific things to exist in this UI. And I think what will probably happen here is that a lot of those UIs will be generated more and more often by the models, as opposed to something that we're hand-coding each instance. But I think we're in this space where I don't think chat and maybe even talking to the terminal is going to go away. It's interesting that with Open Claude, Claude, Moldbot, all the names, one of the big innovations is another way to chat with it through WhatsApp and Telegram and SMS, just another form of chatbot. But that was a big unlock. Oh, I could just chat with it through WhatsApp. Yeah. And it's like, chatting and talking to someone is still, we as humans are doing it. And it's a way for us to interact in a really rich way. And now we just have this other medium to interact with a computer, basically. Yeah. So Kevin Wheel, who works at another AI lab, I want to mention, he had this great point on the podcast that talking is such a beautiful way to handle every level of intelligence. We can talk to people that are very, very smart and not so smart, and it's talking, and the scale works so well across the spectrum. We can talk to people at 200 IQ, 300 IQ, and talking still works. So that's why it's been this beautiful way to deal with the growing intelligence of models, and it continues to work. Yeah, that totally makes sense. Yeah. This episode is brought to you by Omni. Many product teams today are in the process of debating how to ship AI analytics. The hard part is obvious. Having an LLM guess at SQL in production is a huge mess and just a bad idea. Omni takes a different approach. They have a semantic layer built in so that when you embed their analytics, the AI actually knows your business definitions, not just your raw tables. You can test queries, validate the reasoning, and lock down permissions before anything hits production. If you want AI analytics in your product without building the whole stack from scratch, check out omni.co slash Lenny for a free three-week trial. Companies like Perplexity, DBT, and BuzzFeed use Omni to ship analytics their customers can trust. That's O-M-N-I dot C-O slash Lenny. Okay. I want to come back to this whole idea of management and IC. So you've put yourself back into the IC role in a lot of ways. Talk about that, and if you think that's a thing design managers need to be doing. Mm-hmm. Yeah. So this past year at Anthropic, I joined as an IC at first. And then I managed a team for a few months in an org structure that needed it. And now I'm actually back to doing full-time IC work. And I joined Anthropic as an IC because I was just really excited about the kind of work that there was to be done as an IC here, but also because I was feeling like I want to be close to the work. And I think this feels like a really important time to do it before I ascend the corporate ranks, you know? And having these questions and doubts about, is middle management safe in the future? Is the way that we're working actually going to be a job that persists into the future, or should I try something else and get my hands dirty? And to be totally fair, I actually love both sides of the coin. I love managing people. I love setting up teams and being at that level. But I also just really love IC work. I was a reluctant manager when I did it, and I was like, okay, I'll do it. So I love both sides of the coin pretty equally. But I think actually what being an IC across this past year has taught me is that it gave me a lot of skills that I don't think I would have gained if I was just managing throughout this year. Like I mentioned, the design process has changed so, so much in this past year, and I feel like I've just picked up so many hard skills that I wouldn't have necessarily had the time to do if I was just managing a team. So that's actually the best thing that's afforded me. And I think at any point, if I'm managing a team again, it will give me the empathy and understanding of how the design process has changed. I was a reluctant manager when I did it, and I was like, okay, I'll do it. So I love both sides of the coin pretty equally. But I think actually what being an IC over this past year has taught me is that it gave me a lot of skills that I don't think I would have gained if I was just managing throughout this year. The design process, like I mentioned, has changed so, so much in this past year. And I feel like I've picked up so many hard skills that I wouldn't have necessarily had the time to do if I was just managing a team. So that's actually the best thing that's afforded me. And I think at any point, if I'm managing a team again, it will give me the empathy and understanding of how the design process has changed. And I think that's actually a really important thing right now because, yeah, the teams are working so differently. And I think it's actually pretty hard to empathize if you are not working in that way or you're not always testing all the tools and trying stuff. But yeah, it's an interesting time to be a designer. And if I had not worked in this environment, I don't know if I would have totally understood it or knew what to do or how to guide my teams. So that's what this year really gave me. And so you were previously a director of design at Figma, right? Yeah. How big was your team? How large was your org? Just to give people a reference. At the max, I probably had 12, 15 designers or so. And I had a few managers as well. So it was an org. Yeah. Okay. So you've had the sense that middle management might not last. What's your current feeling? Do you think design management is a thing that persists long-term, or do you think everyone turns into IC? I think as long as there is a team of people, it helps to have somebody who is managing a team. I think there is real value in managers. It depends on what the shape of the manager is and what they actually do. But the way I think about what a helpful manager is these days is somebody who is not just pure people management. Like, just somebody to set you up, help you in your career, have one-on-ones, make sure you're feeling good at work. I think that is not a thing as much anymore. But I think somebody who can really function as giving the team direction, as well as doing some of the people management stuff, tied together, is the future of what managing looks like. At least for now. Somebody who can really engage with the team in terms of the work and giving direction there, as well as creating the environment for them to do their best work. And do you see yourself going back into management long-term? I probably will. I probably will. I think I really just love helping a team build the best product possible. And my motto there is, whatever it takes. If the team needs somebody to give the team direction and set up the team and whatnot, that could be me. If the team just needs somebody to execute on it, that could be me as well. So the advice I'm hearing for people in design, especially managers, is you almost need to move back into IC in order to truly understand what is happening and how much it's changing so that you can be a better manager. I think so. And I think traditionally, at least what I've seen, a lot of the engineering disciplines, when they hire EMs or even sometimes directors, actually make the EMs take a rotation for a few months and pick up a few tasks and really understand how the technology works before they become a full-time manager. And I think design probably needs to do something similar, where I think in the past design has been much more people-management-oriented. What did you find yourself most rusty in when you went back to IC designer? Actually doing crits and just getting criticized. Yeah. Getting criticized. You're like, oh yeah. It is hard to get critical feedback and to hear it on such a regular basis, because that's the thing you have to do as a designer. It's a pretty vulnerable exercise to share work and present it with your team, and then also just get a lot of critical feedback and take that all the time. Yeah. So currently you're leading design slash IC designing on cowork. Is that right? Yeah. Awesome. So Boris, who was on the pod recently, talked about how there's a lot of debate about what cowork should be. And there's all these big ideas. And he's like, in the end, let's just make it a terminal in the product, kind of a fancy terminal. Is there anything you could share about the process of landing on where he's landed for that experience of coworking? I have it here on my monitor, by the way, looking at it. With cowork specifically, we have had a bunch of different prototypes internally of what that could look like. And it's one of those things where we tried a lot of things, and then I think we weren't really sure when it was actually going to be ready to ship. And then it was everything all at once. We were like, okay, we're going to ship it soon. It was like 10 days, 10 days of building. Yeah. It was definitely longer than that. Overall it was like 10 days to get it from what we had internally to something that we were ready to ship externally. So we'd been building it for a while, but we weren't really sure about the actual form it was going to take. And so the way it got there is actually, there was a lot of different other explorations that we had internally on top of different agent harnesses and whatnot. And we just had prototypes, little parts of the different interactions that ended up in cowork. So things like when Claude gives you a to-do list, we tried a bunch of different form factors for that. We tried a bunch of different form factors for the way it presents you different multiple-choice questions. We tried a bunch of different ways to teach people what the use cases are and whatnot. And I don't know if we landed on the best form factor ever, but essentially it was stuff that was already working internally that people liked that we just thought we were going to get some more signal on by releasing it. So I think forcing ourselves to release it within that 10 days that we did, it was just sort of like whatever we had, let's put it out there, and then let's go out there and iterate from there, which is what we're doing. And it blew up the internet when you launched it. So it worked out. Yeah. Is there a feature of cowork today that you're either most proud of or just can't wait to fix and improve? Honestly, I think I'm just most proud of us actually shipping it, to be honest, and putting it out there. And yeah, I don't know if there's one specific thing yet. Because when you work on something and you work on it so long, especially as a designer, all you can do is see flaws in it. But I think there's a lot of stuff that I'm excited about. We have been iterating, especially on the homepage, to make that something where it feels more like, hey, these are tasks you can give Claude, and the tasks that Claude are working on. And so that actually should be rolling out. It might already be rolled out by the time this comes out. I see this little randomizer thing where you click it and it gives you all these different ideas. Mm-hmm. Yeah. Yeah. And then, so when you actually start to work with Claude on stuff, it feels more like a to-do list. It feels more like these are things Claude's working on. These are things that Claude needs your attention on. And I think there's an opportunity here to make it feel much more like this shared to-do list between you and Claude. So excited to iterate on that. And then I'm also excited to think more about what is the actual true form factor of this. Is it stuck in the screen always, or how does this reach out to the different surfaces that it's working with? I love that you shared that it wasn't just 10 days to do this thing. I see this little randomizer thing where you click it, and it gives you all these different ideas. Mm-hmm. Yeah. Yeah. And then, so when you actually start to work with Claude on stuff, it feels more like a to-do list. It feels more like these are things Claude's working on. These are things that Claude needs your attention on. And I think there's an opportunity here to make it feel much more like this shared to-do list between you and Claude. So excited to iterate on that. And then I'm also excited to think more about, yeah. What is the actual true form factor of this? Is it stuck in the screen always, or how does this reach out to the different surfaces that it's working with? I love that you shared that it wasn't just 10 days to do this thing. There's these numbers that people throw out there. We build it in 10 days. And your point is there was time spent thinking about what direction it should go in, and prototyping, mocking, trying stuff. And then it's okay, now we know what we want it to be. Let's build it and ship it. Yeah. I think for some reason that became the viral thing that got taken away from all of the co-work announcements, that it only took 10 days. But I think there have just been so many different explorations and people that have worked on different pieces of co-work that. Yeah, it was not just 10 days, and there were a lot of different people involved. It's one of those things where the idea kept coming back, and it's never the right moment, or there's different variations of it. And then all of a sudden it's the right moment. And it feels so obvious all along, but there was a long, long journey to get there. And by the way, for people that don't know much about co-work, the way I think about it, it's like Claude with hands. Where you can do stuff on your computer. How would you describe it, in a sentence or two? That's a good description. I actually haven't heard that, but I like that. I might use it more often, as Claude with hands. I also think about it as Claude is really good at taking all your garbage and then turning it into something nice. I think one of my favorite use cases that I really like out of co-work is just giving it a folder of my stuff. And it doesn't really matter what's in that folder, but I'm able to extract something good out of it. I've done that many times. Okay. Coming back to managing and being a manager and the role of a designer, I'm going to talk about hiring for a little bit. So, seeing how much is changing in the role of a designer, what do you look for? That's maybe new. What do you now look for when you're hiring designers that you think is really important for them to be successful in this new world? Well, I do think working specifically in the kind of environment that I do, there's a sense of resilience and roll-with-it kind of thing that I think is really important because so much is changing around us, and you have to be really willing to adapt, to try out new methods, to try out new tools, and learn stuff, as opposed to just being stuck in the old processes and the old ways. But then I think about also, there are probably three archetypes of folks that are really interesting to me right now. And I think these folks were already interesting to me before, but I feel like in this era it feels especially important. So the first one I would call strong generalists. Not just regular generalists, where they're good at a lot of things, but people that are almost block-shaped, in that T-shaped framework, where they're really good at a few core skills, like 80th percentile good. I think this is pretty rare and hard to hire for, to be honest, but I like this because the design role we've already seen is stretching and spanning. We're all becoming more PM-shaped, or we're all becoming engineering-shaped. And so if you already have strong skills in a few different buckets, it's really easy for you to flex around and expand your role. So that's really exciting to me. It's somebody who is really good at a bunch of things, again, a huge ask. And then the other person that's really exciting to me is, in that T-shaped framework, a deep specialist. Someone who is T-shaped, but the tip of the T probably goes down farther than most other people. So folks that are maybe the top 10% of the industry and whatnot. Again, super hard to find. And I feel very lucky that working at some of these places, folks like these, you can afford to hire them and actually bring them on board. And then my last one is probably the one that I think we're all overlooking, which is what I call the craft new grad. It's somebody who is early career and feels wise and experienced beyond their years, but is also very humble and very eager to learn. I think this person is really interesting right now because I think most companies are just hiring senior talent, folks that have done things before and are super experienced. But given how much the roles are changing and what we're expected to do is changing, I think having somebody who almost has a blank slate and is a really quick learner and is really eager to learn new tactics and stuff like that, and doesn't have all these baked-in processes and rituals in their mind, that's super valuable. So I think those are the folks that I think a lot of us are overlooking, but I'm really excited about. This is awesome. On the deep T shape, what's an example of someone in design that has, what's the skill that they're really good at? Sometimes there are designers who are just really technical in a way where they could be 50% of software. They're basically a software engineer. That's really interesting, especially because right now, a lot of it, at least for us, is you're working directly with the model. So it helps when you have deep engineering expertise. But another deep specialist T is maybe they're just really good at visual design or designing icons or something, where things like that, given that anybody can make anything, having that deep specialist slant feels like, oh yeah, they can really help differentiate the things that we're building. Awesome. Okay. And then this block shape, I had Marc Andre said on the podcast, we called it the F shape or E shape, where there's multiple T things, sideways F, sideways E, I guess. Is that what you're describing, where there are many things you're really, really good at? Yeah. Yeah. Basically, if you almost had their skill set, it would look like a block. There are so many skills that the T is spread out. Yeah. Okay. And the craft new grad. So this is just someone that is eager, open-minded, gritty, very smart, I imagine is a big part of it. Yeah. Awesome. Yeah. Yeah. If someone's a young designer trying to break in, trying to be successful, what would your advice be to them to help them have a shot at joining Anthropic, for example? I would just say build a bunch of stuff, try a bunch of stuff out, build actual things. I think that can feel, I don't really know what the state of design education or education is these days, but at least from back when I was in school, everything was very theoretical and here, we're going to teach you some approaches and whatnot. But the best craft new grad folks I know are just people who use the technology, build actual things. I don't feel limited by how little experience they might have. I think that sometimes they're actually unburdened by that because we have expectations of ourselves after being in industry for so long, but they actually don't, and they feel like anything is possible. And so, just building a bunch of stuff and sharing it with people and finding a community of folks that also do that. Yeah. I think my one call here too is I went to a school that started something called Socratica a few years after, actually a while after I graduated. And basically their whole thing is building stuff and showcasing it almost like a science project. But the best, the best kind of crack new grad folks I know are people who just use the technology, build actual things. I don't feel limited by how little experience they might have. I think that sometimes they're actually unburdened by that because we have expectations of ourselves after being in industry for so long, but they actually don't, and they feel like anything is possible. And so just building a bunch of stuff and sharing it with people and finding a community of folks that also do that. Yeah. I think my one call here too is I went to a school that started something called Socratica a few years after, actually a while after I graduated. And their whole thing is building stuff and showcasing it, almost like a science project. And I think there's just been a really cool movement there of folks who just build things and do things. For example, somebody built this Claude robot project. This was a few years ago too, where they were assembling robots that were running on Claude. And then somebody else did something where she just wanted to put googly eyes on a bus in Boston or something. And there's just a sense of both agency in terms of, yeah, we can just do stuff, but then also this community where people were just trying and building things and sharing things with each other. So whatever that looks like, given the school that someone's from or graduating from. Yeah. Doing that kind of stuff is the stuff that will make people stand out. So for current designers that are in a career, Austin Lee senior, do you think you need to get technical and learn to code, at least build, or do you think you could be really successful and just not lean into that and get better at other stuff? I think it definitely helps to maybe not learn how to code so much that you're building something from scratch, but it does feel like more and more of the designer's vocabulary right now is implementing some stuff. I wonder though, as the models, both the models and the products, get better, if we probably will continue to move up the abstraction layer and layers, and you won't have to actually know how each single line of code will work. But I think what I would say is start to bring that into your toolkit, the coding tools, whether or not you're actually becoming technical. I think any designer should just be really aware and know how to use the tools that are at hand, as opposed to maybe learning and going off and learning reactor or et cetera, et cetera. How good of a designer is Claude, would you say, or Claude code? Would everyone have to be scared? Would you hire Claude as a designer, or is it not there yet? I don't think Claude is there yet. I don't think Claude is there yet. In terms of a designer you would hire, I think it is not yet the strong generalist or the deep specialist or the crack new grad. I think it's pretty good at a first pass and at presenting a bunch of different ideas to you, but nothing there quite feels special and hireable yet. Which is good news for designers for now. It sucks at this for now. And I'm so curious to see how good it could get at this. That's such a big open question: can it pump out amazing, novel, unique content? Is it just never going to be that good as a human designer? Yeah. I mean, it's gotten a lot better in the last year or so. Even so. Yeah. There's a couple of management, I don't know, rituals or takes you have that I've heard from folks that you work with that I want to touch on. One is that you have this hot take that low leverage time for managers is just not a thing, that there's a lot of benefit you can get out of things that people consider low leverage. Can you talk about that? Yeah. Yeah. Yeah. I remember first becoming a manager. And I think one of the pieces of advice that I either got from a course or a book or something is, yeah, now that you're a manager, you have to really prioritize your time and categorize your work. And there was this two by two of, I don't remember what it had in it, but you essentially say, oh, these are the things that only I can do. These are the things anybody else can do, and everything else is low leverage and you shouldn't do that anymore. And a lot of the low leverage things were things that are really nitpicky in the weeds or literally, yes, probably somebody else could do those tasks. But when I think about leaders and managers that I respect the most, I actually think some of the best traits are that they choose low leverage tasks that they take on themselves. And that actually ends up being a very high leverage thing because it's them who's doing it. So one example is whenever you have senior leaders who just test the shit out of the product and they're so in tune with it. And they dogfood it, they repurp the bugs. They spend a bunch of time with engineers, sharing the logs and nitpicking and stuff like that. And I think that ends up being super high leverage, even though it's a lot of nitty-gritty time, because it creates this familiarity with the product, which I think is really good. It also creates this vibe where it's like, oh yeah, this senior leader really cares deeply, and they actually know the inside of the product, and they're rolling up their sleeves, and they're giving this feedback and working with the team on it. And I think similarly, what I've seen is when a senior leader is able to fix a bug now, even like I think I've actually seen Mike Krieger before put in PRs himself. And it's really nice because it's like, OK, cool. We're all on this team together, and nothing is below this person. And I think another thing that I love that's a little bit more cultural is when somebody goes out of the way to make somebody's anniversary card or something and vibe code them something super nice or make them a super nice card. Because I think it just shows that, yeah, an EA or somebody can put together the card, but this leader is somebody who cares so much about their team that they put in the effort. So that's something I try to embody, choosing the seemingly low leverage tasks that are worth my time. Yeah, that is so interesting. What you're saying there is, in a sense, the low leverage stuff is the stuff that often has the most impact because your reports wouldn't expect you to spend time on this thing. And the low leverage ends up being high leverage. Yeah. And I think it's what makes your style of leadership stand out or feel special to a certain person. Amazing. Another, I don't know, ritual and kind of way of running teams that I heard about you is you encourage team members roasting each other, which on the surface doesn't sound like a wonderful environment. But on the other hand, I hear constantly that the teams that you've built are just the happiest, the highest-performing teams. Talk about, I guess, this idea of roasting and encouraging that and just what you've learned about building awesome teams. Yeah, I think it's not that I'm like, yo, you should roast each other. I'm not forcing it in that way or anything. But when I think about the sort of psychological safety in teams and people that just get along with each other, when you think about your friends, you're always willing to push the boundaries a little bit and roast them. You're roasting your friends a lot. But you actually might not be roasting your coworkers a lot because it's all just about comfort and safety, right? So it's not that I'm like, oh, I want my teams to roast each other. But I think it can be a really good sign when the people on your team feel comfortable just poking fun at each other a little bit. And I think that also can be a good sign when folks also feel the same way about you as a leader, where there's just an element of they don't fear you as much, and they feel like there's a sense of safety where if they say something, they're not going to get fired. So an example of this is with my last team, I feel like they would make fun of things that I would say at crit sometimes, like certain phrases I would say. What's an example of that? But you actually might not be roasting your coworkers a lot because it's all just about comfort and safety, right? So it's not that I'm like, "Oh, I want my teams to roast each other." But I think it can be a really good sign when the people on your team feel comfortable poking fun at each other a little bit. And I think that also can be a good sign when folks also feel the same way about you as a leader, where there's an element of they don't fear you as much, and they feel like there's a sense of safety where, if they say something, they're not going to get fired. So an example of this is with my last team. I feel like they would make fun of things that I would say at crit sometimes, like certain phrases I would say. What's an example of that? I don't know. I would always be like, "Okay, what are next steps? And how do we follow up on this?" And then they'd be like, "Okay, what are next steps?" And they would channel me in that way. Yeah, I just think it shows a level of, okay, these people are not necessarily afraid of me. They know that they trust me, they can trust me. And they know enough about each other and me personally, in our personal lives, to be able to know where those boundaries are. But at the same time, I think the thing that you err into in that territory is, as a manager, are you friends with your reports, which is, I think, the thing people tell you not to do? And so the way I think about balancing this out is, you have to create this baseline of psychological safety, and people feel comfortable both with each other and with you. But you also have to make sure that they know that you have really high standards. And I think these two things can feel like they're in tension, but I think they actually work really well together. Because once you have that psychological safety, you have people trusting each other, and you applying the high standards actually, I think, becomes potentially easier because you can do it without fear. And I think about this from the approach of being a tough parent a little bit. It's like, oh yeah. I work with my team in a way where they know I'm always going to be there, and I'm not just going to fire them on a whim or something. But at the same time, they also know that I want the best for them and that I have high standards and that I'm working with them to make the best work possible. And so, yeah, that's the balance, I think. Can you create this environment where your team feels comfortable roasting you, but at the same time, they know they have to be doing great work, and they will do great work with you? That is awesome advice. It's interesting how often this management style comes back, or good management. It reminds me of radical candor, this combination of caring deeply and challenging directly. Yeah. And that's kind of what I hear here, is just make sure people know that you care deeply about them, but also be very direct and have high standards. Yeah. Yeah, exactly. Interesting. Okay, maybe a final question. I'm always looking for interesting frameworks and methods and processes that people have found useful in their work. And I hear you're a big fan of something called the legibility framework. Mm-hmm. Talk about this. Talk about how you use it, why it's so valuable. Yeah. This framework, I think I saw it on Twitter maybe last year or something. And it was Evan Tana, who is a partner at SPC. He's a VC. So it basically is this two-by-two. I don't think it got so much attention, but once I started seeing it, I actually couldn't stop thinking about it. So, on the two-by-two, he basically has founders. Founders can be either illegible or legible, and then ideas can either be illegible or legible. And basically he was saying that, okay, if both the founder and idea are super legible, the idea is probably not that novel and somebody is already going to implement it or do it, and you're actually not finding something new. But then where it gets really interesting is where the idea itself is illegible. And by illegible, he means it's really on the frontier, people might not get it yet, or the way it's being told, it's not being told in the way that makes the most sense to people. And I think this is obviously a good way for a VC to operate because you're trying to look for the opportunities that people don't see and put them out there in the world. But I also think that part of the role of the designer, at least at a frontier lab at Anthropic, is spotting the ideas that are illegible and trying to understand what's there and how to take that and transform it, whether it's through storytelling or whether it's through the actual UX and the form factor, and put it out there. And I think when I mentioned going through Slack and looking at all the stuff that people are making, that's kind of what I'm doing. I'm trying to see, oh yeah, what are the ideas that there's some energy around but might not make sense yet, that are worth me thinking about more in my work? There's one good example actually that ties to cowork, where there was this internal prototype that we called cloud studio that I think somebody built partway through last year. And essentially it was just this really dense, powerful interface that was built on top of some agentic harness. It might've been cloud code at that point in time too. And it had all these displays where it's showing you all this knowledge and all these skills and things cloud was doing and previewing its outputs. And I think, to a designer, I looked at it and I was like, "This is, I don't know what's going on. I don't really get it." But then I saw the folks in research, the folks building it, and just folks internally. There's just a lot of energy around it. And I was like, "Cool. I think there's something here, but I just don't understand it yet." And I think that really was an example of an illegible idea. And ultimately what came from it was the skills framework and the sort of markdown files that instruct cloud on how to do something. So that came out of that specific prototype. That was not something I was directly involved in, and that was more of the folks working on this prototype extracting that out of it. But when it did come to work on cloud cowork, and I was thinking about, "Oh yeah, what is the form factor for those things?" seeing that prototype and seeing the kinds of information that people found really helpful, like seeing cloud's plan and to-dos, seeing cloud's context and the files that it was going through, those kinds of things are things that I ended up pulling out of that prototype into cloud code work. So yeah, I think about how designers can almost be more like VCs in this way internally when we're looking at prototypes. This is super interesting. I did a research project recently with this guy, Terrence Rohan, a VC actually. We looked at what are patterns across people that have joined companies very early that ended up being massive successes, like Palantir and Stripe, Linear and Notion, all these companies. People that have joined many of these companies early, what were they looking for? And one of the factors was, the idea is so crazy that everyone's laughing at this. This is impossible. You're never going to do this. This is the craziest thing. Yeah. Why would you even think that? Palantir, OpenAI actually was one of them, just some research lab doing some stuff. Yeah. So yeah, I think about how designers can almost be more like VCs in this way internally when we're looking at prototypes. This is super interesting. I did a research project recently where, with this guy, Terrence Rohan and VC, actually, we looked at what patterns there are across people that have joined companies very early that ended up being massive successes like Palantir and Stripe. Linear and Notion, all these companies, people that have joined many of these companies early, what were they looking for? And one of the factors was the idea is so crazy that everyone's laughing at this. This is impossible. You're never going to do this. This is the craziest thing. Yeah. Why would you even think Palantir, all the, open AI actually was one of them, just some research lab doing some stuff. Yeah. So it's interesting that, and it's not like every time this will work, and it's not like every crazy idea that makes no sense will be good. But I think what you're saying is pay attention to stuff that's interesting to you and isn't totally clear. Maybe you can be the person that helps pull it together. Yeah. Yeah. That, but also if there is some energy around it, but I don't always quite understand what the energy is, it's to dive deeper and try to understand what that is. Yeah. Yeah. Because I think people who often gravitate towards these early ideas, they can't always articulate why. And it's up to you to dive deeper and understand that. That's one of those. So there's three patterns we found. One of the other ones was just pay attention to people getting very excited about this thing, even if you don't get it. And it sounds crazy. That's so interesting. Okay. And then what was the other one? Oh, the founders are just top 1%, was the other piece there, which everyone at Anthropic already. So you got that one. Oh man, Jenny, what a crazy time we're living through. What a world. How much, how much change. Okay. Before we get to our very exciting lightning round. Is there anything else that I should have asked you that you want to leave listeners with, that you want to double down on? I think I just want to call out the Anthropic design team and shout them out just because it's a team of folks that are really humble, and they're not always allowed on social, but they're doing a lot of really great work. And especially through this time, our jobs are changing so much. The team is so resilient, and they span this whole spectrum of people who are really technical and prototype all the way to folks that are really high craft and delivering stuff that's going out the door and is fabulous. And we are hiring throughout the year. So I just wanted to call that out. If I didn't scare you with the way that we work in Turtle and Anthropic, if that sounds more exciting than terrifying, would love to connect. What sounds exciting is getting access to these slacks or whatever, all the features being built. Yeah. That's the core benefit. Let's talk to super intelligence right now and tell me where I should invest. I'm just joking. And then in terms of hiring, is there anything specific that people should think about if they want to apply? Think a little bit about the archetypes that I mentioned, especially the strong generalists and the deep specialists. Those folks we're really excited about, but generally folks who are the block and the deep tea, the block, the block and the deep tea. What could we be talking about? Yeah. Folks who feel like those archetypes resonate with them, but also folks that are just really excited about the technology, have been building a lot, and want to be on the frontier. Amazing. Well, with that, we've reached our very exciting lightning round. I've got five questions for you, Jenny. All right. I'm ready. Here we go. What are two or three books that you find yourself recommending most to other people? The first one is The Power Broker by Robert Caro, which is an incredibly aggressive recommendation given that it's like 1100 pages. But I think in this era when our attention spans are so short, I think this is actually worth reading end to end. Because I think there are very few collections or memoirs where it spans through someone's entire life and you see how somebody changes throughout those decades. And it's also somebody who's really controversial too. And it's nice to read a really nuanced view of somebody, Robert Moses. And I think we just lose out on some of this long-arc thinking because we're thinking so much about right now. So it's just an important reminder that careers are long and is also really good for understanding how somebody gets things done really well. So The Power Broker. The second one that I recommend to a lot of people is a book called Insomniac City, which is written by Bill Hayes, who was the partner of the scientist Oliver Socks around the time that Oliver Socks died. And it's just this really beautiful ethereal memoir of Oliver Socks's last days and their love story. I think this has very little to do with the stuff on your podcast, Lenny, but it's a book that I really love and just makes you think about mortality, but also love and life and stuff like that. So that's one of my favorite books. My goal here is, you know, I'm trying to create, we're trying to create Renaissance humans. All of this other stuff is excellent. Cool. Interestingly, I saw Julie Zhu, famed design leader, was reading The Power Broker recently. What's going on over here? Spreading in design land. Okay. Do you have a favorite recent movie or TV show that you really enjoyed? I watched A Sentimental Value recently. I watched it on a plane, which is how directors want you to watch their films. But it's a Norwegian film by the same director who did The Worst Person in the World. I think just the pacing, the writing, the relationship between the characters is really subtle and beautiful. It's basically about this family, a family drama, but also about this house that they lived in their entire lives. It's beautiful because the house is sort of a character. So I don't know what else to say about that, but that was a really good movie. And then I would also recommend obviously The Pit season two. I don't, we're on that. We're on that. I think everybody just likes to watch people who are really competent at their jobs do something. So yeah. Imagine being an actor on that show, just how much you have to learn and memorize, all these terms. Yeah. Yeah. It just also seems really fast paced too. They do so much stuff in one shot, and there's just so much movement and stuff like that. Seems really, really hard to be an actor on. And I only recently realized Noah Wiley was in ER as a younger person, and now he's the head of this. Yeah. Yeah. Oh man. Okay. Favorite product you recently discovered that you really love cannot be cowork. Not one that I actually discovered recently, but Retro I've been using it for basically two years now since it came out, and I think I discovered new benefits of it recently. So, for folks who don't know about Retro, it's this small community photo-sharing app in which you can only share photos from each week from a given week, as opposed to all time. And it basically has none of the social media stuff. You can't really see counts. There are no ads, et cetera. But one really nice thing is now that I've been using it for two years, I can now look back at each year and see, oh yeah, this week two years ago, I was doing this. And it's become this really special way to live through each week of my life, basically. Wow. And it's also a beautifully crafted app if you're looking for building your own taste in design. Yeah. Designers love Retro. I could see, I could see that. Okay. Do you have a favorite life motto that you often come back to in work or in life? Yeah. Not sure if it's my favorite life motto, but one thing I do catch myself saying a lot is just, it is what it is. My dad says that all the time. I love it. Yeah. Yeah. It sounds super defeatist, but I promise it's not. But one really nice thing is now that I've been using it for two years, I can now look back at each year and see, oh yeah, this week, two years ago, I was doing this. And it's become this really special way to live through each week of my life. Wow. And it's also a beautifully crafted app. If you're looking for building your own taste in design. Yeah. Designers love retro. I could see, I could see that. Okay. Do you have a favorite life motto that you often come back to in work or in life? Yeah. Not sure if it's my favorite life motto, but one thing I do catch myself saying a lot is just, it is what it is. My dad says that all the time. I love it. Yeah. Yeah. It sounds super defeatist, but I promise it's not. I think just given how much stuff is going on in the world right now, and especially with the industry and whatnot, you can't control everything. And so sometimes it is what it is just brings the levity you need to move forward. I went to, I did a 10-day meditation retreat a while ago, and I came back from it and it's like, dad, you've been right all along. This is the whole, the answer to it all. It is what it is. You can't don't cling. Don't try to change. Just it is what it is. It is what it is. There's so much depth to that. I was like, okay, smarter than I even thought. Okay. Final question. Coming back to co-work, is there, I don't know, a mind-blowing use case, something just like, wow, that's so cool, that co-work can do that? Either something you use it for, or you've heard somebody using it for. One thing I really like is just introspection. And so I have this, this folder of local notes that I use IA Writer for, and I just write whatever. And over the years have collected it with a bunch of different notes, and they span all different things, like one-on-one notes, random thoughts, tiny memos, interview notes, et cetera. And my favorite, it makes it's, it's cool to me, is just using co-work to analyze that and have insights out of it and actually create things out of it. So anything I, anytime I can learn something new about myself, I love that, but I think a very practical thing I did with it the other day was along the lines of hiring. I was like, oh yeah, I want to articulate what it is that I look for when I look for a design craft. Because I think actually a lot of people struggle to articulate that. And I just had it read through all of my notes, both interview notes and other things that I cared about and memos and stuff like that that I've written in the past. And then it made me this rubric for evaluating that. So that kind of introspection where it's like, oh, I wouldn't have realized even these things about myself that I'd been putting out there implicitly. That's been really cool for me. That is so cool. So just to make this very clear for people, you have a folder with all these things you've written, one-on-ones, meetings. You could do, I don't know if y'all are allowed to use Granola, something like that, meeting transcripts, and ask it. And it's like, I was gonna ask what prompt you use, but it's just like, read all these things I've written and help me probably just understand how I feel about what is design craft. Yeah, basically I think it was like, hey, I have a bunch of interview notes and a bunch of notes related to design craft in this folder. Read it and then help me craft a memo slash rubric for how I assess craft in interviews. So cool. Yeah. Jenny, this was awesome. What a, what a time to be alive. What a time. Two final questions. Where can folks find you online if they want to reach out, and how can listeners be useful to you? Yeah. I'm on Twitter slash X is what we're calling it these days. It's at Jenny underscore when. That's probably the best place, not really on LinkedIn as much. So that's, that's the best place. And how can folks be helpful to me? Send us your product feedback, you know, like we're working on cowork, or anything cloud-related really, just send us your feedback. We'd love to make it better for you. Jenny. Thank you so much for being here. Yeah, of course. It was great chatting, Lenny. It was wonderful. Jenny, thank you. Bye, 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. And I hear you're a big fan of something called the legibility framework. Mm hmm. Talk about this. Talk about how you use it, why it's so valuable. Yeah. This framework, I think I saw it on Twitter of maybe last year or something. And it was Evan Tana, who is a partner at SPC. Uh, he's a BC. So it, it basically is this like two by two. I don't think it like got so much attention, but I, once I started seeing it, I actually couldn't stop thinking about it. So, um, on the two by two, he basically has like founders, like founders can be either illegible or legible. And then ideas can either be illegible or legible. Um, and basically he was saying that like, okay, if, if both the founder and idea is like super legible, the idea is probably not that novel and somebody is already like, they're already going to implement it or, or do it. And you're actually not finding something new. Um, but then where it gets really interesting is where like the idea itself is illegible. And by illegible, he means like, oh, it's sort of like really, you know, on the frontier, people might not get it yet. Or like the way it's being told, it just doesn't, it's not like being told in the, in the, in the way that makes the most sense to people. And I think this is obviously a good way for a VC to operate because you're trying to look for the opportunities that people don't see and put them out there in the world. But I also think that like part of the role of the designer, at least, um, at least at, at a, at a frontier lab at Anthropic is kind of spotting the ideas that are illegible and trying to understand what's there and how to take that. And like transform it, whether it's through storytelling or whether it's through like the actual UX and the form factor and, and, and, and put it out there. Um, and I think there's like, like when I mentioned, you know, going through Slack and like looking at all the stuff that people are making, like, that's kind of what I'm doing. I'm trying to see like, oh yeah, what are the ideas that are really. That like, there's like some energy there around, but like might not make sense yet that, that are worth me like thinking about more in my work. There's, there's one good example actually that like ties to co-work, uh, where there was this internal prototype that we called like cloud studio. That I think somebody built like partway through last year. Um, and essentially it was just this like really kind of like dense, powerful interface that was built on top of some agentic harness. I, I, I, it might've been cloud code at that point in time too. And it had all these like displays where it's showing you like all this knowledge and all these skills and, and things cloud was doing and like previewing its outputs. Um, and I think. To a designer, I looked at it and I was like, this is like, I don't know what's going on. I don't really get it. Um, but then I sort of saw the folks in research to folks building it and, and just folks internally, there's just a lot of energy around it. And I was like, cool. Like, I think there's like something here, but I just don't understand it yet. And I think that really was an example of an ill, an ill, illegible idea. And ultimately what came from it was like the skills framework. Um, and, and, and, uh, like the sort of like markdown files that sort of that instruct cloud on how to do something. So that came out of that specific prototype. That was not something I was directly involved in. And that was more of like, you know, the folks working on this prototype extracted that out of it. But when it did come to work on cloud cowork, and I was thinking about like, oh yeah, what is the form factor for those things? Seeing that prototype and seeing the kinds of information that people found really helpful, like seeing clouds, um, plan and to do's, um, seeing clouds, like context and the files that it was, it was going through. Like those kinds of things are things that I ended up pulling out of that prototype into cloud code work. So yeah, I think about like, how can designers almost be more like VCs in this way internally when we're looking at prototypes. This is super interesting. I did a research project recently where, uh, with this guy, Terrence Rohan and VC, actually, we looked at what are patterns across people that have joined companies very early that ended up being massive successes like Palantir and Stripe. Um, Linear and Notion, all these companies, like people that have joined many of these companies early, what were they looking for? And one of the factors was the idea is so, it's like so crazy that everyone's laughing at this. This is, this is impossible. You're never going to do this. This is the craziest thing. Yeah. Why would you even think like Palant like all the, like open AI actually was one of them, just like some research lab doing some stuff. Yeah. So, so it's interesting that, and it's not like every time this will work and it's not like every crazy idea that sounds makes no sense will be good. But I think what you're saying is pay attention to stuff that's like interesting to you and isn't totally clear. Maybe you can be the person that helps pull it together. Yeah. Yeah. That, but also like if there is some energy around it, but I don't quite under always understand what the energy is. It's to like dive deeper and try to understand what that is. Yeah. Yeah. Cause I think people who often gravitate towards these early ideas, they can't always articulate why. And it's sort of up to you to like dive deeper and understand that. That's one of those. So there's three patterns we found. One of the other ones was there's just pay attention to people getting very excited about this thing, even if you don't get it. And it's like, sounds crazy. That's so interesting. Okay. And then what was the other one? Oh, the founders are just like top 1% was the other piece there, which everyone at Anthropic already. So you got that one. Oh man, Jenny, what a crazy time we're living through. What a world. How much, how much change. Okay. Before we get to our very exciting lightning round. Is there anything else that I should have asked you that you want to leave listeners with that you want to double down on? I think I just want to call out the Anthropic design team and shout them out just because it's a team of folks that are just really humble and they're not always allowed us on social, but they're doing a lot of really great work. And especially through this time, our jobs are changing so much. The team is so resilient and they're, they sort of span this whole spectrum of people who are really technical and prototype to all the, all the way to folks that are really high craft and, and delivering stuff that's, that's going out the door and is fabulous. Um, and we are hiring throughout the year. So I just wanted to call that out. If I didn't scare you with the way that we work in Turtle and Anthropic, if that sounds more exciting than terrifying, um, would love to connect. What sounds exciting is getting access to these slacks or whatever, all the features being built. Yeah. That's the core benefit. Let's talk to super intelligence right now and tell me where I should invest. I'm just joking. And then in terms of hiring, is there anything specific that people should think about to, if they want to apply? Think a little bit about the, the archetypes that I mentioned, especially the strong generalists and the deep specialists. Those folks were really excited about, uh, but generally folks who are the block and the deep tea, the block, the block and the deep tea. What could we be talking about? Uh, yeah. Folks who feel like they, you know, they, those archetypes resonate with them, but also folks that are just really excited about the technology have been building a lot. Um, and, and sort of want to be on the frontier. Amazing. Well, with that, we've reached our very exciting lightning round. I've got five questions for you, Jenny. All right. I'm ready. Here we go. What are two or three books that you find yourself recommending most to other people? The first one is the power broker by Robert Caro, which is an, which is an incredibly aggressive recommendation given that it's a hot, it's like 1100 pages. Uh, but I think in this era when our, our, when our attention spans are so short, I think this is actually worth reading end to end. Um, because there, I think there are very few like collections or memoirs where it spans through someone's entire life and you sort of see how somebody changes throughout those decades. Um, and it's also something who's really controversial too. And it's, it's nice to sort of like read a really nuanced view of somebody, Robert Moses. And I think we just lose out on some of this like long arc thinking because we're so much, we're thinking so much about right now. So, uh, it's just an important reminder that careers are long and is also really good for kind of understanding how somebody just gets things done really well. So power broker. Um, the second one that I recommend to a lot of people is, uh, a book called Insomniac City, which is written by Bill Hayes, who is, was the partner of the scientist, Oliver Socks around the time that Oliver Socks died. And it's just this like really beautiful kind of like ethereal memoir of Oliver Socks last days and their sort of love story. Um, I think this has like very little to do with the stuff on your podcast, Lenny, but it's just like, it's just a book that I really love. Um, and just like makes you think about mortality, but also like love and life and stuff like that. So that's one of my favorite books. My goal here is in, you know, I'm trying to create, we're trying to create Renaissance humans. All of this other stuff is excellent. Cool. Interestingly, I saw Julie Zhu, uh, famed design leader was reading the power broker recently. What's going on over here? Spreading in design land. Okay. Do you have a favorite recent movie or TV show that you really enjoyed? Um, I watched a sentimental value recently. I watched it on a plane, which is, you know, how, how directors want you to do it. You know, watch to their films. Um, but it's a, it's a Norwegian film by the same director who did the worst person in the world. I think just the, the pacing, the writing, the relationship between the characters is just really subtle and beautiful. Um, it's basically about this family, sort of a family drama, but also about this house that they lived in their entire lives. It's beautiful. Cause like the house is sort of a character. So I don't know what else to say about that, but that was a really good movie. Um, and then I would also recommend obviously the pit season two. I don't, we're on that. We're on that. I think everybody just likes to watch people who are really competent at their jobs do something. Um, so yeah. Imagine being an actor on that show. Just like how much you have to learn and memorize all these terms. Yeah. Yeah. It just also seems really fast paced too. Like they do so much stuff in like one shot and there's just so much like movement and stuff like that. Seems really, really hard to be an actor on. And I only recently realized Noah Wiley was in ER as like a younger person and now he's like the head of this. Yeah. Yeah. Oh man. Okay. Favorite product you recently discovered that you really love cannot be cowork. Not one that I actually discovered recently. Um, but I, retro I've been using it for basically two years now since it came out. Um, and I think, I think I discovered new benefits of it recently. So, uh, for folks who don't know about retro, it's sort of like this small community photo sharing app in which you can only share, um, photos from each week from a given week, as opposed to like all time. Um, and it basically has like none of the social media stuff. Like you can't really see like counts. It's not, there's no ads, et cetera. Um, but one really nice thing is now that I've been using it for two years, I can now look back at each year and see like, oh yeah, this week, two years ago, I was doing this. And it's become this really special way to like live through each week of my life, basically. Wow. And, uh, it's also a beautifully crafted app. If you're looking for building your own taste in design. Yeah. Designers love retro. I could see, I could see that. Okay. Do you have a favorite life motto that you often come back to in work or in life? Yeah. Um, not sure if it's my favorite life motto, but one thing I do catch myself saying a lot is just, uh, it is what it is. Um, my dad says that all the time. I love it. Yeah. Yeah. It sounds super defeatist, but I promise it's not. I think just given how much stuff is going on in the world right now, and especially with the industry and whatnot, uh, you can't control everything. And so sometimes it is what it is just like brings the levity you need to move forward. I went to, I did a 10 day meditation retreat a while ago and I came back from it and it's like, dad, you've been right all along. This is the whole, the answer to it all. It is what it is. You can't don't cling. Don't try to change. Just it is what it is. It is what it is. There's so much depth to that. I was like, okay, smarter than I even thought. Okay. Final question. Coming back to co-work is there, uh, I don't know, mind blowing use case, something just like, wow, that's so cool. That co-work can do that. Either something you use it for, or you've heard somebody using it for. One thing I really like is just like introspection. And so, uh, I have this, this folder basically of like local notes that I have from that I use like IA writer for, and I basically just like write whatever. And over the years have collected it with a bunch of different notes and they span like all different things, like one on one notes, like random thoughts, like kind of like tiny memos, interview notes, et cetera. And my favorite, like it makes it's, it's cool to me is just like using co-work to like analyze that and have insights out of it and actually create things out of it. Um, so like anything I, anytime I can like learn something new about myself, like I love that, but I think a very practical thing I did with it the other day was like along the lines of hiring. I was like, oh yeah, I want to sort of articulate like what it is that I look for when I look for a design craft. Cause I think actually a lot of people struggle to articulate that. And I just had it read through all of my notes, both like interview notes and other things that I cared about and memos and stuff like that I've written in, in the past. And then it made me this rubric, uh, for, for evaluating that. So, um, that kind of introspection where it's like, oh, I don't even, I wouldn't have realized even these things about myself that I'd been putting out there implicitly. That's been really cool for me. That is so cool. So just to make this very clear for people, you have a folder with all these things you've written one on ones, meetings. Like you could do, I don't know if y'all are allowed to use granola, something like that, like meeting transcripts and ask it. And it's like, I was gonna ask what prompt you use, but it's just like, read all these things I've written and help me probably just like understand how I feel about what is design craft. Yeah, basically I think it was like, Hey, I have a bunch of interview notes and a bunch of notes related to design craft in this folder. Um, read it and then help me craft a, uh, like a memo slash rubric for how I assess craft in interviews. So cool. Yeah. Jenny, this was awesome. What a, what a time to be alive. What a time. Two final questions. Where can folks find you online if they want to reach out and how can listeners be useful to you? Yeah. Um, I'm on Twitter slash X is what we're calling it these days. Um, it's at Jenny underscore when that's probably the best place, not really on LinkedIn as much. So that's, that's the best place. Um, and how can folks be helpful to me? Send us your product feedback, you know, like we're working on cowork, uh, or anything cloud related, really just send us our, your feedback. We'd love to make it better for you. Jenny. Thank you so much for being here. Yeah, of course. It was great chatting Lenny. It was wonderful. Jenny. Thank you. Bye 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 Lenny's podcast.com. See you in the next episode.