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."
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."
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.
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."
tl;dr:The first major input in any kind of fair evaluation is based on the work the employee needed to accomplish, and the work they did accomplish. Camille breaks this down into "must be achieved, stretch goals, and moonshot goals" elaborating on each. She also discusses identifying management characteristics essential to the role so you can score the candidate against each, while also giving leeway for your own judgement.
tl;dr:(1) Doing all technical design work yourself. (2) Doing all the project management yourself. (3) Neglecting to give feedback on non-technical issues. (4) "Hoarding information" i.e. not providing business context to your team or distilling and communicating it effectively. (5) Focusing too much on your personal output and not the team's output.
tl;dr:23 skills include: (1) How to write a design doc, take feedback, and drive it to resolution in a reasonable period of time. (2) How to mentor an early-career teammate, a mid-career engineer, a new manager who needs advice. (3) How to listen to other engineers’ ideas without feeling threatened, and more.
tl;dr:When managing managers, it’s tempting to be hands off, but that's not optimal. Camille was managing a complex migration and decided to hold a monthly status update meeting that paid dividends. It allowed her team to "show off" and air grievances. Camille recommends it when there's a critical area that has misalignment between participants, a forcing function to organize a manager or when there's uncertainty around direction.
tl;dr:"Novel technology deserves boring plans." Exciting visions come with unpredictability. Strategy that executes this vision can be stressful if it starts and ends with the vision alone. "Contrast this to the team that turns that vision into boring plans" e.g. start with a small proof of concept so you can learn the process.
tl;dr:To change engineering values as a leader, you need to change what you reward and focus on. This can be slow and has negative consequences e.g. some feel their skill are less relevant. As a platform engineer, you can find tools that bake in and support the values you want to be taken seriously.