The slow death of the hands-on engineering manager

And how to combat it. The story of an EM who created a ChatGPT for the internal docs in a few hours

95% of engineering managers wish to write more code, but feel they just can’t. Today I’m going to share 2 ideas you can implement with only a few hours a week, that will be a huge help for your dev team.

One is from an EM in my company, who created a very cool internal ChatGPT that knows our Confluence, GitHub readme files, and public Slack channels.

The second one is from a task I did myself a few weeks ago.

But first, why do managers stop coding?

The slow death of the hands-on manager

There are 2 types of engineering managers:

1. Super hands-on - they take tasks in every sprint, know the codebase, and help the team fix hard bugs.

2. Full-time managers - attending meetings all day, having 1:1s, zero coding time.

The sad truth is that almost all of us start from type 1, and slowly become type 2:

I’ve been through that transition twice. When you are first promoted, you are close to the code. You were responsible for big parts of the codebase, and it’s easy to stay a part of the sprint.

For the first couple of years, you code 30-70% of your time, with a slow decrease as your team grows.

Then comes a sprint where you just have too many things. Tons of meetings, a new project you are leading, the usual stuff. So for the first time, you decide to not take on any coding task.

One sprint becomes 2, then 5, then 10. Suddenly a year went by and you barely opened your IDE. Now it’s not a question of having no time - it’s a habit you have lost. Even the most busy engineering managers can find 2-3 hours a week to do some coding.

Getting back into the game is hard. You tell yourself “I can’t do anything useful in 2 hours. I’ll get into the zone and I will be distracted anyway. Better go over that document one more time”.

Getting back to coding

In the last couple of months, I was able to write more code with a simple change: choosing very specific tasks.

I don’t take anything that is in the critical path, or that someone else depends on.

I choose one of 3 options:

1. Something that’ll help my engineers.

2. Something I’ll learn from.

3. Something that will help the company and no one else will ever do.

Today our focus is on number 1: why you should do simple tasks that you’ll developers will thank you for.

The moment you’ve been waiting for:

Build your internal docs ChatGPT

Avi is my colleague, a fellow engineering manager. He is one of the first employees in Taranis, and has been in the company for 8 years.

Most of his days, he is interrupted at least 4–5 times with some random question about legacy parts only he remembers… So he finally decided to be a responsible adult and write down all those answers.

Guess what? Nobody was reading his documents! It’s not that people were lazy, they just couldn’t find them or didn’t even know they existed.

So a couple of months ago, he decided to solve it once and for all. He wrote an internal chatbot that lets everyone in our company simply ask questions, and receive correct answers based on all our internal knowledge.

He used an existing opensource repo (so you don’t need any frontend knowledge for that!), and the end result looks like this:

One more example:

I sat with him to understand how he did it, and helped him write a detailed step-by-step article on Medium. It was very interesting to learn about RAG, Langchain, and vector databases. It’s much simpler than I thought!

If you want to finally understand those terms AND create something useful for your team, check it out!

Choosing a small project for yourself

So what else can you do?

• Fix bugs that nobody prioritizes

• Address technical debt

• Or my favorite: automating the most annoying process for your engineers.

A few weeks ago, one of my team members raised in a retrospective how awful was the process of copying data from production to QA buckets. There was some Jenkins job, but it could only copy data in huge chunks, and could take a few hours.

Long story short, I created a simple UI (using ChatGPT, I’m horrible with CSS), and wrote some Python backend to automate the process. Now they can just input the specific criteria for the copy, and they receive an email once it is done (through a SendGrid integration).

These types of projects have a double benefit:

• It will improve the lives of your engineers

• AND teach you something new

Final words

I truly believe that engineering managers at all levels (up to the CTO) should do at least a little bit of coding. It’s much easier to do when you choose small tasks that you can progress with at your own pace.

What I enjoyed reading this week:

1. Eating Our Own Dog Food by

   Greg Tidanian
   .

2. How to Identify Silent Disagreements? by

   Raviraj Achar

3. Why your product idea sounds too complicated - The "simple" to "WTF" scale of product complexity by

   Andrew Chen