Running an AI-native engineering org
Fiona Fung, who leads Claude Code and Cowie engineering, shares lessons learned from scaling the team in an AI-augmented development environment. She explains that engineering bandwidth is no longer the bottleneck—verification, review, and cross-functional collaboration are—and outlines new norms around planning, code review, and team structure. The key takeaway is to constantly question old processes, 'Claudify' everything possible, and keep the team flat and agile.
Key points
Detailed summary
Speaker Introduction & Context
Fiona Fung leads Claude Code and Cowie engineering and product, working closely with Boris and Cat. She previously led teams at Meta and Microsoft. Her talk covers lessons learned helping Claude Code and Cowie grow, and building out the team.
Agenda Overview
Five themes are covered: bottlenecks have shifted, team norms rewritten, how norms were rolled out, proof the team is trending right, and unanswered questions. A recurring phrase is "What served you prior may not serve you any longer." A constant growth mindset is described as a muscle that has served her well, noting the rate of change is "a little bit crazy."
Historical Context: Engineering Bandwidth Shift
For years, engineering bandwidth was the expensive thing, and software shipping processes were built around that assumption. Fiona gives an analogy of shipping Visual Studio 2005 on CD-ROMs with hard manufacturing deadlines. When distribution moved online, shipping changed. Now, engineering bandwidth is no longer the expensive thing.
Current State on Claude Code Team
Coding is rarely the slow part anymore; throughput has increased dramatically. Old bottlenecks (writing code, tests, refactoring) have shifted. New bottlenecks are verification, review, cross-functional partners, and security. Key questions now are "Is this code correct? Who reviews this code?" Maintenance cost is a concern because it's easier to generate a lot of code.
Processes That 'Quietly Stop Working'
Processes rarely kill themselves; teams tend to layer more processes on. Fiona gives an example of a team with so many SLAs they needed to stack-rank priorities. Specific processes that may no longer serve include planning norms, code ownership, code reviews, team makeup (roles blurring), and knowledge sharing.
Norms Rewritten on Claude Code Team
Norms rewritten include code review, onboarding, planning, hiring, org shape, and technical debates.
Planning Changes
The team does a lot less planning—described as "JIT planning, almost like JIT compiling." A six-month roadmap was good for three months but then too many things changed. The principle is to do just the right amount at the right time because prototyping and code generation are no longer bottlenecks.
Technical Debates: 'Code Wins'
Fiona shares a story of a technical debate with Boris where instead of whiteboarding, she generated three PRs to compare options. The key insight: "When building is cheap, arguing expensive." However, it shouldn't be that the last person to check in wins; good team culture for open, honest debates is needed.
Reduced Design Docs, Increased Prototyping
On Claude Code, design docs before every code ritual are reduced. Most discussions happen via PRs instead of docs. The team motto is "Hey, we found an idea, go prototype." They don't do a lot of product reviews because the landscape changes fast; they prototype, get internal users, then ship to all users for feedback.
Doubling Down on Verification
Verification needs more focus because throughput is different and there are new ways to break. The concept of "shift left" means more automation to catch bugs earlier. Because roles are blurring, designers need confidence that their code doesn't break something. The goal is to give everyone higher confidence for their changes.
Code Ownership & 'Double Clicking'
The question "Who made this change?" is odd because PRs are assisted by Claude. Instead, double-click into what question you're really trying to answer: who caused a regression? Looking for an expert? Gaining context? Automate where possible. Fiona changed her workflow from manually summarizing customer feedback to using routines.
Code Reviews: Human vs. Claude
Claude handles styling, lint, PR feedback, catching bugs, and adding tests. Humans are still needed for expertise (trust but verify), legal review, risk tolerance areas (trust boundaries, security), and product sense/taste. Fiona shares a story about asking Claude to turn Claude into a snowman—Claude wasn't good at ASCII art, so a design partner gave feedback.
Team Makeup: Two Engineer Profiles
Two profiles heavily indexed on: creative builders with product sense (dreamers, curious, passionate) and deep systems expertise (e.g., distributed systems for Claude Code remote). Less indexed on: raw throughput, because models make that efficient.
Cross-Functional Gaps & Role Augmentation
Fiona wanted to update survey responses but didn't have a content designer. Claude augmented that role. On the flip side, PMs code a lot. Non-traditional coders can now do more engineering, and engineers can lean into content or design. Claude and AI have augmented roles all around.
Org Shape & Hiring Philosophy
Fiona kept the org scrappy and flat. She believes heavy dogfooding helps ship great product. For leaders, it's fun to still be in the code. She wanted every manager to start as an IC first to earn street cred. Recruiters were skeptical, but Fiona held firm. She notes that Claude helps her ramp and context-switch. She encourages managers to lean in.
New Source of Truth
On Claude Code, the code is the source of truth. When answering customer requests, Fiona uses desktop Claude Code with the local repository. This prevents lag between documentation and code. Advice: do what makes sense for your team; if you have good specs, check them into repositories and have Claude verify code execution matches the spec.
Rollout Approach
The approach blends mandates and enabling pods: align on must-dos, then let each pod do what makes sense. Core principles are lived and breathed, and updated every few months. Every Claude Code team member, including cross-functional partners, uses Claude Code.
Key Principles and Strategies
"Claudify everything you can"—ask what's better than one of us doing it? Have an automation mindset, constantly ask if Claude could help. Give explicit permission to kill old processes; get fast feedback on what the team spends time on. Example: moving from stand-ups to a spreadsheet to a Claude-run stand-up script, then questioning the spreadsheet's purpose. Always defrag and kill old processes. Give pods high agency for triage, planning, stand-ups, and which workflows to Claudify first.
Three Key Priorities
Metrics for Measuring Success
Onboarding ramp-up time has dramatically reduced. PR cycle time shortening can identify gaps like CI struggling with volume. Cloud-assisted commit rate should go up—on their team, every commit is cloud-assisted. End goal: measure what you're actually trying to solve (e.g., quality and reliability), not just percentage of AI-generated code.
Open Questions and Areas for Audit
Organizational structure: does traditional iOS/Android team structure still make sense? Balancing automation and review: how much to push fully automated review? Model capabilities improve, so re-evaluate. Blurring roles: how to ensure everyone feels equally productive?
Final Takeaway and Anecdote
Pick your noisiest workflow—the most expensive, dreaded, or unappealing task. Ask if it still serves its purpose. Fiona shares a story of a weekly review with 50 people where everyone was on laptops; by asking why they were having it, the meeting was canceled. Look at one piece of workflow and consider if you can automate it or if it's still serving its intended purpose.
Closing Remarks
Fiona thanks the audience and will be around for the day and tomorrow to chat further.
Transcript
Summarize your own video
Paste any YouTube link and get a TL;DR, key points and the full transcript like this one — in seconds.