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:
Super hands-on - they take tasks in every sprint, know the codebase, and help the team fix hard bugs.
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:
Something that’ll help my engineers.
Something I’ll learn from.
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.
Nothing wrong with an EM finding a little time to code if it doesn't take away from more important things, but you must be careful not to do anything too impressive because then your own upper management will start measuring you on code contributions again and you may slip in your ability to be measured and appreciated as a people leader. Technical teams already have enough code wranglers, what's missing at most companies are EM's who can debug humans and empathize with their reports and be accessible rather than heads down in code and distracted or too focused only on the technical priorities. I'm curious where you got this statistic:
"95% of engineering managers wish to write more code, but feel they just can’t." It suggests a worrying lack of self awareness among EMs: why move into management if you would really prefer to be writing code?
Looks like great EMs are looking for impact instead of just “doing some coding”.
This was my experience too-recently with my last manager, but event at smaller scale in my company where I was the only manager.
And that’s a great thing you’ve built with RAGs, I recently wrote about RAGs too because I think they are the missing pieces in helping faster LLM adoption for businesses.