/Camille Fournier

The Manager As Debugger tl;dr: The best engineering managers are often great debuggers. Camille argues that there are overlapping skills between debugging complex systems and managing teams. “Managing teams is a series of complex, black boxes interacting with other complex, black boxes. These black boxes have inputs and outputs that can be observed, but when the outputs aren’t as expected, figuring out why requires trying to open up the black box and see what is going on inside.”

featured in #510

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