Camille Fournier

Camille Fournier literally wrote the book on the management career path (The Manager's Path), has served as CTO at Rent the Runway, VP of Technology at Goldman Sachs, and Global Head of Engineering at JP Morgan Chase -- giving her the rare perspective of someone who has succeeded on the management track and can speak honestly about its downsides. Their core argument: Many ICs become managers expecting freedom plus authority -- the reality is management is a service job that takes away freedom. People who love building should think very carefully before making the switch. The evidence is specific: The false promise of management: expecting authority AND freedom, getting neither. Furthermore, platform engineering leadership as a case study: stakeholder management is the hardest and least fun part, and domain-passionate people underestimate it. Fournier's personal experience: having been an engineer for 10 years before becoming a manager, she describes the loss of the fast feedback loop as genuinely painful. In Camille Fournier's own words: "I think individual contributors often think that if they become a manager, they will still have some of the freedom that they have as a senior individual contributor. But then they'll also be able to tell people what to do and they'll have all this authority. And the reality is, management is much more ... management really is a service job." (Debunking the myth that management gives you authority while letting you keep freedom.)

Fournier's case against rewrites is fundamentally about epistemic humility. The seductive logic of a rewrite — 'this old thing is crappy, let's just go over here and build the new thing' — underestimates how much the old system actually does. Legacy systems accumulate years of undocumented business logic, edge-case handling, and hard-won bug fixes. Engineers who want to rewrite typically haven't catalogued any of it. Her diagnostic question often kills the rewrite impulse entirely: if you could leave this alone without harming the business, is it worth changing at all? If the only reason for the rewrite is engineer annoyance, you're burning capital to scratch an aesthetic itch. Her constructive alternative is stage-wise evolution — identify a well-contained subsystem, uplift it, clean up its tech debt, leave the rest alone. In Camille's own words: "When you're struggling making an evolution plan, take pieces potentially of the old system, uplift them, make them more scalable, make them easier to work with, clean up the tech debt, but 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." (Her prescription: staged, piecewise evolution rather than a greenfield replacement.)

Fournier represents the most experienced voice on the debt-as-bug side, and her specific contribution is about how engineering leaders mis-handle debt once it's accumulated. She's skeptical of both extremes — she doesn't dismiss debt as a champagne problem, and she doesn't romanticize the clean rewrite as a solution. Her prescription is evolutionary: take pieces of the old system, uplift them, clean up the debt in that specific section, and move on. This is infrastructure-as-gardening rather than infrastructure-as-construction. Her sharpest heuristic is diagnostic — if you could leave this system alone for a long period without harming the business, is it worth changing at all? The fact that she's held senior roles from hypergrowth startup to trillion-dollar bank is what makes her case load-bearing: she has seen both the startup that died because it refused debt and the enterprise that died trying to rewrite its way out. In Camille's own words: "If I could go away and not touch this and not do anything to it for a long period of time without it really harming my business, is it worthwhile to change it at all? Does it matter, and there's some questions there." (The sharpest heuristic for deciding whether debt is actually worth paying down at all.)

Fournier wrote the book on platform engineering precisely because she thinks most platform teams are dysfunctional in exactly the ways their internal customers complain about: slow, tone-deaf, funded without needing to show ROI. Her diagnosis is that this happens when leaders treat platform as infrastructure-plus-DevOps instead of as a product discipline. In her view, platform engineering has to involve actual software engineering — not just SRE and operations and blueprint scripts — because the output is supposed to be a cohesive internal product. Platforms are products, which means they need product managers, outcome-based goals, and a clear theory of how they create leverage for the rest of the company. Without that, platform teams drift into technology-for-its-own-sake work and demand adoption. In Camille's own words: "I'm a very strong believer that platform engineering has to involve software engineering. If you don't have any software engineers on your platform team and you only have more operations systems engineers, DevOps, SRE... I think you're kind of missing the picture. Platform engineering is not just maintaining cloud infrastructure and doing small scripts or blueprints or enablement projects for other teams, because that doesn't really create a cohesive and coherent platform... platforms are products, ultimately." (On how to structure an effective platform team from the leadership side.)