重写是陷阱，一对一也别开太多：Camille Fournier 的工程领导课

Fournier starts by noting that annoyance runs both ways between PMs and engineers. The easy fix, she says, is credit hoarding: because PMs are the front-facing people talking to customers and executives, engineers can feel that the PM takes all the glory for work the engineers did. She recommends sharing credit and letting engineers speak about their contributions, and Lenny adds that the best PMs talk the least and let others present.

The second is acting as though technical details do not matter. Even managers with a broad, big-picture job can forget that engineering success is about details. Dismissing them with "why is this taking so long?" shows a lack of empathy that she finds off-putting, though she concedes that some details really don't matter and call for patience.

The third is playing telephone, in which a PM relays questions to engineers and carries back answers they do not fully understand. Fournier calls this a waste of time for everyone and especially maddening to senior engineers. The fourth is hoarding ideas. When PMs want to be the source of every product idea, engineers lose their creative outlet and start over-engineering, obsessing over frameworks they can control.

Lenny asks whether keeping engineers out of ideation leads to urges to rewrite systems. Fournier says she can almost always predict it: where engineers' creativity about the business is crushed and their voice ignored, they channel it into the area they control, which is technology choices and details. It happens even without such treatment sometimes, she adds.

The PMs who do best, she says, are not threatened by smart engineers having ideas. Many engineers believe they could be product managers but do not see the parts of the job such as measuring inputs and understanding customers. When PMs build relationships that let engineers share ideas and also appreciate the PM's role, engineers can accept that many ideas will go nowhere as long as someone listens.

On the telephone problem, Fournier says connecting people directly is not always easy, since a management job involves filtering meetings so ICs can focus. But if you keep having to say "let me get back to you," the asker may be asking at the wrong level, or you may be losing information in translation. On credit, she says there is no easy fix beyond stepping back and letting others speak, especially after a big technical lift.

Fournier says she has overseen re-architectures and major system evolutions, so she believes they are sometimes needed. But she has seen many cases where engineers convince themselves that building a replacement on the side is the only way to escape a system that is hard to support and change. She favors a thoughtful, staged plan, such as uplifting a well-contained recommendation system behind an API without changing the whole web framework.

The first problem is migration time, which engineers "notoriously" underestimate, especially when external users rely on web UIs or APIs. The old system must also keep being supported while the new one is built. She doubts PMs enjoy being told that no features can ship for six months to two years, and says that should rarely be an acceptable answer.

She also asks whether a system that users are happy with and needs no new features deserves a big investment merely because it annoys engineers. And people underestimate how much undocumented, odd business logic and data formatting lives in legacy systems, making it much harder to replicate than expected. Lenny draws a parallel with product redesigns, which often produce negative experiment results and lost features.

Asked how leaders balance technical depth against altitude, Fournier says not to stop being hands-on until the skill is in your bones, like a language or an instrument you could pick up again quickly. That mastery gives you confidence and empathy for engineers, and makes being hands-off less anxious, though she says anyone will feel anxious for a year or two after the transition.

Technical leaders earn credibility by understanding what is going on and asking good questions, she says, not by dictating which library to use. She finds it annoying when a long-hands-off senior person does that, but appreciates questions like "have you considered this?" or "what are the main technical challenges?" A last piece of advice is to surround yourself with smart technical people and listen to them, through conferences, group chats with former colleagues and following smart voices online.

Fournier is a self-described nerd who loves databases and infrastructure, and says that natural curiosity helps her but is not a prerequisite. She also advises that women and other underrepresented people in tech, whose skills are often underestimated, should build internal confidence before the scary leap into management. She does not claim that good managers must have been technical, but if you care about staying technical, don't take the first management offer.

Lenny mentions an indie developer who ships products in PHP and jQuery and does well. Fournier knows many smart engineers like that and agrees that much of tech is over-engineering. The catch, she says, is that what makes one person productive does not necessarily make ten, a hundred or a thousand people productive, so team technology must balance both.

She suggests being aware of what is changing without obsessively chasing fads. Asked for an example, she names GraphQL, which she would not tell teams to use or avoid since it is outside her expertise, but notes that senior people she knows think poorly of it. Her impression is that it promises front-end engineers they need not collaborate with back-end engineers, which rarely works out in practice unless you are Facebook.

Lenny relays a guest's point that a framework with a VC-funded startup behind it is a bad sign because the company must persuade engineers to adopt and pay for it. Fournier says that is not wrong but adds that some of the most time-wasting frameworks come from big companies, whose context may not translate to smaller ones. Big companies share the blame, she says.

Asked for a heuristic, Fournier points to the idea of ten thousand hours, which she says has since been challenged. For her it was an undergraduate degree, a graduate degree, and four or five years of full-time work. She thinks something in the ten-year range of spending most of your time writing code is about right, though someone who programmed heavily in high school might need only four or five years of work.

She cautions that when a 23-year-old with strong communication skills is nudged toward management, it is often really a project manager role, which she considers the worst path to real leadership. If you are still having fun writing code, she says, do not rush. Lenny, who was an engineer for ten years before moving to product, says he missed building, and Fournier agrees nothing matches the fast feedback loop of code.

Asked what surprises new managers most, Fournier says many do not understand the job and are not self-aware enough to know it. Among those who try, a common shock is that you do not own your time: your team, your management and the company do, increasingly so as you grow more senior. ICs often expect to keep their freedom while gaining authority.

She calls management a service job, though she is not a fan of "servant leadership" as such. Your job is to make things better, which usually does not mean making all the decisions, and in tech snapping your fingers will cause people to revolt. Command and control does not create creativity, she says, so a manager nudges, encourages and sets guardrails and is not the glorious fearless leader. The job is grueling and reactive.

Lenny wonders whether engineering managers move back to IC most often, and Fournier says PM managers do too. Lenny says he disliked engineering management but enjoyed managing PMs. Fournier jokes that PMs are far easier and more fun to manage, because engineers are all primadonnas, though she is one.

Fournier's contrarian view is not about one-on-ones with direct reports or your own manager, which she keeps weekly or every other week and treats as sacred. Her concern is the pattern of managers holding one-on-ones with peers, stakeholders, product and design. Because the cost scales linearly with relationships, it does not work as a company or team grows.

She adds that one-on-ones will not solve every problem, and some people do not want one with you. Using them for stakeholder management can be a weakness: your unhappy stakeholder never hears from the happy ones, and hearing that everyone else is fine sounds like "trust me" and can seem whiny. For many stakeholders, she says, one-on-one management is simply not productive.

Her broader point is to respect your own time, since a one-on-one asks for someone else's time. She admits she is not a natural networker and prefers building relationships through shared work, and says people for whom casual relationship-building is a comfort zone should do fewer of them and push themselves elsewhere. The goal should be getting something out of meetings, not ticking a box for eight meetings in a day.

Lenny notes Fournier is known for a culture where people work hard but keep balance. She argues that overwork lets you sidestep the hard task of figuring out what matters most. If you never reset what you let slide, you do not know where the line of importance lies, so she urges regular audits of whether you are producing value or just easing guilt about working sixty-hour weeks.

She says people also fail to delegate, which leaves them overwhelmed because the team was never taught. Delegating costs more time at first, but frees you to scale, and Lenny adds that it lets team members feel empowered. Lenny also cites the Elon Musk idea that if you never find 10% of what you cut was a mistake, you are not cutting enough, and Fournier says testing the limits is scary but necessary to grow.

A practical tactic is forcing boundaries: log off every day at 6 p.m., or stop at 4 p.m. on Fridays, and then see what you got done. She credits her own mastery partly to being very focused during working hours early on, before heavy social media, so she did not need to stay until 9 p.m. Her focus rituals include tea, a Diet Coke at lunch, a quiet place and wordless music such as Four Tet or Andre 3000's flute album.

Lenny relays a colleague's complaint that platform teams are slow, push product teams to compromise on features and get infinite funding without proving ROI. Fournier is sympathetic, since she co-wrote her platform engineering book with Ian Nolan because so many platform teams do fail to listen, deliver or explain their value. Still, she advises trying to understand their problems and being clear about what you need.

Getting angry or working around them may work in the long run but worsens the short run. She suggests finding the parts of the team that are good, such as a strong database team, and building those relationships. She also says internal platforms need a product mindset and product managers, which many companies do not fund, so sometimes you need to product manage the platform team from the side by telling them clearly what problems you have.

On structure, Fournier firmly believes platform engineering must include software engineers, not only DevOps, SRE and operations staff, because maintaining cloud infrastructure and writing small scripts does not create a coherent platform. Platforms are products, she says, so you also need systems specialists and product people. She has had product managers on all her platform teams, since an engineering manager cannot manage a big team and do the product job well.

Product people matter because they push outcome-based thinking, not adopting a technology because everyone online is talking about it. She suggests measurable contributions such as shorter cycle times for engineering tasks, unblocking products that need to launch and scale, and meaningful cost reductions. Lenny adds that some of the best PMs he has worked with sat on platform teams, and Fournier agrees the PM-to-engineer ratio can be lower there because much of the work is deep technical scaling.

She defines platform engineering as developing and operating platforms that manage system complexity and deliver leverage to the business. Examples include former dev-tools work such as CI/CD, cloud infrastructure provisioning, custom storage systems, web and mobile frameworks, and in-between integration platforms such as a shared billing platform. A company should consider one around fifty-plus engineers, when the same people are solving the same problems on every team or a scaling issue needs a dedicated team, but not earlier.

For people on a platform team, Fournier says half the work is operational excellence, so engineers must care about operations and scaling and not throw code over the wall. PMs should enjoy working with engineers who know more than they do, and should be good at "past one" work, because many of the best platform offerings begin on application teams and get taken over, stabilized and scaled. Those who want constant zero-to-one building may be unhappier there.

She adds three under-discussed challenges. Platform projects run longer and are more complex than typical agile projects, migrations are constant, such as forced cloud provider upgrades, and stakeholders can be a nightmare because peers and executives question whether the team is worth the money. Stakeholder management is probably the least fun part, she says, but leaders cannot avoid it.

In Lenny's AI Corner, Fournier says she mostly uses ChatGPT to rephrase single sentences and calls herself an AI novice. She warns that it fabricates quotes, as she found when she looked for quotations for her book and none were real. She also had it summarize the wrong paper, and jokes about not wanting to manage machines on top of managing humans.