Key Takeaways

  • AI tools like Claude now automate daily manager routines, transforming oversight from manual tracking to an agent-assisted process for generating feedback and even pull requests.
  • Engineering managers at high-velocity teams, like Fiona Fung's at Anthropic, shift into a "player-coach" model, staying hands-on as individual contributors (ICs) to keep their product intuition sharp.
  • Quality assurance moves to proactive measures, distinguishing between critical, irrecoverable errors ("Bad") and painful but recoverable user experiences ("Sad") before they escalate.
  • This approach gives high agency to engineering teams, letting them define what "bad" and "sad" mean for their specific services, which builds ownership over product health.
  • The core of this quality shift is the "Bad vs. Sad" Proactive Quality Framework, which helps rapidly moving teams prioritize fixes and prevent degradation.

The "Bad vs. Sad" Proactive Quality Framework

Here's how Fiona Fung's team uses this framework:

  • Define "Bad": Identify truly bad, irrecoverable errors or critical failures (e.g., CLI crashes, data loss). Each team defines what constitutes "bad" for their specific surface areas or services.
  • Define "Sad": Identify pain points that are recoverable but diminish the user experience (e.g., flickering UI, slow load times that don't crash). Stacking "sads" can lead to "bad" experiences.
  • Monitor Trends: Track "bad" and "sad" metrics over time to proactively detect quality degradation and identify hot spots.
  • Prioritize Fixes: Focus on addressing "bad" experiences immediately while continuously working to reduce "sad" points.
  • Empower Teams: Give high agency to each team to define what constitutes "bad" and "sad" for their domain and set goals for improvement.

AI: Your Co-Pilot Manager

Fiona Fung, who leads the Claude Code and Co-work teams at Anthropic, has seen AI fundamentally change the daily grind for engineering managers. Gone are the days of manually tracking every commit or sifting through logs to offer feedback. Now, AI takes over.

“I just have a routine that automates all this for me,” Fung says, explaining how Claude now provides visibility into code output, analyzes feedback, and even generates pull requests. This automation frees up managers to focus on deeper conversations, not just tracking output. As Lenny Rachitsky points out, AI helps managers “keep on top of all the things people are shipping and then make that a conversation with them.”

Fung explains her team uses Claude not just to automate tasks, but as an agent that helps generate prompts and even PRs. This shift means managers can spend less time on rote oversight and more time on market impact, user experience, and preventing issues.

The Player-Coach Manager

Even with AI handling more, the manager's role isn't obsolete. Instead, it evolves into a "player-coach" model. Managers still act as individual contributors (ICs), keeping their hands in the code and product to maintain intuition. This prevents a growing divide between AI-native and non-AI-native professionals, and keeps managers deeply connected to the work.

Fung emphasizes the importance of this hands-on approach: “making every manager start as an IC first without a like worry of supporting people... give yourself that maker time to actually type deep into the code and learn the code base or or the product.” This means staying close to the product, understanding the nuances only found by building it, and ensuring that strategic decisions are grounded in real-world knowledge, even as AI takes on more of the daily grunt work.

When This Works (and When It Doesn't)

This framework thrives in high-velocity development environments where teams iterate fast and traditional bug tracking can become a bottleneck. It's particularly useful for product-led companies receiving constant user feedback, allowing them to categorize and act on issues beyond raw performance numbers. By empowering teams to define "Bad" and "Sad" for their specific domain, it fosters strong ownership over quality.

The framework might be less critical for very small teams (say, fewer than five people) where quality issues are often immediately apparent and discussed informally. Similarly, in highly regulated industries or safety-critical systems, every "sad" might carry a "bad" level of risk, making the distinction less relevant than strict adherence to protocol and exhaustive testing.

What to Do With This

This week, apply the "Bad vs. Sad" framework to your own product. Imagine you run a SaaS startup with a rapidly growing user base, and you're starting to get mixed feedback: some glowing reviews, but also persistent complaints about specific quirks and occasional critical errors.

Call a short, focused meeting with your engineering or product leads. First, define the specific "Bad" errors: What are the absolute showstoppers? (e.g., the app crashes 5% of the time for new users, data is occasionally lost during a specific workflow, payment processing fails for 1% of transactions). Next, outline the "Sad" pain points: What are the frequent annoyances that don't break the app but diminish the experience? (e.g., the dashboard loads slowly for 10% of users, a specific UI element flickers, complex reports take too long to generate, error messages are unhelpful).

Assign specific teams or individuals to monitor these "Bad" and "Sad" metrics, tracking their frequency and impact. Prioritize immediate fixes for all "Bad" issues. Then, set a clear, quantifiable goal to reduce the top three "Sad" experiences by 50% over the next month. Empower the relevant teams to own these definitions and improvement goals, reporting back weekly on progress. This gives them agency and aligns everyone on tangible quality improvements, not just feature delivery.