- Fiona Fung, who leads engineering and product for Claude Code and Cowork (and previously led teams at Meta and Microsoft), shares lessons on running an AI-native org now that coding is rarely the bottleneck.
- She covers how bottlenecks have moved, which team norms had to be rewritten (code review, onboarding, planning, hiring, org shape), how changes were rolled out, and what signals prove it's working.
- Core themes: verification and "shifting left" matter more, code becomes the source of truth, every manager starts as an IC, "Claude-ify everything," and teams should keep auditing whether old processes still serve their purpose.
Running an AI-native engineering org
- Bottlenecks have moved: engineering bandwidth used to be the scarce resource, but with Claude, writing code, tests, and refactoring are no longer the slow part — so upstream and downstream processes had to change.
- "What served you prior may no longer" — a growth mindset of continually auditing whether team norms and processes still serve their purpose is the muscle that helps teams weather rapid change.
- The new bottlenecks are verification, who reviews, and how things are maintained; the team doubles down on verification and "shifting left" so automation catches issues closer to the source.
- In technical debates, code wins — building is cheap and arguing is expensive; instead of whiteboarding, generate multiple PR versions to compare impact, and prototype-and-dogfood rather than writing in-depth design docs.
- Claude Code code review helps keep up with coding bandwidth (style, lint, obvious bugs, spec drift), but humans stay in the loop for legal reviews, risk tolerance, trust boundaries, and product sense and taste (the "Mr. Peanut" snowman story).
- Preferred engineering profiles are creative builders with product sense and people with deep system expertise; product sense is built through dogfooding ("ant food"), shipping, iterating, and talking to customers.
- Code becomes the source of truth: onboarding is done with Claude tech deep-dives, and teams should check specs/skills into the codebase so the source of truth stays up to date.
- Three priorities that worked: keep the org agile and flat with managers starting as ICs, "Claude-ify" anything Claude can do, and give explicit permission to kill old processes since they pile up on their own; signals include falling onboarding ramp-up and PR cycle time, plus rising Claude-assisted commits.
Bottleneck shift — The idea that the scarce, rate-limiting resource (e.g. engineering bandwidth) changes over time and processes must adapt.
Verification — Confirming correctness of changes, the new bottleneck when coding bandwidth is abundant.
Shift left — Catching issues with automation closer to the source rather than after they reach customers.
Dogfooding — Using the product you build daily to build product sense; called "ant food" at Anthropic.
Source of truth — The authoritative reference for a team; on Claude Code it is the code itself, with specs checked in as skills.
Claude-ify — Asking whether Claude can do a task instead of a human, to free up bandwidth.
Forcing function — A team principle that compels a behavior, e.g. every teammate uses Claude Code.
IC — Individual contributor; on Claude Code every manager starts as one to learn the codebase.
Hey everyone. Thank you so much for joining me today. I'm excited to speak with all of you about some lessons I've learned as I've been leading Claude Code and Cowork. First I should do an intro. My name is Fiona Fung and I lead engineering and product for Claude Code and Cowork. And before Anthropic, I had also built and led teams at Meta and Microsoft. So with that, let's dive into some lessons I'm excited to share. Hopefully you'll find a couple of tidbits that may be helpful.
There are five topics I really want to cover today. The first is the bottlenecks have moved. And when the bottlenecks have shifted, what are all the team norms that we felt we have to rewrite because it's changed? How we rolled it out — I'll talk about how we rolled out some of these updated team norms. And in terms of the proof, what were some signals that give me confidence that we're trending in the right direction? And lastly, I'll leave you all with a topic to take back to your team to discuss, because I'd love to hear whether any of this resonated.
So, the bottlenecks have moved. There's that little subtitle of "what served you prior may no longer." This is one of my favorite sayings. I think this is the muscle that has really helped me weather at Anthropic, but also before at the other companies. Always being of that growth mindset. Our rate of change is just increasing. So I found it's always helpful to look at the team norms or processes you've set up and always ask yourself, is it still serving its purpose? For many years, engineering bandwidth was an expensive thing. Everything was around protecting this resource — we want to do a lot of planning to make sure we're building the right thing, or we want to do reviews. There's a lot of action around when engineering bandwidth was a limiting factor.
This is not the first time the bottleneck has shifted. Let me take you back in a time machine to the early 2000s. Back then I had just joined Microsoft, working on Visual Studio. There was no such thing as cloud. It sounds crazy now. I remember how we built Visual Studio — this one server room, everybody had to be on call for a week, and the whole build process was a queue. We could only merge six PRs at a time, and any time one of the tests would fail, you had to debug which of those PRs caused that failure. Back then, that was a big bottleneck. And then with cloud and continuous build, that bottleneck shifted. So this is just another shift for us to think about: when coding is no longer the bottleneck, what changes? On the Claude Code team, coding is rarely the slow part anymore. So all the upstream and downstream processes, we felt we've had to change.
What were some of the old bottlenecks? Writing code, writing tests, refactoring. I'll share a story. When I first joined Claude Code, I wanted to onboard and fix some bugs, and I thought, you know what I'm going to try? Test-driven development. The idea is write the test first, make sure it fails, then do the change, then you already have a test. But it was kind of like eating broccoli — even though I actually love broccoli — it feels like eating broccoli to write the test first because it's not always the most enjoyable part. I remember always itching to build a product and play around with it. And now with Claude, the first bug, I'm like, let's try test-driven development again. Let's write the test, verify it fails because that's how I verify the test is actually testing something, then make the bug fix, and we already had a test. That first experience, test-driven development was so much more fun and pleasurable. It took the tax out of test-driven development. That was a big aha. Refactoring is another one. I've been on teams before where we have to do some big refactoring or software architecture cleanup, and it's always a debate of when would we find time to do this work that we know is so important but always comes at the cost of time to build product. Thanks to the models, with Claude, refactoring is also no longer a bottleneck.
So when those shifts happen, what am I starting to see as the new bottlenecks? Verification. That's a big one, because the bandwidth has just increased so much. We have to pay even more attention to: is it correct? And when roles are blurring and more people are checking in changes, we also want to make sure everybody feels confident their changes are correct. Who reviews? And how is it maintained? With the throughput now so much more, we also have to think about the cost of maintenance.
These were some of the old processes that we felt quietly stopped working. I love that phrase "quietly stops working" because anytime somebody puts a process in place, it's to solve a problem, but very often we forget to audit whether those processes are still required. So what were some things we had to change? Planning norms. When coding is no longer the bottleneck and you have much more coding bandwidth, how did we rethink planning? Code ownership — almost all Claude Code commits now are co-authored by Claude; I don't think in the last few months I ever saw a commit that wasn't. Code review is a good one. Team makeup — roles are blurring, and what are the skill sets we're doubling down on? And knowledge sharing — what happens when documentation is no longer your source of truth?
So how have our planning and technical debates changed? In technical debate, code wins. Building is cheap, arguing is expensive. As I was onboarding, I wanted to do some code refactoring, and me and Boris had a couple of debates of approach. In the old days, I almost said, let's just go to a meeting room and whiteboard it out. But with Claude, I can actually generate. I remember generating three different versions of the PRs. That's what me and Boris used to have a really good technical debate about, because I wanted to look not at how the code was implemented but also the impact to the colleagues. Prototyping is another good one. Now anytime we have an idea, go ahead and prototype, dogfood it, and we'll try. Many years ago there were two camps: one that prototyping is great for moving quickly, and another with a concern that prototyping with speed cuts corners, and what happens when you show a prototype that kind of works and then you get hung up on it and try to ship that thing not built to scale. With Claude, prototyping is a great way to get started because we can iterate and learn, and then scale a prototype to production a lot faster. So what's one thing we reduced on the Claude Code team? Design docs — really in-depth planning and design docs. Most of our discussions actually happen in PRs or prototypes.
What do we really want to double down on? Verification. Now with all the bandwidth it's even more important. I call this "shift left." What's better than you running into a bug? It really sucks when I hear from our customers and developers that you run into a bug. But what's better than me running into the bug first is us having automation in place to catch it closer to the source. Who made this change? This used to be a question a lot of folks would ask. Now I encourage you, if you find yourself asking that, get to the root of the question. Are you looking for someone that caused a regression? Someone to answer a question? To gain context? And is there a way Claude could help you with that? One of the routines I have set up is automatically in the morning, over my coffee, I like to review all the feedback in our various feedback channels. I have a routine that amalgamates all the feedback and helps me identify themes.
How do you keep up with code reviews? Before we shipped Claude Code code review, this was a question I would get all the time. Claude Code code review is one tool that has really helped us keep up with the coding bandwidth. Where Claude is really good: style and lint, obvious bugs, and if there is a spec, I encourage you to check the spec into your code base because Claude is very good about verifying against spec drift. But it's still really important to have a human in the loop. Where are humans still important in code reviews? Legal reviews, anything about risk tolerance, especially trust boundaries — it's all about trust but verify, where humans bring needed expertise. Product sense and taste is another one. Last December, I wanted to update Claude in our CLI to give it a holiday theme and turn Claude into a snowman. I coded up an example and asked our designer to review it. She gave me excellent feedback: no, this looks nothing like a snowman, you turned Claude into Mr. Peanut. In the US we have this jar of peanuts whose mascot is a little peanut character. I thought it was a snowman, but she was right, it's a peanut. So humans with product sense are important to keep in the loop.
Now, what should my team makeup be, because roles are blurring and Claude is augmenting? When it comes to engineering, these are the two profiles I now focus on. One is creative builders with product sense, and another is deep system expertise. We want to make sure we still have that trust but verify. Maybe I'll talk about product sense. When I gave this talk in San Francisco, a lot of engineers came up to ask how do I build this product sense muscle? For me it's a muscle that starts with dogfooding, especially for managers, making sure you're spending time using the product you're building. Anytime I join a new team, that's one of the first things I do — dogfood the product to understand it. This way you really start feeling your product in your bones and you ask yourself, when I was building this, what problem were we trying to solve? One of my personal passion projects is working with small businesses — I feel small businesses are the lifeblood of our community. We just announced Claude for small business. I have friends who run restaurants, and I met with a lot of them to onboard them onto Cowork to see how, outside of enterprise, our users actually onboard. I got such valuable feedback. It's humbling to see where in the onboarding flow there were so many things we could have been doing better. So I really encourage you to dogfood your product, or as we call it in Anthropic, ant food. Otherwise, after a while, you might find yourself making product decisions based only on metrics, dashboards, or PowerPoints.
Filling cross-functional gaps with Claude. I see this for all roles. Designers on the Claude Code team previously would create a red line for polish or UX fixes and hand it off to engineering, and it's always a wait. Designers on Claude Code now use Claude to make a lot of those polish fixes, closing that iterative loop a lot faster. On the flip side, one time I was fixing a bug and needed content help. As an engineer, I tend to be very verbose. Claude was a great content design partner for me. So for all roles, Claude is augmenting all the areas where you may not be as strong.
This was the manager slide, maybe a spicy topic. When I first joined Claude Code, one of the first things I changed: I worked with recruiting because I believe so much in dogfooding. On Claude Code, we're using Claude to build Claude. So every manager started as an IC first. This worked really well because it enabled managers, before they have to worry about the responsibility of supporting people, to actually have time to roll up their sleeves and get into the code base and learn what it's like to be an engineer on the team. This is also a great time for a manager to get some maker hours back, because onboarding is a lot less daunting than it used to be. Even before Anthropic, I switched between manager and IC roles, and every time I switched to IC it helped build up the engineering toolbox, but that onboarding was always a little daunting if you hadn't done it in a while. When I onboarded to Claude, it was such a different experience.
In terms of knowledge sharing, what becomes a new source of truth? When I was onboarding to Claude, the code is our source of truth. In the old days, anytime I joined a new team, I'd meet with all the engineers and do these tech deep-dives. Now I did my first tech deep-dive just with Claude, because Claude is really good at answering all these questions. Even when I was doing that first bug fix, I asked Claude, before I dive into this, can you teach me about the surface area and the areas around this bug? For the Claude Code and Cowork team, our code is the source of truth. I'd encourage your teams, whatever is your source of truth, whether it's a spec, you might change that into a skill that you check into the code base. Whatever you can make sure becomes your source of truth, keep it in the code base because this way you can keep it up to date. When coding bandwidth is so much more, it makes it easier for any documentation that isn't part of the update loop to get out of date.
So how did we roll out all these changes on the Claude Code team? There were things that it was really important we aligned on as a team, and I also want to give space for bottoms-up because each team is focused on different things. What did we align on as a must-do? These are some of our Claude Code team principles and what we call forcing functions. This slide is out of date — I shouldn't put "every engineer," it's every teammate uses Claude Code, and Cowork. Using our product day in and day out has been really important. Claude-ify everything we can. Anytime we have a question of what, can Claude do it for me, because then it frees up more of my bandwidth for other problems. And my last one is explicit permission to kill old processes. Even our team principles and processes, after a few months, when we notice, is this really serving its intended purpose, we always give ourselves permission to critique and revisit. And bottoms-up, there's a lot of freedom for teams or pods to adapt — how Claude shows up in team triage, planning rituals, stand-ups, which workflows get Claude-ified first.
If I zoom out, what were the three things I prioritized for Claude Code and Cowork that worked really well? Number one, keeping the org as agile and flat as possible, having managers support parts of work but also get into the code base and be directly responsible for parts of the product. Number two, Claude-ify — if Claude can do it, Claude should. Sometimes even if Claude wasn't good at doing something two or three months ago, now with a model update it's actually gotten really good, which is why it always goes back to that growth mindset. And number three, people don't delete processes on their own, they tend to pile up. I was on a team with so many different SLAs — an SLA for P0 bugs, an SLA for incident response — and after a while, even the engineers came to me going, there's only 24 hours in a day, which SLA am I supposed to do? That's why it's always so important to audit whether all these are still necessary.
Now for the proof. What are some signals that it's actually working? Onboarding ramp-up time goes down — the span of time it takes for an engineer to land their first PR — and costs to other team members keeps going down. A lot of times when a person joins and asks me a question, I'm like, that's a great question, we should ask Claude. The PR cycle time should also go down, but this one's interesting. It's important not to just look at the end-to-end but break it out into all the different funnels of a PR. If your PR cycle time isn't going down, it might not mean you're not adopting AI — it could be other parts of your queue getting jammed up because of all the throughput, like build and CI systems keeping up. And lastly, Claude-assisted commits go up. But what's even more important than throughput is whatever you and your team are trying to solve — find some way to measure that, because outside of throughput, hopefully we're making meaningful change to make the product better or improve quality.
Now it's time to share a little takeaway home exercise. First I want to be transparent: I still have questions. For example, do you still need separate iOS and Android orgs? That was the traditional approach, but now with Claude enabling engineers to flex across mobile platforms, do we really still need two separate mobile teams? How far do you push fully automated reviews? We always want to strike the right balance between speed and not losing something important. And roles are blurring — how do we make sure everybody is productive and has confidence in their change? With that, this is what I'd love to leave you with: pick your noisiest workflow, or some workflow or team meeting you don't particularly enjoy or that's high tax on the team. I was on a team with a really expensive weekly meeting where everybody's on their laptop except when they pop their head up to give status. Pick a workflow and ask yourself, is it still serving its purpose? Or if it's really expensive, is it something Claude might help you with? And do this one step at a time. Thank you so much for listening to my talk. It's been a pleasure.
TL;DR
- Fiona Fung, who leads engineering and product for Claude Code and Cowork (and previously led teams at Meta and Microsoft), shares lessons on running an AI-native org now that coding is rarely the bottleneck.
- She covers how bottlenecks have moved, which team norms had to be rewritten (code review, onboarding, planning, hiring, org shape), how changes were rolled out, and what signals prove it's working.
- Core themes: verification and "shifting left" matter more, code becomes the source of truth, every manager starts as an IC, "Claude-ify everything," and teams should keep auditing whether old processes still serve their purpose.
Takeaways
- Bottlenecks have moved: engineering bandwidth used to be the scarce resource, but with Claude, writing code, tests, and refactoring are no longer the slow part — so upstream and downstream processes had to change.
- "What served you prior may no longer" — a growth mindset of continually auditing whether team norms and processes still serve their purpose is the muscle that helps teams weather rapid change.
- The new bottlenecks are verification, who reviews, and how things are maintained; the team doubles down on verification and "shifting left" so automation catches issues closer to the source.
- In technical debates, code wins — building is cheap and arguing is expensive; instead of whiteboarding, generate multiple PR versions to compare impact, and prototype-and-dogfood rather than writing in-depth design docs.
- Claude Code code review helps keep up with coding bandwidth (style, lint, obvious bugs, spec drift), but humans stay in the loop for legal reviews, risk tolerance, trust boundaries, and product sense and taste (the "Mr. Peanut" snowman story).
- Preferred engineering profiles are creative builders with product sense and people with deep system expertise; product sense is built through dogfooding ("ant food"), shipping, iterating, and talking to customers.
- Code becomes the source of truth: onboarding is done with Claude tech deep-dives, and teams should check specs/skills into the codebase so the source of truth stays up to date.
- Three priorities that worked: keep the org agile and flat with managers starting as ICs, "Claude-ify" anything Claude can do, and give explicit permission to kill old processes since they pile up on their own; signals include falling onboarding ramp-up and PR cycle time, plus rising Claude-assisted commits.
Vocabulary
Bottleneck shift — The idea that the scarce, rate-limiting resource (e.g. engineering bandwidth) changes over time and processes must adapt.
Verification — Confirming correctness of changes, the new bottleneck when coding bandwidth is abundant.
Shift left — Catching issues with automation closer to the source rather than after they reach customers.
Dogfooding — Using the product you build daily to build product sense; called "ant food" at Anthropic.
Source of truth — The authoritative reference for a team; on Claude Code it is the code itself, with specs checked in as skills.
Claude-ify — Asking whether Claude can do a task instead of a human, to free up bandwidth.
Forcing function — A team principle that compels a behavior, e.g. every teammate uses Claude Code.
IC — Individual contributor; on Claude Code every manager starts as one to learn the codebase.
Transcript
Hey everyone. Thank you so much for joining me today. I'm excited to speak with all of you about some lessons I've learned as I've been leading Claude Code and Cowork. First I should do an intro. My name is Fiona Fung and I lead engineering and product for Claude Code and Cowork. And before Anthropic, I had also built and led teams at Meta and Microsoft. So with that, let's dive into some lessons I'm excited to share. Hopefully you'll find a couple of tidbits that may be helpful.
There are five topics I really want to cover today. The first is the bottlenecks have moved. And when the bottlenecks have shifted, what are all the team norms that we felt we have to rewrite because it's changed? How we rolled it out — I'll talk about how we rolled out some of these updated team norms. And in terms of the proof, what were some signals that give me confidence that we're trending in the right direction? And lastly, I'll leave you all with a topic to take back to your team to discuss, because I'd love to hear whether any of this resonated.
So, the bottlenecks have moved. There's that little subtitle of "what served you prior may no longer." This is one of my favorite sayings. I think this is the muscle that has really helped me weather at Anthropic, but also before at the other companies. Always being of that growth mindset. Our rate of change is just increasing. So I found it's always helpful to look at the team norms or processes you've set up and always ask yourself, is it still serving its purpose? For many years, engineering bandwidth was an expensive thing. Everything was around protecting this resource — we want to do a lot of planning to make sure we're building the right thing, or we want to do reviews. There's a lot of action around when engineering bandwidth was a limiting factor.
This is not the first time the bottleneck has shifted. Let me take you back in a time machine to the early 2000s. Back then I had just joined Microsoft, working on Visual Studio. There was no such thing as cloud. It sounds crazy now. I remember how we built Visual Studio — this one server room, everybody had to be on call for a week, and the whole build process was a queue. We could only merge six PRs at a time, and any time one of the tests would fail, you had to debug which of those PRs caused that failure. Back then, that was a big bottleneck. And then with cloud and continuous build, that bottleneck shifted. So this is just another shift for us to think about: when coding is no longer the bottleneck, what changes? On the Claude Code team, coding is rarely the slow part anymore. So all the upstream and downstream processes, we felt we've had to change.
What were some of the old bottlenecks? Writing code, writing tests, refactoring. I'll share a story. When I first joined Claude Code, I wanted to onboard and fix some bugs, and I thought, you know what I'm going to try? Test-driven development. The idea is write the test first, make sure it fails, then do the change, then you already have a test. But it was kind of like eating broccoli — even though I actually love broccoli — it feels like eating broccoli to write the test first because it's not always the most enjoyable part. I remember always itching to build a product and play around with it. And now with Claude, the first bug, I'm like, let's try test-driven development again. Let's write the test, verify it fails because that's how I verify the test is actually testing something, then make the bug fix, and we already had a test. That first experience, test-driven development was so much more fun and pleasurable. It took the tax out of test-driven development. That was a big aha. Refactoring is another one. I've been on teams before where we have to do some big refactoring or software architecture cleanup, and it's always a debate of when would we find time to do this work that we know is so important but always comes at the cost of time to build product. Thanks to the models, with Claude, refactoring is also no longer a bottleneck.
So when those shifts happen, what am I starting to see as the new bottlenecks? Verification. That's a big one, because the bandwidth has just increased so much. We have to pay even more attention to: is it correct? And when roles are blurring and more people are checking in changes, we also want to make sure everybody feels confident their changes are correct. Who reviews? And how is it maintained? With the throughput now so much more, we also have to think about the cost of maintenance.
These were some of the old processes that we felt quietly stopped working. I love that phrase "quietly stops working" because anytime somebody puts a process in place, it's to solve a problem, but very often we forget to audit whether those processes are still required. So what were some things we had to change? Planning norms. When coding is no longer the bottleneck and you have much more coding bandwidth, how did we rethink planning? Code ownership — almost all Claude Code commits now are co-authored by Claude; I don't think in the last few months I ever saw a commit that wasn't. Code review is a good one. Team makeup — roles are blurring, and what are the skill sets we're doubling down on? And knowledge sharing — what happens when documentation is no longer your source of truth?
So how have our planning and technical debates changed? In technical debate, code wins. Building is cheap, arguing is expensive. As I was onboarding, I wanted to do some code refactoring, and me and Boris had a couple of debates of approach. In the old days, I almost said, let's just go to a meeting room and whiteboard it out. But with Claude, I can actually generate. I remember generating three different versions of the PRs. That's what me and Boris used to have a really good technical debate about, because I wanted to look not at how the code was implemented but also the impact to the colleagues. Prototyping is another good one. Now anytime we have an idea, go ahead and prototype, dogfood it, and we'll try. Many years ago there were two camps: one that prototyping is great for moving quickly, and another with a concern that prototyping with speed cuts corners, and what happens when you show a prototype that kind of works and then you get hung up on it and try to ship that thing not built to scale. With Claude, prototyping is a great way to get started because we can iterate and learn, and then scale a prototype to production a lot faster. So what's one thing we reduced on the Claude Code team? Design docs — really in-depth planning and design docs. Most of our discussions actually happen in PRs or prototypes.
What do we really want to double down on? Verification. Now with all the bandwidth it's even more important. I call this "shift left." What's better than you running into a bug? It really sucks when I hear from our customers and developers that you run into a bug. But what's better than me running into the bug first is us having automation in place to catch it closer to the source. Who made this change? This used to be a question a lot of folks would ask. Now I encourage you, if you find yourself asking that, get to the root of the question. Are you looking for someone that caused a regression? Someone to answer a question? To gain context? And is there a way Claude could help you with that? One of the routines I have set up is automatically in the morning, over my coffee, I like to review all the feedback in our various feedback channels. I have a routine that amalgamates all the feedback and helps me identify themes.
How do you keep up with code reviews? Before we shipped Claude Code code review, this was a question I would get all the time. Claude Code code review is one tool that has really helped us keep up with the coding bandwidth. Where Claude is really good: style and lint, obvious bugs, and if there is a spec, I encourage you to check the spec into your code base because Claude is very good about verifying against spec drift. But it's still really important to have a human in the loop. Where are humans still important in code reviews? Legal reviews, anything about risk tolerance, especially trust boundaries — it's all about trust but verify, where humans bring needed expertise. Product sense and taste is another one. Last December, I wanted to update Claude in our CLI to give it a holiday theme and turn Claude into a snowman. I coded up an example and asked our designer to review it. She gave me excellent feedback: no, this looks nothing like a snowman, you turned Claude into Mr. Peanut. In the US we have this jar of peanuts whose mascot is a little peanut character. I thought it was a snowman, but she was right, it's a peanut. So humans with product sense are important to keep in the loop.
Now, what should my team makeup be, because roles are blurring and Claude is augmenting? When it comes to engineering, these are the two profiles I now focus on. One is creative builders with product sense, and another is deep system expertise. We want to make sure we still have that trust but verify. Maybe I'll talk about product sense. When I gave this talk in San Francisco, a lot of engineers came up to ask how do I build this product sense muscle? For me it's a muscle that starts with dogfooding, especially for managers, making sure you're spending time using the product you're building. Anytime I join a new team, that's one of the first things I do — dogfood the product to understand it. This way you really start feeling your product in your bones and you ask yourself, when I was building this, what problem were we trying to solve? One of my personal passion projects is working with small businesses — I feel small businesses are the lifeblood of our community. We just announced Claude for small business. I have friends who run restaurants, and I met with a lot of them to onboard them onto Cowork to see how, outside of enterprise, our users actually onboard. I got such valuable feedback. It's humbling to see where in the onboarding flow there were so many things we could have been doing better. So I really encourage you to dogfood your product, or as we call it in Anthropic, ant food. Otherwise, after a while, you might find yourself making product decisions based only on metrics, dashboards, or PowerPoints.
Filling cross-functional gaps with Claude. I see this for all roles. Designers on the Claude Code team previously would create a red line for polish or UX fixes and hand it off to engineering, and it's always a wait. Designers on Claude Code now use Claude to make a lot of those polish fixes, closing that iterative loop a lot faster. On the flip side, one time I was fixing a bug and needed content help. As an engineer, I tend to be very verbose. Claude was a great content design partner for me. So for all roles, Claude is augmenting all the areas where you may not be as strong.
This was the manager slide, maybe a spicy topic. When I first joined Claude Code, one of the first things I changed: I worked with recruiting because I believe so much in dogfooding. On Claude Code, we're using Claude to build Claude. So every manager started as an IC first. This worked really well because it enabled managers, before they have to worry about the responsibility of supporting people, to actually have time to roll up their sleeves and get into the code base and learn what it's like to be an engineer on the team. This is also a great time for a manager to get some maker hours back, because onboarding is a lot less daunting than it used to be. Even before Anthropic, I switched between manager and IC roles, and every time I switched to IC it helped build up the engineering toolbox, but that onboarding was always a little daunting if you hadn't done it in a while. When I onboarded to Claude, it was such a different experience.
In terms of knowledge sharing, what becomes a new source of truth? When I was onboarding to Claude, the code is our source of truth. In the old days, anytime I joined a new team, I'd meet with all the engineers and do these tech deep-dives. Now I did my first tech deep-dive just with Claude, because Claude is really good at answering all these questions. Even when I was doing that first bug fix, I asked Claude, before I dive into this, can you teach me about the surface area and the areas around this bug? For the Claude Code and Cowork team, our code is the source of truth. I'd encourage your teams, whatever is your source of truth, whether it's a spec, you might change that into a skill that you check into the code base. Whatever you can make sure becomes your source of truth, keep it in the code base because this way you can keep it up to date. When coding bandwidth is so much more, it makes it easier for any documentation that isn't part of the update loop to get out of date.
So how did we roll out all these changes on the Claude Code team? There were things that it was really important we aligned on as a team, and I also want to give space for bottoms-up because each team is focused on different things. What did we align on as a must-do? These are some of our Claude Code team principles and what we call forcing functions. This slide is out of date — I shouldn't put "every engineer," it's every teammate uses Claude Code, and Cowork. Using our product day in and day out has been really important. Claude-ify everything we can. Anytime we have a question of what, can Claude do it for me, because then it frees up more of my bandwidth for other problems. And my last one is explicit permission to kill old processes. Even our team principles and processes, after a few months, when we notice, is this really serving its intended purpose, we always give ourselves permission to critique and revisit. And bottoms-up, there's a lot of freedom for teams or pods to adapt — how Claude shows up in team triage, planning rituals, stand-ups, which workflows get Claude-ified first.
If I zoom out, what were the three things I prioritized for Claude Code and Cowork that worked really well? Number one, keeping the org as agile and flat as possible, having managers support parts of work but also get into the code base and be directly responsible for parts of the product. Number two, Claude-ify — if Claude can do it, Claude should. Sometimes even if Claude wasn't good at doing something two or three months ago, now with a model update it's actually gotten really good, which is why it always goes back to that growth mindset. And number three, people don't delete processes on their own, they tend to pile up. I was on a team with so many different SLAs — an SLA for P0 bugs, an SLA for incident response — and after a while, even the engineers came to me going, there's only 24 hours in a day, which SLA am I supposed to do? That's why it's always so important to audit whether all these are still necessary.
Now for the proof. What are some signals that it's actually working? Onboarding ramp-up time goes down — the span of time it takes for an engineer to land their first PR — and costs to other team members keeps going down. A lot of times when a person joins and asks me a question, I'm like, that's a great question, we should ask Claude. The PR cycle time should also go down, but this one's interesting. It's important not to just look at the end-to-end but break it out into all the different funnels of a PR. If your PR cycle time isn't going down, it might not mean you're not adopting AI — it could be other parts of your queue getting jammed up because of all the throughput, like build and CI systems keeping up. And lastly, Claude-assisted commits go up. But what's even more important than throughput is whatever you and your team are trying to solve — find some way to measure that, because outside of throughput, hopefully we're making meaningful change to make the product better or improve quality.
Now it's time to share a little takeaway home exercise. First I want to be transparent: I still have questions. For example, do you still need separate iOS and Android orgs? That was the traditional approach, but now with Claude enabling engineers to flex across mobile platforms, do we really still need two separate mobile teams? How far do you push fully automated reviews? We always want to strike the right balance between speed and not losing something important. And roles are blurring — how do we make sure everybody is productive and has confidence in their change? With that, this is what I'd love to leave you with: pick your noisiest workflow, or some workflow or team meeting you don't particularly enjoy or that's high tax on the team. I was on a team with a really expensive weekly meeting where everybody's on their laptop except when they pop their head up to give status. Pick a workflow and ask yourself, is it still serving its purpose? Or if it's really expensive, is it something Claude might help you with? And do this one step at a time. Thank you so much for listening to my talk. It's been a pleasure.