- Fiona Fung, who leads Claude Code and Cowork engineering and product, shares how the team rewrote its norms once AI shifted the bottleneck away from engineering bandwidth toward verification, review, security, and cross-functional alignment.
- Concrete changes include just-in-time planning, settling technical debates by generating multiple PRs instead of whiteboarding, doubling down on verification and "shift left" automation, and selectively trusting Claude for reviews while keeping humans for legal, security, and product taste.
- Her overarching mantra is "what served you prior may not serve you any longer" — keep a growth mindset, give pods explicit permission to kill old processes, keep the org flat, dogfood heavily, and re-audit your noisiest workflow.
Running an AI-native engineering org
- The bottleneck has shifted: engineering bandwidth and coding throughput used to be the expensive thing, but coding is rarely the slow part now, so bottlenecks moved to verification, code review, cross-functional partners, and security.
- Processes "quietly stop working" — teams layer on processes (e.g. stacking SLAs) but rarely retire them, so leaders need explicit permission to kill old processes and re-audit whether each still serves its purpose.
- Planning is just-in-time ("JIT planning"): a six-month roadmap became stale within months, so the team does much less pre-planning and replaces design-doc rituals with prototypes and PRs.
- In technical debates, code wins: instead of whiteboarding, generate multiple PRs (she made three) to compare not just implementations but their impact on all callers — but set culture so it's never "last check-in wins."
- Verification is the new investment area: "shift left" with more automation to catch bugs earlier so everyone, regardless of role, has higher confidence in their changes given the increased throughput.
- Trust Claude for styling, lint, PR feedback, catching/fixing bugs, and adding tests; keep humans for legal review, security and trust-boundary code, and product sense/taste (illustrated by the snowman-Claude that looked like Mr. Peanut).
- Team makeup indexes on two engineer profiles — creative builders with product sense, and deep systems experts (e.g. distributed systems for Claude Code remote) — and less on raw throughput; roles are blurring as PMs code and engineers handle content/design with Claude's help.
- Keep the org flat and scrappy: every manager starts as an IC first to dogfood and earn credibility, the code (plus checked-in specs) is the source of truth, and "Claudify everything you can," while leaving pods high agency over their own workflows.
- Signals it's working: dramatically reduced onboarding ramp-up time, shorter PR cycle time (which can also reveal CI/infra scaling gaps), and Claude-assisted commits rising to nearly 100% — but always tie metrics back to product quality and reliability, not just volume.
Bottleneck shift — The move of the expensive constraint away from coding throughput toward verification, review, and cross-functional work.
Quietly stops working — When a once-useful process becomes obsolete without anyone noticing or retiring it.
JIT planning — "Just-in-time" planning: doing the right amount of planning at the right time rather than long-horizon roadmaps.
Shift left — Moving bug detection and verification earlier in the pipeline through automation, closer to the source.
Dogfooding — Heavily using your own product day-to-day to build empathy and ship better.
Routines — Automations (in Claude Code) that run on a schedule or trigger, e.g. summarizing a feedback channel each morning.
Claudify — Delegating a manual workflow to Claude wherever possible.
Source of truth — The authoritative artifact (here, the codebase plus checked-in specs) the team relies on over separate docs.
Pod — A small sub-team within Claude Code given agency to adapt its own rituals and workflows.
Trust but verify — Relying on Claude for much of the work while keeping human experts in the loop for high-risk areas.
Hey folks, do you hear me okay? I swear this isn't a Claude Code thing, but do you mind if I take a photo? Boris and Jared had their session at 2:00 and I really thought this would be empty — there's no way people would still be coming from that session. Thank you. I promise Boris and I don't just do selfies all the time. Good afternoon and thanks for attending. My name is Fiona Fung and I lead Claude Code and Cowork engineering and product, so I work closely with Boris and Cat. Before Anthropic I led and grew teams at Meta and Microsoft. Today's talk is about some lessons I learned helping Claude Code and Cowork grow as we build out this team — lessons that apply across my time at Meta, Microsoft, and Anthropic. It's funny, I made this deck about a month ago and already had to change content; when I started it, there were no routines, and that way of working was different for me.
I want to cover five themes I've noticed. One is that the bottlenecks have shifted. When bottlenecks shift, what team norms did we have to rewrite within the Claude Code team? I'll share those norms, how we rolled them out, and what signals tell me we're trending in the right direction — and it's always important to ask: is it still serving us? I'll end with a few questions I still have, and suggestions for actions to take back to your teams.
First, the shift. You'll hear me repeat this subtitle: what served you prior may not serve you any longer. A constant growth mindset is a muscle that has served me well, especially now when the rate of change is a little crazy. The first time I did live coding was last year, and it was still making bugs — using constants everywhere, not good engineering practice — and now it's become so much more capable. For years, engineering bandwidth was the expensive thing; coding throughput was expensive, and a lot of our software-shipping processes were built around that — even how we did planning, from waterfall to agile.
This isn't the first time our industry has had to adapt. Come back with me to the 2000s, when I started my career working on Visual Studio, shipping VS 2005. In those days we shipped software on CD-ROMs — before that, floppy disks. We had hard deadlines because we had to get the software to the manufacturing lab to print the CDs, put them in boxes, and ship to stores. When we could distribute software online, that changed how we ship. Now the new shift is that engineering bandwidth is no longer the expensive thing. On the Claude Code team, coding is rarely the slow part, and the throughput has really increased — it's not only that we get to build more, the amount we're generating has changed a lot.
When your bottleneck shifts away from the act of typing — writing code, writing tests, refactoring used to be expensive, and we'd schedule time for refactoring — that's no longer the bottleneck. Bottlenecks then shift to other areas: verification, review, cross-functional partners, security. Is this code correct? Who reviews it? That's one of the top questions I get from fellow eng leaders: how are humans keeping up with code reviews, and how is it maintained, since it's now much easier to generate a lot of code, so think about maintenance cost too.
These are processes that quietly stop working — I love that phrase. We put processes in for a reason, thinking there's a gap or we want to improve, but rarely do processes kill themselves; we tend to layer more and more on. On one team we had so many SLAs — a P0 bug SLA, a high-pri review SLA — that I had to stack-rank priorities so engineers knew which SLA mattered more. The planning norms, code ownership ("who wrote this, who owns it?"), code reviews, team makeup as roles blur (non-engineering partners are also shipping code), and knowledge sharing and onboarding — all of these are changing.
So what norms did we rewrite on the Claude Code team? Number one is code review — human judgment of who actually needs it. Onboarding changed, planning changed, hiring changed especially with roles blurring, and org shape — one of my favorite spicy topics; I'll share the story of proposing that at Anthropic, where one recruiting partner thought I was crazy.
How has planning changed? We do a lot less of it, and the timing matters — I call it JIT planning, like JIT compiling. When I first joined I thought we needed a six-month roadmap; we wrote one, it was good for three months, and after the new year so many things had changed that six months seemed too long. Do the right amount at the right time, because prototyping and code generation are no longer the bottleneck. Technical debates are a fun one: code wins. When I first joined, I wanted to do a refactoring to learn the codebase, and Boris and I had a healthy technical debate. I almost reached for my old toolbox — tap him on the shoulder, go to a room and whiteboard — then realized I can just generate all the options. I generated three PRs. The cool part is I cared about both the implementation of the API and the impact on all the callers, and generating three versions let us debate implementation and impact. When building is cheap, arguing is expensive — but this makes team culture for alignment even more important. What won't fly is "last person to check in wins" — I'm not going to stay up to submit a PR or set up a routine to get the last word. You need open, honest technical debates and good alignment.
On planning we reduced the design-doc-before-every-code ritual. For certain teams and async discussions, design docs are still important, but on Claude Code most discussion is a PR instead of a doc: "we found an idea, go prototype." We don't do many product reviews because the landscape changes fast — let's prototype, get internal folks using it, ship to all of you, and hear the feedback. What did we double down on? Verification — an area we need to keep getting better at, because throughput is different and there are new ways to break. I call it shift left: more automation so we catch bugs earlier, closer to the source. Because roles are blurring, my designers want confidence that their checked-in code doesn't break something. I once fixed a bug in resume and the next day saw someone flag a bug to Boris — that sinking feeling. Regardless of role, I want everyone to have higher confidence in their changes.
"Who made this change?" is now an odd question since our PRs are Claude-assisted. What's more helpful is double-clicking into it: what are you really trying to answer? Are you looking for who caused a regression — not to blame, but to know who last touched it? An expert to answer a customer question? Context? Then think about whether you can automate it. When I started this talk a month ago, every morning I'd open desktop Claude Code, go into the customer feedback channel, and ask it to summarize with my morning coffee. Now it's a routine — even better than before. Code ownership is fuzzier, but double-click to the real question and see how Claude can help.
How do you keep up with code reviews? As Cat showed in the keynote, we lean heavily on Claude code review. The interesting part is where you trust Claude a lot versus where you still want a human. Claude does a great job babysitting PRs — handling styling, lint, PR feedback, catching and fixing bugs before a full commit, and adding tests. Where I still want a human is expertise — trust but verify. Legal review: I want my legal partner. Risk tolerance, trust boundaries, and security-sensitive code: pull in the experts. And product sense and taste — I like to decorate Claude for the holidays; I asked Claude Code to turn Claude into a snowman, but it wasn't great at ASCII art then, and my design partner said I'd turned Claude into the Mr. Peanut character. So I made it simpler — ice blue with a snowflake. Keep product sense in mind.
That leads to team makeup. Because roles are blurring and Claude is augmenting, on Claude Code I index heavily on two engineer profiles. One is creative builders with product sense — the dreamers, curious, passionate about shipping a product that solves a problem, with lots of iteration for a delightful experience. The other is deep systems expertise. When I joined, we were good with product generalists and creative folks but missing distributed-systems expertise, which you need when building things like Claude Code remote to run Claude everywhere. Think about the hard parts where you want to double down. I index less on raw throughput, since thanks to the models we're much more efficient. Cross-functional gaps are interesting too: I wanted to update our survey responses but didn't have a content designer, and my writing is terrible at being short and succinct — every line in the terminal matters. Claude augmented that content-design role for me. On the flip side, our PMs code a lot, which is fun. Non-traditional coders do more engineering, and engineers lean into content or design work. Claude has augmented roles all around.
Org shape was a spicy one. When I joined, recruiters used the typical 10 ICs to one manager and nesting. I leaned into keeping it scrappy. Across Anthropic, Meta, and Microsoft — Visual Studio, Facebook Marketplace, AR/VR, Claude — what helped me ship great product is heavy, heavy dogfooding. For leaders, nowadays it's fun because I can still be in the code; for a while you couldn't, and when you can't, make time to use your product day in and day out. That's why I wanted every manager in Claude Code to start as an IC first — to earn street cred and learn to be an effective engineer. I structured the org as flat as possible to stay agile. My recruiters had concerns: "You want to hire managers who start as ICs first? No manager would be interested." But that's what dogfooding on Claude Code is about, and if someone's not interested, earlier separation is better. Without Claude I wouldn't have been able to ramp or code, given all the context switching. For the managers in the room, lean in. At Meta I'd try one PR a year, but the workflows and internal tools kept changing — by the time I learned one command it changed. Now I don't even remember git commands; I ask Claude.
What becomes your new source of truth? On Claude Code, the code is the source of truth. That's why when I answer customer requests I just use desktop Claude Code with my local repositories. Having the codebase as source of truth prevents the lag of keeping documentation in sync with code. But do what makes sense for your team — if you have good specs, check them into the repositories and have Claude verify your code execution matches the spec.
How did we roll this out? There's a blend of what we mandate as team norms — gaining alignment with the team — and where I enable each pod within Claude Code to do what makes sense for them. For the must-dos, align with the teams. A few core Claude Code team principles we live and breathe — and I keep them up to date, asking every few months whether each still serves its purpose. For example, every Claude Code team member, including cross-functional partners, uses Claude Code, and we all use Cowork a lot. "Claudify everything you can" — what's better than one of us doing it is having Claude do it, so always look to automate, shift left on verification. My favorite is explicit permission to kill old processes — because processes won't kill themselves, get fast feedback on what's costing time. When I joined we did stand-ups; the team grew, so we used a spreadsheet for weekly progress; then I thought, we should make a skill — a stand-up script we run with Claude so everyone stays aware. One day it was a spreadsheet, then "does this still make sense?" Always question, defrag, and kill old processes. I leave room for pods to adapt — each team has high agency over triage, planning rituals, stand-ups, on-call, and which workflows to Claudify first. We don't mandate "thou shalt automate this"; we share suggestions and learnings but give room.
Zooming out, the three things I prioritized when I joined that made the biggest difference: keeping the team as flat as possible — managers lead pods of work but stay agile, with one overall team mission so shifts don't require re-walking everyone through new missions; "Claudify everything" frees us for harder work; and remembering that processes pile on, so work with your team to let go of the ones you should.
Does it work? I can't give explicit numbers, but three general metrics can signal success. Onboarding ramp-up time has dramatically reduced — how soon an engineer, designer, or PM becomes effective. PR cycle time shortening — worth double-clicking, since it can reveal not just AI adoption gaps but where the rest of the pipeline (like CI) struggles to scale with so much more code. Both should go down, while Claude-assisted commits should go up — by default every commit is Claude-assisted, and I haven't seen a non-Claude-assisted commit in about four months. Beyond number of commits, think about the end goal: what product are you making more delightful, what problem are you solving? You see headlines that X percent of code is AI-generated; throughput is great, but measure what you're really trying to solve. We keep an eye on quality and reliability.
My last section: audit your own effort. I still have questions. The iOS and Android org is interesting — when engineers can flex across mobile platforms more efficiently, does a traditional separate-iOS-and-Android-team structure still make sense? How much do you push fully automated review — when do you balance fast enough against losing something important? Trust but verify. And model capabilities keep improving, so even if you need more verify than trust for some work now, that might change with the next model — so always re-evaluate. Roles are blurring, so how do you make sure everyone feels equally productive? If I leave you with one thing: pick your noisiest workflow — the most expensive, or something you or your team dread — and ask if it still serves its purpose. Another funny story: a team I was on had an expensive weekly review, 50 people in a large room, everybody on their laptops except to pop up for their status report. I asked the simple question, why are we having it? And we canceled it. Always think, defrag, and see what workflow you can automate or whether it still serves its intended purpose. That's the end of our talk. Thank you for attending — I really thought this room would be empty, so thanks for not having me here by myself. I'm around today and tomorrow, so come introduce yourself. Thank you.
TL;DR
- Fiona Fung, who leads Claude Code and Cowork engineering and product, shares how the team rewrote its norms once AI shifted the bottleneck away from engineering bandwidth toward verification, review, security, and cross-functional alignment.
- Concrete changes include just-in-time planning, settling technical debates by generating multiple PRs instead of whiteboarding, doubling down on verification and "shift left" automation, and selectively trusting Claude for reviews while keeping humans for legal, security, and product taste.
- Her overarching mantra is "what served you prior may not serve you any longer" — keep a growth mindset, give pods explicit permission to kill old processes, keep the org flat, dogfood heavily, and re-audit your noisiest workflow.
Takeaways
- The bottleneck has shifted: engineering bandwidth and coding throughput used to be the expensive thing, but coding is rarely the slow part now, so bottlenecks moved to verification, code review, cross-functional partners, and security.
- Processes "quietly stop working" — teams layer on processes (e.g. stacking SLAs) but rarely retire them, so leaders need explicit permission to kill old processes and re-audit whether each still serves its purpose.
- Planning is just-in-time ("JIT planning"): a six-month roadmap became stale within months, so the team does much less pre-planning and replaces design-doc rituals with prototypes and PRs.
- In technical debates, code wins: instead of whiteboarding, generate multiple PRs (she made three) to compare not just implementations but their impact on all callers — but set culture so it's never "last check-in wins."
- Verification is the new investment area: "shift left" with more automation to catch bugs earlier so everyone, regardless of role, has higher confidence in their changes given the increased throughput.
- Trust Claude for styling, lint, PR feedback, catching/fixing bugs, and adding tests; keep humans for legal review, security and trust-boundary code, and product sense/taste (illustrated by the snowman-Claude that looked like Mr. Peanut).
- Team makeup indexes on two engineer profiles — creative builders with product sense, and deep systems experts (e.g. distributed systems for Claude Code remote) — and less on raw throughput; roles are blurring as PMs code and engineers handle content/design with Claude's help.
- Keep the org flat and scrappy: every manager starts as an IC first to dogfood and earn credibility, the code (plus checked-in specs) is the source of truth, and "Claudify everything you can," while leaving pods high agency over their own workflows.
- Signals it's working: dramatically reduced onboarding ramp-up time, shorter PR cycle time (which can also reveal CI/infra scaling gaps), and Claude-assisted commits rising to nearly 100% — but always tie metrics back to product quality and reliability, not just volume.
Vocabulary
Bottleneck shift — The move of the expensive constraint away from coding throughput toward verification, review, and cross-functional work.
Quietly stops working — When a once-useful process becomes obsolete without anyone noticing or retiring it.
JIT planning — "Just-in-time" planning: doing the right amount of planning at the right time rather than long-horizon roadmaps.
Shift left — Moving bug detection and verification earlier in the pipeline through automation, closer to the source.
Dogfooding — Heavily using your own product day-to-day to build empathy and ship better.
Routines — Automations (in Claude Code) that run on a schedule or trigger, e.g. summarizing a feedback channel each morning.
Claudify — Delegating a manual workflow to Claude wherever possible.
Source of truth — The authoritative artifact (here, the codebase plus checked-in specs) the team relies on over separate docs.
Pod — A small sub-team within Claude Code given agency to adapt its own rituals and workflows.
Trust but verify — Relying on Claude for much of the work while keeping human experts in the loop for high-risk areas.
Transcript
Hey folks, do you hear me okay? I swear this isn't a Claude Code thing, but do you mind if I take a photo? Boris and Jared had their session at 2:00 and I really thought this would be empty — there's no way people would still be coming from that session. Thank you. I promise Boris and I don't just do selfies all the time. Good afternoon and thanks for attending. My name is Fiona Fung and I lead Claude Code and Cowork engineering and product, so I work closely with Boris and Cat. Before Anthropic I led and grew teams at Meta and Microsoft. Today's talk is about some lessons I learned helping Claude Code and Cowork grow as we build out this team — lessons that apply across my time at Meta, Microsoft, and Anthropic. It's funny, I made this deck about a month ago and already had to change content; when I started it, there were no routines, and that way of working was different for me.
I want to cover five themes I've noticed. One is that the bottlenecks have shifted. When bottlenecks shift, what team norms did we have to rewrite within the Claude Code team? I'll share those norms, how we rolled them out, and what signals tell me we're trending in the right direction — and it's always important to ask: is it still serving us? I'll end with a few questions I still have, and suggestions for actions to take back to your teams.
First, the shift. You'll hear me repeat this subtitle: what served you prior may not serve you any longer. A constant growth mindset is a muscle that has served me well, especially now when the rate of change is a little crazy. The first time I did live coding was last year, and it was still making bugs — using constants everywhere, not good engineering practice — and now it's become so much more capable. For years, engineering bandwidth was the expensive thing; coding throughput was expensive, and a lot of our software-shipping processes were built around that — even how we did planning, from waterfall to agile.
This isn't the first time our industry has had to adapt. Come back with me to the 2000s, when I started my career working on Visual Studio, shipping VS 2005. In those days we shipped software on CD-ROMs — before that, floppy disks. We had hard deadlines because we had to get the software to the manufacturing lab to print the CDs, put them in boxes, and ship to stores. When we could distribute software online, that changed how we ship. Now the new shift is that engineering bandwidth is no longer the expensive thing. On the Claude Code team, coding is rarely the slow part, and the throughput has really increased — it's not only that we get to build more, the amount we're generating has changed a lot.
When your bottleneck shifts away from the act of typing — writing code, writing tests, refactoring used to be expensive, and we'd schedule time for refactoring — that's no longer the bottleneck. Bottlenecks then shift to other areas: verification, review, cross-functional partners, security. Is this code correct? Who reviews it? That's one of the top questions I get from fellow eng leaders: how are humans keeping up with code reviews, and how is it maintained, since it's now much easier to generate a lot of code, so think about maintenance cost too.
These are processes that quietly stop working — I love that phrase. We put processes in for a reason, thinking there's a gap or we want to improve, but rarely do processes kill themselves; we tend to layer more and more on. On one team we had so many SLAs — a P0 bug SLA, a high-pri review SLA — that I had to stack-rank priorities so engineers knew which SLA mattered more. The planning norms, code ownership ("who wrote this, who owns it?"), code reviews, team makeup as roles blur (non-engineering partners are also shipping code), and knowledge sharing and onboarding — all of these are changing.
So what norms did we rewrite on the Claude Code team? Number one is code review — human judgment of who actually needs it. Onboarding changed, planning changed, hiring changed especially with roles blurring, and org shape — one of my favorite spicy topics; I'll share the story of proposing that at Anthropic, where one recruiting partner thought I was crazy.
How has planning changed? We do a lot less of it, and the timing matters — I call it JIT planning, like JIT compiling. When I first joined I thought we needed a six-month roadmap; we wrote one, it was good for three months, and after the new year so many things had changed that six months seemed too long. Do the right amount at the right time, because prototyping and code generation are no longer the bottleneck. Technical debates are a fun one: code wins. When I first joined, I wanted to do a refactoring to learn the codebase, and Boris and I had a healthy technical debate. I almost reached for my old toolbox — tap him on the shoulder, go to a room and whiteboard — then realized I can just generate all the options. I generated three PRs. The cool part is I cared about both the implementation of the API and the impact on all the callers, and generating three versions let us debate implementation and impact. When building is cheap, arguing is expensive — but this makes team culture for alignment even more important. What won't fly is "last person to check in wins" — I'm not going to stay up to submit a PR or set up a routine to get the last word. You need open, honest technical debates and good alignment.
On planning we reduced the design-doc-before-every-code ritual. For certain teams and async discussions, design docs are still important, but on Claude Code most discussion is a PR instead of a doc: "we found an idea, go prototype." We don't do many product reviews because the landscape changes fast — let's prototype, get internal folks using it, ship to all of you, and hear the feedback. What did we double down on? Verification — an area we need to keep getting better at, because throughput is different and there are new ways to break. I call it shift left: more automation so we catch bugs earlier, closer to the source. Because roles are blurring, my designers want confidence that their checked-in code doesn't break something. I once fixed a bug in resume and the next day saw someone flag a bug to Boris — that sinking feeling. Regardless of role, I want everyone to have higher confidence in their changes.
"Who made this change?" is now an odd question since our PRs are Claude-assisted. What's more helpful is double-clicking into it: what are you really trying to answer? Are you looking for who caused a regression — not to blame, but to know who last touched it? An expert to answer a customer question? Context? Then think about whether you can automate it. When I started this talk a month ago, every morning I'd open desktop Claude Code, go into the customer feedback channel, and ask it to summarize with my morning coffee. Now it's a routine — even better than before. Code ownership is fuzzier, but double-click to the real question and see how Claude can help.
How do you keep up with code reviews? As Cat showed in the keynote, we lean heavily on Claude code review. The interesting part is where you trust Claude a lot versus where you still want a human. Claude does a great job babysitting PRs — handling styling, lint, PR feedback, catching and fixing bugs before a full commit, and adding tests. Where I still want a human is expertise — trust but verify. Legal review: I want my legal partner. Risk tolerance, trust boundaries, and security-sensitive code: pull in the experts. And product sense and taste — I like to decorate Claude for the holidays; I asked Claude Code to turn Claude into a snowman, but it wasn't great at ASCII art then, and my design partner said I'd turned Claude into the Mr. Peanut character. So I made it simpler — ice blue with a snowflake. Keep product sense in mind.
That leads to team makeup. Because roles are blurring and Claude is augmenting, on Claude Code I index heavily on two engineer profiles. One is creative builders with product sense — the dreamers, curious, passionate about shipping a product that solves a problem, with lots of iteration for a delightful experience. The other is deep systems expertise. When I joined, we were good with product generalists and creative folks but missing distributed-systems expertise, which you need when building things like Claude Code remote to run Claude everywhere. Think about the hard parts where you want to double down. I index less on raw throughput, since thanks to the models we're much more efficient. Cross-functional gaps are interesting too: I wanted to update our survey responses but didn't have a content designer, and my writing is terrible at being short and succinct — every line in the terminal matters. Claude augmented that content-design role for me. On the flip side, our PMs code a lot, which is fun. Non-traditional coders do more engineering, and engineers lean into content or design work. Claude has augmented roles all around.
Org shape was a spicy one. When I joined, recruiters used the typical 10 ICs to one manager and nesting. I leaned into keeping it scrappy. Across Anthropic, Meta, and Microsoft — Visual Studio, Facebook Marketplace, AR/VR, Claude — what helped me ship great product is heavy, heavy dogfooding. For leaders, nowadays it's fun because I can still be in the code; for a while you couldn't, and when you can't, make time to use your product day in and day out. That's why I wanted every manager in Claude Code to start as an IC first — to earn street cred and learn to be an effective engineer. I structured the org as flat as possible to stay agile. My recruiters had concerns: "You want to hire managers who start as ICs first? No manager would be interested." But that's what dogfooding on Claude Code is about, and if someone's not interested, earlier separation is better. Without Claude I wouldn't have been able to ramp or code, given all the context switching. For the managers in the room, lean in. At Meta I'd try one PR a year, but the workflows and internal tools kept changing — by the time I learned one command it changed. Now I don't even remember git commands; I ask Claude.
What becomes your new source of truth? On Claude Code, the code is the source of truth. That's why when I answer customer requests I just use desktop Claude Code with my local repositories. Having the codebase as source of truth prevents the lag of keeping documentation in sync with code. But do what makes sense for your team — if you have good specs, check them into the repositories and have Claude verify your code execution matches the spec.
How did we roll this out? There's a blend of what we mandate as team norms — gaining alignment with the team — and where I enable each pod within Claude Code to do what makes sense for them. For the must-dos, align with the teams. A few core Claude Code team principles we live and breathe — and I keep them up to date, asking every few months whether each still serves its purpose. For example, every Claude Code team member, including cross-functional partners, uses Claude Code, and we all use Cowork a lot. "Claudify everything you can" — what's better than one of us doing it is having Claude do it, so always look to automate, shift left on verification. My favorite is explicit permission to kill old processes — because processes won't kill themselves, get fast feedback on what's costing time. When I joined we did stand-ups; the team grew, so we used a spreadsheet for weekly progress; then I thought, we should make a skill — a stand-up script we run with Claude so everyone stays aware. One day it was a spreadsheet, then "does this still make sense?" Always question, defrag, and kill old processes. I leave room for pods to adapt — each team has high agency over triage, planning rituals, stand-ups, on-call, and which workflows to Claudify first. We don't mandate "thou shalt automate this"; we share suggestions and learnings but give room.
Zooming out, the three things I prioritized when I joined that made the biggest difference: keeping the team as flat as possible — managers lead pods of work but stay agile, with one overall team mission so shifts don't require re-walking everyone through new missions; "Claudify everything" frees us for harder work; and remembering that processes pile on, so work with your team to let go of the ones you should.
Does it work? I can't give explicit numbers, but three general metrics can signal success. Onboarding ramp-up time has dramatically reduced — how soon an engineer, designer, or PM becomes effective. PR cycle time shortening — worth double-clicking, since it can reveal not just AI adoption gaps but where the rest of the pipeline (like CI) struggles to scale with so much more code. Both should go down, while Claude-assisted commits should go up — by default every commit is Claude-assisted, and I haven't seen a non-Claude-assisted commit in about four months. Beyond number of commits, think about the end goal: what product are you making more delightful, what problem are you solving? You see headlines that X percent of code is AI-generated; throughput is great, but measure what you're really trying to solve. We keep an eye on quality and reliability.
My last section: audit your own effort. I still have questions. The iOS and Android org is interesting — when engineers can flex across mobile platforms more efficiently, does a traditional separate-iOS-and-Android-team structure still make sense? How much do you push fully automated review — when do you balance fast enough against losing something important? Trust but verify. And model capabilities keep improving, so even if you need more verify than trust for some work now, that might change with the next model — so always re-evaluate. Roles are blurring, so how do you make sure everyone feels equally productive? If I leave you with one thing: pick your noisiest workflow — the most expensive, or something you or your team dread — and ask if it still serves its purpose. Another funny story: a team I was on had an expensive weekly review, 50 people in a large room, everybody on their laptops except to pop up for their status report. I asked the simple question, why are we having it? And we canceled it. Always think, defrag, and see what workflow you can automate or whether it still serves its intended purpose. That's the end of our talk. Thank you for attending — I really thought this room would be empty, so thanks for not having me here by myself. I'm around today and tomorrow, so come introduce yourself. Thank you.