Sep 15, 2024 · 1h 23m · lennys-podcast
The things engineers are desperate for PMs to understand | Camille Fournier (“The Manager’s Path”)
0:00 / 0:00
▶ Watch on YouTube →
gold bands on the timeline = statements, start to end. Hover to read, click to jump. CC turns on captions
Technology executive and author Camille Fournier joins Lenny Rachitsky to discuss resolving friction between engineers and product managers, navigating engineering management transitions, and scaling internal platform teams effectively.
How this conversation actually went
Every chapter scored 0–10 on four independent dynamics. Hover any point for the reasoning behind the score. Lenny holds 24.8% of the talking time here. How this is scored →
Lenny as informed peer 3.2 Guest teaching 3.9 Guest disagreement 1.7 Lenny pushing back 0.6
speaking balance: gold is Lenny, purple is the guest (3 minute bins)
Sharpest disagreement ▶ 41:10 Camille rejects the modern culture of endless one-on-ones
Camille rejects the widespread belief that more one-on-ones build better organizations, arguing that peer and stakeholder one-on-ones are unscalable, performative, and ineffective.
Hardest push from Lenny ▶ 54:15 Lenny challenges platform teams on velocity and ROILenny directly confronts Camille with a sharp critique from a product colleague about platform teams receiving infinite funding without demonstrating tangible business ROI.
Biggest teaching moment ▶ 15:50 Camille exposes the hidden trap of software rewritesCamille provides a detailed, technical explanation of why engineering rewrites fail, demonstrating how teams consistently underestimate migration complexity and undocumented legacy logic.
Lenny holds their own ▶ 19:42 Lenny parallels technical rewrites to product redesign failuresLenny demonstrates deep product expertise by drawing an exact parallel between engineering rewrite failures and zero-baseline product redesigns that fail negative experiments.
the scores for every segment, with the reasoning behind each
| Chapter | Topic | Lenny as informed peer | Guest teaching | Guest disagreement | Lenny pushing back | Why |
|---|---|---|---|---|---|---|
| Episode Preview: Engineering Grievances with Product Managers | 0 | 0 | 0 | 0 | Monologue preview and podcast introduction outlining Camille Fournier's career background and the episode's themes. | |
| Key PM Behaviors That Frustrate Engineers: Credit and Technical Details | 2 | 4 | 2 | 0 | Lenny opens by asking what PMs do that frustrates engineers. Camille breaks down credit hoarding and dismissing technical details as major pain points. | |
| Sponsor Message: DX Engineering Intelligence Platform | 0 | 0 | 0 | 0 | Host sponsor read for DX engineering intelligence platform and CommandBar. | |
| The Dangers of Playing Telephone and Hoarding Product Ideas | 3 | 5 | 2 | 1 | Camille outlines the dangers of PMs playing telephone and gatekeeping product ideation, which causes engineers to over-engineer to find creative outlets. | |
| Tactics for Collaborative Ideation and Balanced Communication | 4 | 4 | 1 | 1 | Lenny and Camille discuss practical solutions for collaborative ideation and bridging communication between engineers without cluttering calendars. | |
| Why Massive System Rewrites Are Frequently Dangerous Traps | 5 | 6 | 2 | 0 | Camille gives a detailed breakdown of why major system rewrites are dangerous traps, emphasizing migration time and undocumented logic. Lenny validates this by comparing it directly to product redesign failures. | |
| Navigating Hands-on Technical Mastery versus Engineering Leadership | 5 | 5 | 2 | 2 | Camille explains how leaders can stay technically credible without micro-managing tools. Lenny pushes the discussion forward by bringing up Pieter Levels' success using simple PHP/jQuery, prompting Camille to differentiate solo productivity from organizational scale. | |
| Evaluating Technological Fads and the Pitfalls of GraphQL | 4 | 4 | 3 | 1 | Camille critiques GraphQL as a fad that creates false promises of front-end autonomy. Lenny notes VC dynamics pushing frameworks, while Camille adds that big tech internal tools share equal blame. | |
| Heuristics and Readiness for Transitioning from IC to Management | 4 | 4 | 1 | 1 | Camille outlines her 10-year mastery heuristic before transitioning to management. Lenny connects with his own 10-year engineering experience and the pain of giving up coding. | |
| Sponsor Message: Coda Collaborative Document Workspace | 3 | 4 | 1 | 1 | Following a sponsor read, Camille discusses the loss of time autonomy in management. Lenny notes his own experience transitioning between engineering management and product management. | |
| A Contrarian View on One-on-Ones and Stakeholder Management | 3 | 6 | 4 | 0 | Camille presents a contrarian critique against the proliferation of peer and stakeholder one-on-ones, arguing they are unscalable and ineffective for real alignment. | |
| Sustainable Work Culture: Focus, Deliberate Time Audits, and Delegation | 5 | 4 | 2 | 1 | Camille explains her philosophy of ruthless time auditing, boundary setting, and delegation over brute-force long hours. Lenny references Elon Musk's five-step optimization framework regarding cutting too little. | |
| Working Effectively with Internal Platform Engineering Teams | 4 | 5 | 3 | 2 | Lenny confronts Camille with a sharp quote from a product colleague criticizing platform teams as slow and unaccountable for ROI. Camille validates the criticism and suggests PMing platform teams directly. | |
| Structuring High-Impact Platform Teams as Product Organizations | 4 | 5 | 1 | 0 | Camille outlines proper platform team composition, stressing the need for software engineers and product managers focused on business outcomes. Lenny adds that PM ratios on platform teams are often much higher. | |
| Identifying When a Scaling Company Truly Needs a Platform Team | 3 | 5 | 2 | 0 | Camille defines platform engineering boundaries and warns early-stage startups against creating dedicated platform teams before hitting clear scale bottlenecks around 50+ engineers. | |
| Navigating Operational Rigor, Migrations, and Platform Stakeholders | 2 | 5 | 2 | 0 | Camille covers the unglamorous realities of platform leadership, such as operational quality, forced cloud migrations, and managing skeptical internal stakeholders. | |
| AI Corner: Practical Applications, Limitations, and LLM Hallucinations | 4 | 3 | 2 | 1 | Lenny and Camille discuss practical LLM workflows, hallucinated quotes, and the Megalopolis fake movie review marketing controversy. | |
| Lightning Round: Recommendations, Life Mottos, and Weightlifting Habits | 2 | 1 | 0 | 0 | Rapid-fire lightning round covering book recommendations, favorite movies, core life mottos, and home weightlifting habits. |
Statements from this episode (22)
Fournier: PMs must proactively share credit with engineers to avoid friction
“PMs, because they're, they tend to be the front facing person for initiatives, they're
Talking to customers, they're talking to the executive team, whatever.
Engineers sometimes think that they don't get the credit for their work because the PM sort of takes a…”
Fournier: PMs acting like technical details do not matter alienates engineers
“Engineering done successfully really is all about the details.
And you don't necessarily have to understand all of those details, but when you act like they don't matter, and you don't care about them, and it's just like, I don't care, just like tell me when y…”
Fournier: PMs acting as middlemen for technical questions wastes time
“So if you are being asked questions that you cannot answer because you just don't know, right? Because that's something that involves a level of technical detail that only the engineers have that you just don't have. And you're, you put yourself in this in-bet…”
Fournier: Excluding engineers from product ideation triggers massive over-engineering
“What I see happen in those cases is that I see engineers start to over-engineer things because engineers Are like, well, I need to take control of something, right? Like I want to have some creative outlet. So I'm going to use my engineering skills in my creat…”
Fournier: Many engineers underestimate what the product manager job actually requires
“Like I just, my experience is there are plenty of engineers who actually think they can be product managers and they don't really understand all of the elements of the product job. That they would need to be successful.”
Rachitsky: The best PMs talk the least and let others present
“I find the best PMs are the ones that talk the least and encourage other people to do the presenting and announcing.”
Fournier: Engineers massively underestimate system migration time
“Engineers notoriously, notoriously, notoriously, massively underestimate the migration time for old system to new system, and that causes a lot of problems.”
Fournier: Ground-up software rewrites rarely succeed
“Trying to say, we're going to just go away, we're going to rewrite, we're going to build something brand new, and it's going to solve all our problems, it just very rarely works.”
Fournier: Engineers shouldn't stop hands-on coding until mastery is in their bones
“One piece of advice I give everybody is don't stop being a hands-on technical until you feel like it's in your bones. You feel like you've got mastery that you could, if you know a second language fluently, or if you like played an instrument, like really, rea…”
Fournier: GraphQL rarely works well in practice outside of Facebook
“The impression that I have from sort of listening to people talk about it is that GraphQL is kind of trying to promise front end engineers that they don't really have to like collaborate with back end engineers and they can just sort of build whatever and it'l…”
Fournier: Big-company frameworks often fail when adopted outside their original context
“Some of the most time-wasting frameworks have also just come out of big companies, right? Where the context of the big company that may have made that framework super useful within that context doesn't translate to startup or small company or even big company …”
Fournier: Engineers need roughly 10 years coding before entering management
“So I do think it's probably a like somewhere in the 10 year range of like really having spent a lot of your time over those years in writing code and, you know, really understanding how to be a technical expert.”
Fournier: Shifting engineers to project management is the worst leadership path
“Often they're actually pushing you to become a project manager, which is actually also the worst, you know, worst sort of path to real leadership, in my opinion.”
Fournier: Product managers are far easier to manage than engineers
“PMs are way easier to manage. PMs are awesome to manage. PMs want to, like, they're just so helpful. They're, like, want to do things. They're good communicators. I love managing PMs. I have to say, I just, like, my experience, engineers are such a pain. They …”
Fournier: Managing stakeholders via one-on-ones isolates unhappy stakeholders
“Having all these meetings as one-on-ones with those stakeholders can actually be kind of a weakness because when your stakeholders just tell you in a one-on-one that they're happy or unhappy with things,
Your unhappy stakeholders kind of aren't hearing that.”
Fournier: Overworking allows people to sidestep the difficult work of prioritization
“Overwork kind of lets you just sidestep doing the hard work of figuring out what's important in the first place.”
Fournier: Companies must allocate dedicated product managers to internal platform teams
“I actually think product, you need to have a product mindset. And frankly, you need to have product managers to build good platforms, internal platforms. A lot of companies just don't do this. They don't believe that they should waste headcount on product mana…”
Fournier: Platform engineering teams must include dedicated software engineers, not just SREs
“First of all, I really am a very strong believer that like platform engineering has to involve software engineering. If you don't have any software engineers on your platform team, and you only have like, you know, more like operation systems engineers, DevOps…”
Fournier: Engineers cannot effectively double as product managers for very long
“The actual details and focus of the product work is just, you can't write a bunch of code or, and, or manage like a big soft software engineering team and be a product manager at the same time. That's actually just asking, I think too much of people to do that…”
Fournier: Platform teams require fewer PMs per engineer than product teams
“So much of the work in a platform team is not a Is not exactly product work. Like a lot of it's like, you know, scaling or really like deep kind of technical, like I got to figure out how to actually do this technical thing, or I've got to, you know, do this p…”
Fournier: Do not build a dedicated platform engineering team before 50 engineers
“So first of all, I think it tends to be like, you have 50 plus engineers. I don't think this is the kind of thing that you start when you are, you know, 10 engineers, right?”
Fournier: The best platform tools originate in individual application teams
“A lot of the best platform type offerings and companies start in individual like application teams, like an application team has a problem and they solve it for themselves. And it turns out that that's actually a really good idea for how to solve that problem.…”