💡

InsightHunt

Hunt the Insights

C

Camille Fournier

Episode #47

Author & Tech Executive

Various (formerly Two Sigma, Rent the Runway, Goldman Sachs)

👥Team & Culture🎯Product StrategyExecution

📝Full Transcript

15,460 words
Lenny Rachitsky (00:00:00): I'm curious what it is that PMs do that annoy engineers most. Camille Fournier (00:00:04): Hoarding credit. PMs, they tend to be the front-facing person for initiative. Engineers sometimes think that they don't get the credit for their work because the PM takes all the glory and all the credit for the project that they really worked very hard on. Lenny Rachitsky (00:00:19): I find the best PMs are the ones that talk the least and encourage other people to do the presenting- Camille Fournier (00:00:23): The next thing that engineers really get annoyed about with PMs, when they just don't understand the details and act like they don't matter, it just shows a real lack of empathy for the work that engineers are doing and I think it really can be very off-putting. Lenny Rachitsky (00:00:34): Is there any insight you can give about what people may be missed about the motivation of engineers, what gets them excited? Camille Fournier (00:00:40): A lot of people assume that engineers just write code and don't underestimate the ability for your engineers to want to understand the business problem, want to understand the customer problem. I think the product managers that have done the best, they're not threatened by other people having ideas. Lenny Rachitsky (00:01:00): Today, my guest is Camille Fournier. Camille is one of the most respected technology executives in tech and the author of the Manager's Path, which many considered the definitive guide for navigating your career and moving into management. Over the course of her career, she was CTO of Rent The Runway, VP of technology at Goldman Sachs, global head of engineering and architecture at JP Morgan Chase and head of platform engineering at Two Sigma. She's also releasing a new book later this year called Platform Engineering, A Guide for Technical Product and People Leaders, which you can actually pre-order today and we get into this topic in the latter half of the conversation. (0...

💡 Key Takeaways

  • 1PMs annoy engineers most by hoarding credit, ignoring technical details, playing 'telephone' between stakeholders, and hoarding ideation.
  • 2When PMs hoard product ideation, engineers often seek creative outlets by over-engineering the technical stack.
  • 3Rewrites are usually a trap; the complexity lies in the data migration and hidden legacy logic, not the new code construction.
  • 4If a legacy system is stable and doesn't require new features, it is almost never worth the cost of a rewrite.
  • 5Effective Platform Engineering requires a product mindset; if a platform team lacks a PM, the consumer (you) must product manage them.
  • 6Engineering leaders should not move into management until technical mastery is 'in their bones' (often ~10 years of practice).
  • 7Reduce meeting bloat by stopping 'maintenance' one-on-ones with stakeholders; rely on project-based collaboration instead.
  • 8Platform teams should only be formed once an organization hits 50+ engineers and faces scaling inefficiencies.

📚Methodologies (3)

👥 Team & Culture

A behavioral framework for PMs to build trust with engineering teams by distributing ownership and removing communication bottlenecks. It posits that engineers who feel heard on product strategy are less likely to overcomplicate technical decisions.

Core Principles

  • 1.Share the Glory: Step back during presentations and let engineers present the work they built; do not be the sole face of the initiative.
  • 2.Involve Engineers in Ideation: Allow engineers to contribute to product problem-solving. If you block their creative input on product, they will use code architecture as their creative outlet (leading to over-engineering).
  • 3.Stop Playing Telephone: If you cannot answer a technical question, do not mediate the answer. Connect the stakeholder directly to the engineer to avoid translation errors.
  • +1 more...

"When you take the people that are part of the project team out of the creative loop entirely, they're going to find that creative outlet somewhere else and it's actually kind of bad for the product."

#anti-friction#engineering#partnership
View Deep Dive →
The Rewrite Viability Audit

by Camille Fournier

🎯 Product Strategy

A decision-making heuristic to evaluate if a system rewrite is necessary. It shifts the focus from 'how hard is it to build the new thing' to 'how hard is it to migrate the old thing.'

Core Principles

  • 1.The Migration Multiplier: Recognize that migrating users/data from the old system takes significantly longer than building the new system.
  • 2.The 'Do Nothing' Test: Ask, 'If we didn't touch this system for a year, would it harm the business?' If the answer is no, do not rewrite it, even if the code is ugly.
  • 3.The Hidden Logic Assessment: Acknowledge that legacy systems contain undocumented business rules and data formatting logic that will be lost or broken in a rewrite.
  • +1 more...

"Engineers notoriously, notoriously, notoriously, massively underestimate the migration time for old system to new system."

#rewrite#viability#audit
View Deep Dive →
Execution

A framework for structuring and interacting with internal platform teams. It treats internal infrastructure as a product that requires customer discovery, adoption metrics, and stakeholder management.

Core Principles

  • 1.Staff for Software, Not Just Ops: Platform teams must include software engineers to build scalable tools, not just SREs or SysAdmins.
  • 2.Mandatory Product Management: Internal platforms need PMs to define the 'what' and 'why.' If a platform team lacks a PM, the consuming team must step in to 'product manage' them.
  • 3.Harvest, Don't Invent: The best platform features often start as solutions built by individual application teams. The platform team should 'harvest' these proven solutions and scale them, rather than inventing from zero.
  • +1 more...

"Platforms are products, ultimately. You should be thinking about how do I create coherent offerings that make this company more productive?"

#platform-as-product#operating#execution
View Deep Dive →