Staying Technical as an Engineering Leader

As a founder and CTO, I have seen my company grow from when I used to write all the code, to the point I wrote almost none.

I have also had frequent conversations with other founders and peers about how much tech leaders should still be coding, or anyway stay technically involved.

My take is: it's very important to stay technical, but it's not trivial to find an effective way to do so.

• If you do it the right way — your skills become an asset that improves your decision making and makes your team more effective.
• If you do it the wrong way — your involvement actually slows down your team, undermines trust and creates resentment in the long run.

So let's try to figure this out 👇

💼 The Managerial Track

Career ladders in tech are complicated, and there isn't 100% consensus on how they should look like.

Let's say you are on a managerial track, or you are an individual contributor (IC) with some managerial duties towards other devs. The thing is: you are on a path where you end up writing less code than before.

Your role moves—gradually, or suddenly—from making technical decisions and doing the plumbing yourself, to support your team in doing just that. You have to remove obstacles from the way of your team, and find the way to bring your best contribution to the table.

To do that, you have to ask the right questions and challenge decisions being made — so there is no doubt you need to retain some of your technical skills.

But which? And how?

⏱️ Understanding your Schedule

In one of his most famous essays, Paul Graham explains the difference between a Maker's schedule and a Manager's schedule.

• As a Maker, you benefit from long, uninterrupted streaks of time where you do your focus work.
• As a Manager, your schedule is run by meetings where you make decisions that drive the work of your team forward.

These schedules are not only very different — they are incompatible. As a Manager, you won't ever benefit again from such streaks of focus time to do your maker work.

Likewise, as a Maker, you shouldn't be bothered with too many meetings, because that would come at the expense of your productivity.

As you progress on a managerial track, your responsibilities will shift you away from a maker schedule

🙅 Giving up main development work

If you find yourself mostly on a Manager's schedule, my first advice is to give up critical development work.

It doesn't matter if it's a small feature or a long-term project: if it's something important, with precise goals and deadlines, you should probably leave that to the makers.

For two main reasons:

⏳ Your time

Your time, other than being less than before, it's also more unpredictable. As a Manager, you react to things that happen at least as much as you try to foresee them.

You are more likely to be interrupted, and you won't be reliable in your dev commitment.

⌨️ Y**our dev skills

Your dev skills will likely decay a bit, both in absolute terms, and in the context of your team work.

Inevitably, you will become less familiar with the codebase, its conventions and libraries.

Over time, your contributions will need more and more work from the rest of your team, in terms of support, advice, and review — to the point where your team will be faster in doing the work themselves than helping you doing it.

Not gonna lie, I was super sad the first time I realized that 😅

💁 How you can contribute

Even though you have less time for coding and you will become less familiar with the nuts and bolts of the latest frontend framework, there are still many activities you can contribute to.

Here are a few 👇

✍️ Design choices

This is likely the most important area you should continue to follow.

Such choices, especially for sizeable initiatives, depend on long-lived engineering skills rather than specific knowledge — and you won't lose them all of a sudden.

Some impostor syndrome may kick in after a while, like "ugh, I am a manager now, I am not good at this anymore" but trust me: you still have it 💪

You probably bring a different—and much needed—perspective to the table, which is higher level and balances that of other devs.

So, you should participate in design discussions to evaluate trade-offs, provide direction, and have thoughtful exchanges with your team.

🔍 Code Reviews

Even if you almost don't code anymore, it is useful for everyone if you review other people's code from time to time.

• It provides a fresh perspective from someone who is more detached from the codebase.
• It helps you staying updated with the tech that is being used by your team.

🔭 Tech Exploration

If it's hard to stay on par with your team's tech, try to stay one step ahead instead.

Investigate new technologies, make small experiments and report them back to your team. These might be about:

• Smart ways of removing well-known areas of technical debt.
• Tools that allow you to buy instead of make, reducing the scope of the codebase.
• Modern frameworks and libraries that you might leverage in the future for some parts of the product.

📚 Resources

• The Engineer/Manager Pendulum — Charity Majors argues that the best career path might look like a pendulum, switching between being an Engineer and a Manager every few years. It's a fresh perspective and it really made me think.
• Maker’s Schedule, Manager’s Schedule — This seminal essay by Paul Graham had a big influence on the way I look at my job, and work in general. Even if you already know it, it’s worth re-reading every once in a while.