My biggest takeaways from Claude Code/Cowork lead @Nerdi_Yogi:
1. When your engineers ship 8x more code than a year ago (like they do at Anthropic), the biggest problem becomes verification. How do you know that the experience you shipped is what you intended? One tactic Fiona’s team uses is a “bad vs. sad” tracking framework: bad is unrecoverable errors (like a crash), sad is a recoverable pain point (like flickering or drop in conversation). They give each team agency to build and ship quickly, but they track bad and sad events for their surface areas to quickly identify issues.
2. As engineers increasingly work independently with their own teams of agents, loneliness is emerging as a challenge for engineers. To help, Fiona’s team started “pairwise programming lunches,” where engineers work side by side, not necessarily on the same thing, and pick up new patterns by watching how others use Claude Code and Cowork.
3. Anthropic built a dashboard that counts how often users swear at Claude Code. Back in September, amid visible user frustration, an engineer suggested tracking swear words, and Fiona loved it. It’s become a proxy for things evals struggle to capture: whether the experience is actually delightful, not just technically accurate.
4. Look for latent demand to discover new business opportunities. Cowork emerged when the team noticed that non-coders were using Claude Code for tasks like analyzing MRIs or recovering wedding photos. That signal—people jumping through hoops to make something work with your product—tells you there’s something there.
5. Fiona’s team has shifted from six-month roadmaps to just-in-time monthly planning. She tried doing lightweight six-month roadmaps when she joined Claude Code, but a few months in, she realized her team had barely referenced them. Now they do monthly planning on a simple spreadsheet with a simple list of this month’s priorities.
6. One of Claude Code’s cultural values is: you have permission to kill any process that isn’t working. Fiona brought in six-month planning from her previous experience, then killed it herself when it wasn’t serving the team. Always ask: is this process still serving its purpose?
7. Another core principle: “What’s better than me doing it? Having Claude do it.” This pushes everyone to keep checking whether a task can be automated—even writing the post that announces a model launch. Fiona admits that after decades of shipping software by hand, she still has to remind herself to ask it.
8. When Fiona hires managers, they have to start as individual contributors. This gives them time to learn the codebase, build rapport with the team, and understand what it’s like to be an engineer on the team before taking on management responsibilities. It prevents the trap of immediately reaching for your “manager toolbox” instead of learning the specific context.
9. Fiona uses “routines” to automate her daily rituals as a manager. She used to read user feedback channels over coffee and hand-pick fixes to assign teammates, Now a Claude “routine” runs every morning, kicking off agents that analyze feedback across multiple channels, identify themes, and generate PRs to address issues. Her prediction is that work is shifting from manual synchronous prompting to asynchronous agent management (i.e. loops).
10. Culture, not code, is what keeps her up at night. To Fiona, culture is a living thing, not a poster on a wall. Her nightmare is the manager who says, “everything’s fine” while the room is on fire. She pushes hard for open talk about what’s not going well, because that’s the only way the team can fix it together.
