Managers should focus on leadership and team development rather than coding. <a href="https://bobtomlin-70659.medium.com/why-great-engineering-managers-shouldnt-code-3e046aa0f52c" target="_blank" rel="noopener nofollow">You have your own tasks.</a>. Don’t be the bottleneck, do PoC’s, help debug, keep architecture and product focus consistent across projects and developers, and focus on team skill growth.

This squad was established to be able to share anything about development. Post, Comment, and Upvote!

Dev World

Engineering managers should prioritize leadership and team development over hands-on coding. Their role is to avoid becoming bottlenecks, conduct proof-of-concepts when needed, assist with debugging, maintain architectural consistency across projects, and focus on growing team members' skills rather than writing production code themselves.

Why Great Engineering Managers Shouldn’t Code

As a manager, one of my biggest tasks is to remove all obstacles for my team to be great ! Any other free time left is for coding, as mentioned PoC’s leading the way.

A bit incomplete title. I’d say, it’s good if their code. Off work, i.e. when no more important task stands in the way. 😉

As a team lead I feel that I spend most of the time reviewing code than coding (my company is small and there is only one dev per product). Working on my personal projects would be great but that turned almost impossible since I was promoted at my family to the dad role. I start feeling stuck and the burnout is serious.

I recently moved from Senior Software Engineer to Software Engineering Team Lead. This was a great and succinct article. This has been one of the hardest things to adjust to - knowing it’s ok (wise, and advised, even) not to code. I’ve already been the bottleneck a few times because I picked up a ticket “like normal” and set to work on it. Fortunately, it wasn’t a big bottleneck, but enough to make the Product team a bit nervous.
Along with removing roadblocks for my team, I have been focusing on those “nice-to-do” tasks. In reality, these tasks are Important / Not Urgent. (for those using the <a href="https://www.eisenhower.me/eisenhower-matrix/" target="_blank" rel="noopener nofollow">Eisenhower matrix model</a>). Things like security, performance, observability, etc.
I am currently trying to figure out the best way to incorporate these “nice-to-do” (but are actually pretty important) tasks into my developer’s day-to-day routine. Ideally, we would be dev-complete in the sprint with enough time to spare to dedicate to these items without having to ticket and plan for them. Unfortunately, this has never been the case.
To the other Software Engineering Team Leads/Managers, how do you logistically handle these Important / Not Urgent tasks within the sprint (especially with Product’s involvement)?

I definitely do not agree with this! All engineering managers at my company are also developers, we just have some extra duties on top. I cannot imagine leading people who I am not actively working with. I think actually being in the trenches with the people you are leading really helps you understand the pain points they are dealing with; because you are dealing with them too.
Obviously if you are a manager and a developer at the same time, you have to do a good job managing yourself. Don’t do developer tasks that you don’t have time for, and don’t neglect management tasks for development.