Juanjo Coello

Software Developer & Perpetual Wannabe
I tweet stuff at @jjcoellov

Stuff I wish I knew, 1 - Get out of the way

This is the first post of a series I plan to record for a younger me, in case I ever solve the time travel problem and send these posts back to the past. It might be useful for you in the present, too.

When you were a successful Individual Contributor, young manager, you were tasked with some of the most complex technical assignments your team had to deliver. And you loved it. You learnt to become good at it and your manager recognised your talent by offering you a position as Tech Lead.

(I know that the role of Tech Lead spawns different meanings depending on the company - In this context, I refer to the role that has accountability for project management, technical management and people management of an engineering team)

Now, with your bright new sheriff badge, you still want to be the one solving those complex problems. You know you still have the skills, don’t you? To say nothing of that pleasant feeling when the tests pass and it works as expected; heads down, focusing on refactoring that piece of code your team is struggling with. So it’s Thursday afternoon, there are some meetings you need to prepare, and the only thing you have in mind is rolling up your sleeves and work on that ticket stuck for 2 days, either to help your team completing the sprint or to simply demonstrate them that you are the Lead because you are still awesome at coding.

Don’t do it.

Chances are that you will fail miserably simply because you won’t have the time. As a manager, your calendar looks like a gruyère cheese. Jumping from business meeting to 1:1, from customer complaint to preparation of a 6-pager about your team vision. You have way too many different things to do where a significant lot requires you to be reactive instead of proactive. Coding, in general, demands quality focus time planned upfront, a time that unfortunately is now well left behind in your career. Interruptions will be part of your life - you will get good at it by planning your day around them and mastering the noble and ancient art of multitasking. Those long uninterrupted chunks of time, when coding is the most important thing you could do with them, are gone (at least during working hours). You will be tempted to leave aside others of your duties as a Lead, but let me warn you that they will come back to bite your shiny metal ass. And once you have swallowed the bitter taste of reality, you will find yourself apologising to your team for that task you now need to delegate after realising you won’t have time to complete.

Even if everything above is not true, and you still manage to get time to code during the week without penalising the rest of your responsibilities as a Lead, there is still an important reason for not doing so.

By taking those technical tasks, you are sabotaging your team’s right to own the challenges, solve them and learn from the experience. You are limiting their chances to be stretched and to grow professionally. This goes against the single, most important duty you have as a manager - you are in the people business, and you are hurting your people’s chances of growing and succeeding. You are sending either the message that they are not capable of taking complex tasks or that they should not try because it is your job. It is bad for business, bad for your team and bad for you as a manager.

Note that I am not recommending you to quit coding - right the opposite; I strongly believe you need to keep your technical skills fairly current, otherwise you risk losing touch with reality. However, there are other ways of keeping such skills honed - do code spikes; mentor through pair programming; schedule deep dives with your team; review and comment on pull requests; take those boring coding tasks that you know they hurt your team morale but still are needed and code some of them. Just keep the bold, complex challenges to your team to own and grow.

Your role is to give guidance, technical mentoring, encouragement and feedback, but you cannot and should not do the work. Set up the expectations, offer your help and coach when a skill is not there yet.

Then, get out of the way.

Juanjo