/Camille Fournier

The Next Larger Context tl;dr: For senior engineers who are looking to step up: “When we are looking to do a larger project than the ones we’ve done before, we need to step out of the context that we normally operate in. When you look one context bigger, you will see immediate new opportunities that you can tackle in adjacent areas… That is where you will find your growth.” Camille highlights this advice with real world examples.

featured in #418

Avoiding The Rewrite Trap tl;dr: “Year after year, engineers convince themselves and their leadership that a rewrite will solve all their problems. And then they or their leadership get fired, because most rewrites fail to deliver anything at all. Avoid the trap: don’t go into this exercise unless it is the only way forward, and if you absolutely must, plan accordingly.”

featured in #410

Which Meetings Should You Kill? tl;dr: "I fear that the culprit is a surprising new factor, one that started before the pandemic but has gotten even more out of hand in the world of remote work: 1:1s." Camille discusses how group discussion topics have turned into 1:1 topics in the remote work era.

featured in #378

OKRs Are Hard tl;dr: "In this post, I decided to write down my definition of what a good OKR looks like. My thinking has evolved from what I first learned long ago in half-remembered talks, blog posts, and books, and is now based on my experience using them to set team goals over the past ten or so years."

featured in #376

Debugging Teams: Groundhog Day tl;dr: "Have you ever been on a team that seemed to work very hard but never move forward? Where you look back quarter after quarter, or perhaps year after year, and you did a lot, but nothing actually seemed to happen? Congratulations, you’re in the middle of Groundhog Day." Camille discusses the symptoms of Groundhog Day and how to get out of it. 

featured in #372

The Senior Shift tl;dr: "The real difference that companies are looking for is not that you are capable, but that you have demonstrated those capabilities by delivering impact. It’s not enough to have the skills, you have to deploy them to produce something of value to the wider group. In fact, while companies may put language about increasing expertise in their engineering levels, the real lens that they use to evaluate that expertise is through increasing scope of ownership, delivery, and impact."

featured in #366

The Product Culture Shift tl;dr: "Adding product management to more traditional software infrastructure organizations, sometimes with a shift towards platform engineering, is all the rage today. As someone who has done both these things, it doesn’t surprise me to see so many people struggling to make it work... It’s easy for people who have spent their whole career building infrastructure to misunderstand what product and platform really mean. So I thought I’d share the secret to making this work."

featured in #344

The Secret To Getting To The Staff+ Level? Leverage tl;dr: "You need to develop skills that give you the leverage to show bigger value to the company. These could be interpersonal skills that make you more trusted and valued, execution skills that let you drive complex projects to success, strategic skills that give you bigger ideas and the ability to sell them, or, occasionally, expert skills that make you very hard to replace."

featured in #341

How Do Individual Contributors Get Stuck? A Primer tl;dr: ICs often get sidetracked or stuck by: (1) Brainstorming: “I must have thought through all edge cases of all parts of everything before I begin this project.” (2) Researching possible solutions forever. (3) Refactoring: “this code could be cleaner and everything would be just so much easier if we cleaned this up.” (4) Helping other people instead of doing their assigned tasks. (5) Finishing the last 10–20% of a project. And more. 

featured in #329

Structural Lessons In Engineering Management tl;dr: Engineering managers are "attracted to formulas, algorithms, and structures" and this kind of thinking can create too much structure when applied to team management. Camille gives an example: Engineering managers do not scale well beyond 7–8 direct reports, and teams can also downsize quickly i.e. people quit. Therefore, "the temptation is to create a clean tree structure for your organization" to rebalance numbers, but this can have adverse consequences quickly. Camille advises "to nudge it back into shape over time, or very occasionally, reorganize into something more appropriate." 

featured in #283