Lesson #14: Congratulations! You don't know everything

Hello and thanks in advance for reading lesson #14 of Lessons in Engineering Leadership! Thank you to the 2,065 of you who have subscribed so far! If you’re new here, Lessons in Engineering Leadership is a bi-weekly(-ish) newsletter on a variety of engineering leadership topics that can be read in under 5 minutes.

You may have noticed I didn’t send one of these last week - read the “what I’m working on” section for why. It’s a great topic for a future newsletter.

If you would like to receive longer form newsletters and access to the tools I’ve created over time, you can become a paid subscriber. (This is still a work in progress. I’m about 50% through a long form post on fixing your interview process – it’s a spicy but good one!)

I’m glad you’re here!

---

First off, some news!

I’m launching a course on Engineering Management! You can sign up for the waitlist here. I’m preparing the curriculum for this course now. If you looked at this before, look again! I updated the landing page with some more information on what I cover. I hope to launch my first cohort this summer!

---

Congratulations! You don’t know everything

As you transition from IC to management, your shift focuses from projects to people - I’m sure you’ve heard this at least 20 times from me alone. In some organizations you’ll keep coding to some degree, but many are much more focused on you managing your team vs. writing code against pre-planned deliverables. (I haven’t written a line of production code since I joined Spot AI over a year ago, but I have enough on my plate to take my time up to where I really shouldn’t be spending my time coding.)

If you spend any time on Twitter or even LinkedIn for that matter in the developer ecosystem, there are constantly conversations around new technologies, cool things people are building, or the casual argument about why Tailwind needs to disappear forever. (Before anyone comes after me, this is not my opinion!) If you’ve been managing folks for a while, it can feel like you’re watching these conversations happen from the sidelines. You’re spending more time focused on making sure your team is producing quality work, so you’re likely less focused on making sure you’re keeping up with the latest technologies. The longer you’re at least one level removed from the side, the slower your technical growth becomes – this is expected.

This means you have a new muscle you need to build: leveraging your team’s technical capabilities, combined with your increased business context, to product your team’s best work.

Your job as a manager is not to have all the answers; it’s to help guide your team to the best answer by leveraging your business context and their technical know-how.

As you spend more time in management, you must get comfortable with no longer knowing everything (though it’s highly debatable if you knew everything to begin with, sorry to break this news to you in a 5 minute email). Be okay with asking clarifying questions. They’re not dumb questions! You need the context to make better decisions, and you wouldn’t want your boss or peers making a decision when they don’t have the full context. Keep asking questions until you understand.

I’ve been so far removed from the technical implementation at this stage that while my technical knowledge can carry me through complex conversations, at the end of the day my engineers are much better suited to discussing our options than I am. It’s my job to make sure they’re thinking broadly enough and considering other options as well as the long-term impact of their work, which means I need to ask many clarifying questions to understand the impact from a technical capacity if it’s not my area of expertise.

If this scares you, that’s fine. It’s a mindset shift. But if you find yourself missing being in the code and having time to dig into new technologies, there’s nothing keeping you in management forever. In fact, a lot of people have asked me if it’s okay to go from management back to being an individual contributor, and the answer is a resounding yes. I highly recommend this article from Charity Majors where she discusses the engineer/manager pendulum and why it’s so beneficial. You’re in good company, I promise!

---

What I’m reading

Surprise! I’m still reading High Output Management but I did finally reach part 3. I promise to finish this by next newsletter. Please hold me to it.

Check out the full book list for recommendations and an ever-growing reading list.

Note: Links to books in this section are affiliate links to help support the purchase of the rest of my books :)

---

What I’m working on

Last week I had the pleasure of dealing with two outages of the same underlying root cause, which is… a bit embarrassing to have to explain, but I’m now investing much more time in fixing the brittleness of our deployment process to ensure this doesn’t happen again. It always feels like outages happen one right after another, and then you forget about it for months when everything is going smoothly, and then… back again. Anyway, this is why I didn’t send a newsletter last week. It was a very exhausting week.

---

If this email was forwarded to you, be sure to subscribe to receive bi-weekly emails in your inbox that can be read in under 5 minutes!