Managing Engineering Teams in the AI Era: Rethinking Processes, Structure, and Metrics

Industry Reshaped Twice in Twenty Years

Fiona begins by recalling the early 2000s when she worked on Visual Studio 2005 at Microsoft, when software was distributed on CDs and development cost was dominated by writing code, testing, and refactoring. The rise of the Internet changed distribution, and now AI is changing the very act of coding.

“What served you prior may not serve you any longer.”

She argues that many legacy processes were built on the assumption that code is expensive; with AI‑generated code becoming virtually free, those processes must be rebuilt.

New Bottlenecks: Verification, Review, Collaboration, and Safety

The Claude Code team now faces bottlenecks in verification, code review, cross‑functional collaboration, and security. When code volume grew, the most common question became, “How can we review all these PRs?” and concerns about maintenance cost emerged.

She lists outdated processes that are silently failing: half‑year product roadmaps, cumbersome scheduling meetings, strict code‑ownership rules, marathon review sessions, hierarchical team structures, knowledge‑base sharing, and long onboarding programs.

“Rarely do processes kill themselves; we tend to just layer more and more processes on.”

Example: an SLA spreadsheet was used to prioritize work, but she eliminated it after joining Anthropic.

What to Stop Doing: Six‑Month Roadmaps, Design Docs, Product Reviews

She replaced long‑term roadmaps with “just‑in‑time planning,” arguing that prototype cost is near zero, so upfront planning loses leverage. Design documents are now replaced by opening a PR directly; product review meetings are reduced because the product evolves too quickly, and instead the team pushes internal builds to the whole company for feedback (a practice she calls “ant‑fooding”).

What to Do More: Shift‑Left Verification

Fiona pushes the team to invest heavily in early‑stage verification, moving quality assurance from the delivery end toward the source. As roles blur—designers submit code and engineers write content—the need for automated safety checks grows.

She shares a personal anecdote: after fixing a bug related to job‑search resumes, she anxiously checked a colleague’s message stream for new bugs, illustrating the high‑stakes pressure of rapid code throughput.

Technical Debates Evolve: From Whiteboards to Three PRs

Instead of drawing architecture on a whiteboard, the team now lets Claude generate three PR variants simultaneously, compare their impact on APIs, and discuss concrete code differences. This reduces costly, endless debates when code generation is cheap.

“When building is cheap, arguing is expensive.”

She warns that code ownership questions become meaningless when AI participates in every PR.

Claude‑Assisted Code Review: What to Automate, What to Keep Human

Claude handles style checks, linting, responding to review comments, catching common bugs, and generating unit tests. Human review remains essential for legal/compliance checks, security‑sensitive code, and product‑sense judgments that models still struggle with.

“The model is great at the dirty work, but we still need humans for legal, security, and intuition.”

She illustrates the point with a light‑hearted story about decorating Claude’s terminal for Christmas, showing that aesthetic decisions still require human sense.

Blurring Role Boundaries

Almost every PR now includes Claude, making the question “who wrote this code?” absurd. Fiona suggests focusing on who can answer the underlying bug, who has the context to explain technical details, and who knows the module history. Automation can answer many of these questions.

She notes that non‑technical staff now submit PRs (e.g., PMs), while engineers take on tasks traditionally done by designers or content writers.

Flat Organization and Managers as ICs

Anthropic initially used a 10‑engineer‑to‑1‑manager ratio, but Fiona advocates a flatter structure with a single mission for both Claude Code and Cowork lines. All managers must start as individual contributors; otherwise, they part ways early.

“If someone isn’t willing to start as an IC, it’s better to separate early.”

She admits she no longer remembers git commands and relies on Claude for them.

Code as the Sole Source of Truth

The team treats code as the ultimate source of truth, using Claude to answer technical support questions directly from the repository, eliminating the chronic mismatch between documentation and implementation.

If a project requires formal specs, they are stored in the codebase and cross‑checked by Claude.

Observable Metrics and a Warning

Three key metrics are tracked: dramatically reduced onboarding time, shorter PR lifecycle, and an increasing proportion of Claude‑assisted commits (she hasn’t seen a non‑Claude commit in four months). She warns against obsessing over the percentage of AI‑generated code; the real goal is product quality and reliability.

Open Questions

Does the traditional split between iOS and Android teams still make sense when engineers can work across platforms?

How far should automated review be trusted? The “trust but verify” boundary will shift as models improve.

How to maintain a sense of ownership and fairness when roles blur and everyone contributes to multiple outputs?

Final Advice

Identify the noisiest workflow, question whether it still serves anyone, and prune it.

“Pick your noisiest workflow… is it still really serving, what’s the purpose of there.”

She illustrates this by canceling a weekly meeting of 50 people that had become a keyboard‑staring session, dissolving it after asking, “What are we really trying to achieve?”