Leadership on jeffcarp

Reflections on Becoming a Manager

Fri, 31 Jan 2025 00:00:00 +0000

Last year after rejoining Google, I became a manager for the first time. As a long-time IC, I had some preconceived beliefs about what the job would be like, many of which were wrong.

During this transition a mentor pointed out one chapter from Nine Lies about Work about how humans are terrible at objectively rating other’s behavior. The result is that your entire work life is filtered through the lens of your manager’s point of view. I think this is something anyone with a boss has experienced: a great one can make your life amazing, and a bad or nonexistent one can make it a living nightmare. The saying “you don’t leave a job, you leave a manager” has rung especially true in my journey.

Quickly saying “no” to ideas is harmful

Mon, 23 Sep 2024 00:00:00 +0000

I’ve observed during my software engineering career the different reactions senior engineers have when new ideas are brought up.

Sometimes when an idea is presented, usually by a junior engineer, a senior engineer will chime in very quickly to emphatically describe why it won’t work. I think this is very harmful to team culture for a couple reasons.

First, it reinforces the bias toward authority for senior engineers. When any engineer brings up an idea, even if it’s overall a bad idea, there is always a nugget of truth – they observed a real issue and offered a real solution. Immediately shooting down ideas discards this truth.

Engineering Management for the Rest of Us reading notes

Sat, 24 Feb 2024 00:00:00 +0000

I really enjoyed this book. Here are some of the biggest takeaways for me.

As a manager, your work is meetings. That means not protecting your calendar as much. People come before focus blocks. Corollary: making sure you can perform at a high level in meetings; meaning exercising in the morning or doing what it takes to make you the happiest and best person in meetings.

The importance of keeping a gratitude journal. Seeing the good in things makes you see the good in more things.

Things I Learned as a First-Time Intern Host

Sat, 31 Aug 2019 11:13:25 -0700

I hosted an intern for the first time this summer. It was my first time being somebody’s manager and it became a huge learning experience for me as well as a really fun time. My intern worked on adding many features to velocity-tracking charts, rewriting our ML models in TensorFlow 2.0, and a few other projects.

Here are the biggest areas where I struggled as a host and the important lessons I took away from those experiences.

Inspired

Sat, 19 Jan 2019 17:07:11 -0800

Inspired is a great introduction on how to be a Product Manager by Marty Cagan, a former engineer turned product expert. Here’s one of my favorite themes of the book:

Product: build the right product
Engineering: build the product right

Here are the most poignant things I learned from this book organized by category.

Product team structure

It’s important to have somebody between product marketing and engineering (i.e. the product manager). Otherwise UX gets skipped and the TL has to figure out what to build, which is a bad recipe for product-market fit.
Also a bad idea is to let sales direct engineering, if you do that you get features, not products.
Most product orgs are basically feature factories… don’t be like that.

Engineering management

Run product management and design in parallel with engineering - the PM and designers should always be 1-2 sprints ahead of eng.
To combat tech debt, give the engineering team “headroom,” i.e. 20% of resources to do with it what they want.

The importance of prototypes

It’s really important to take an engineer or two and create usable prototypes during the discovery phase. Otherwise most startups use their entire eng process and release cycle to ship experiments in order for product to iterate. This is why it takes 1.5-2 years for most companies to find traction, and why many startups fail
Cagan argues that making a full mock with all intended functionality not only is preferrable, but will actually let you ship faster by reducing risk later in engineering.

General product management

Software projects have two stages: Discovery (build the right product) and Execution (build the product right). After the discovery phase ends, the product spec needs to be locked down otherwise changes create “churn.”
Don’t rely on your manager as a mentor, it’s not their job.
To prevent surprises and make sure meetings with lots of high level stakeholders run smoothly, reach out to them beforehand to get them on board.

I thought this book had some fresh things to say about confidence. Frequently confidence is looked upon negatively in tech—something that MBAs who don’t know what they’re talking about have. But I really liked Cagan’s take on it:

The Manager's Path

Wed, 14 Nov 2018 15:32:22 -0800

I can’t recommend The Manager’s Path by Camille Fournier highly enough for Software Engineers. I found this book super useful for understanding the structure of technical organizations. It contains tons of gems that I want to write on sticky notes and post above my desk at work, like:

Especially as you become more senior, remember that your manager expects you to bring solutions, not problems.

You are an engineering manager whether you realize it or not

Mon, 25 Jul 2016 21:33:26 -0700

Over the past few months I’ve mentioned to friends that I want to learn engineering leadership skills. Each time the reaction is: “you want to get into management??” That’s not how I see it.

As engineers we hold the lone wolf in high regard, the hoodie-wearing coder hacking away in the corner at a genius project. But large projects that deliver a ton of value are made by teams of engineers, not lone wolves.

Unforseen Perks of Pair Programming

Sun, 15 Jun 2014 19:03:46 +0000

As someone who had never pair programmed before, it was exciting to get thrown into the deep end during my first week at Braintree where engineers pair nearly 100% of the time.

The relative merits of pair programming have already been spoken about at length.^[1]^[2] This post is not an attempt to argue one way or another. Whether it works for any organization is probably too context-dependent for any axioms I could lay down.