When to stop coding

As we grow our careers, and we climb higher and higher, at some point most engineers face the prospects of parting with the tools. And many of us struggle with the process. And so the question of when is it the time to stop coding? crops up regularly. Having wrestled with this very question myself in the past, I have figured this might be a good topic for a post.

What got you here, won’t get you there

A career of a software engineer is a bit of a wretched one. Half of a career we spend on getting really good at programming, and then we’re promoted to a management position and have to throw most of that skill away.

On a surface of it this seems like a bad news and there is something wrong with the software engineering industry. But, it is a common problem across multiple industries, probably all of them that have teams.

Every time the pattern is the same: a person becomes very good on the tools, and they get promoted to a manager; a person becomes very good at management and they are promoted to senior leadership position. And with each of those changes the same problem arises, what got them to the next level, doesn’t necessarily help them to become good on this new level.

This is very true for the senior engineer to a tech lead transition, and especially true for the move from a tech lead to an engineering manager position. Because they are not expected to produce code any more.

Coping with the transition

Change is always painful, and people subconsciously try to avoid pain. And so the coping mechanisms that people employ when they get to the next level are surprisingly similar. People cling to what they know.

A senior engineer to a tech-lead transition will lean on their technical prowess; the tech lead to a manager transition will continue meddling with technical decisions; and a manager to a senior leader position will try to continue impacting the roadmaps and processes.

That is a very natural stress response behaviour. People don’t necessarily know how to approach their new responsibilities, or don’t feel confident in their new abilities, so they try to stick to what they know in order to maintain their world picture consistent.

While understandable, those behaviours are unproductive. Tech leads don’t lead as much they should, managers don’t manage, and senior leaders don’t strategise and coach.

While they might feel like they’re working hard and contributing a lot, they, in fact, don’t fulfil their primary responsibilities that their role implies at full capacity.

The limits of possible

I understand that when I say that a person doesn’t fulfil their role, that sounds harsh. And to a degree it is, a person in fact tries their best after all.

The problem here is that there is a limited number of hours in a day. And unless a person enacts a some sort of custom hybrid role, they are expected to give their new responsibilities their full attention. And when a person spends a significant chunk of their time on doing what they are used to do, they don’t spend that time on what they supposed to do.

A technical term for an engineering manager that keeps acting as a tech lead is an overpaid tech lead. Your boss might not say it this way out loud, but if you are a freshly minted EM and you keep contributing to the code base, that is exactly how they will see you. Add to that the fact that you’re not that great at your new responsibilities yet, and you will understand their displeasement.

The problem is aggravated by the fact that when you take on technical challenges, you create expectations in other people that you’re going to get it done, and done quickly. As an EM, you will have a long slew of overdue responsibilities, you will get distracted, and eventually drop the ball with your technical deliveries. And now you will have both, your boss and your engineers unhappy with you.

As a rule of thumb, a person with more than 5-7 direct reports cannot effectively do anything else but manage those people. If they manage them well that is. And so, an EM that has 2-4 tech leads reporting to them, will barely have time for their other managerial duties.

As a CTO, here is what I would roughly expect from people in terms of time spent on hands-on technical commitments:

• An IC engineer: 80%
• A tech lead: 60%
• A principal engineer: 30% (mostly R&D)
• An engineering manager: 5% (keeping up with the trends)
• Head of engineering: 0%
• Head of architecture: 5% (keeping up with the trends)
• CTO/VPoE: 0%

The effects of contribution

There is yet another aspect of this problem that we need to consider though. And that is how other engineers perceive the work committed by their manager.

The relationship between an employee and their manager is inherently unequal. Yes, a manager might take on a service-leadership stance in their management style, and genuinely try to help people they manage. But, in the end of the day it is the manager who has the upper hand over an employee. Including the right to dismiss them.

All this means is that your reports will be much less inclined to give you an open feedback to your code base contributions. Moreover, unless they feel adventurous, they will avoid making changes to your code as a plague. They just don’t want to risk unnecessary conversation with their manager. Because they know that a nail that sticks out gets hammered.

To a degree, this is a manageable problem. You can build great relationships of trust with your reports, and/or practically twist their arms to make changes to your codebase. But, there are still limits to what you can do here. And you will end up doing more work than you had to if you chose not to contribute in the first place.

Do you have to stop?

I actually make it a point to never hire engineering managers without a technical background. It has to do with strategies and business value. But, the long story short, an engineering manager supposed to be able to make innate value judgements of engineering requirements, because people of other functions won’t have that ability due to differences in their background.

What this means is that technical knowledge is a valuable asset in an engineering manager. Without that, any type of manager would do their job easily. But, the further you go, the less important that technical knowledge becomes. The work becomes more abstract from the codebase specifics, if that makes sense.

And so, the question whether you have to stop coding is a complex one. You definitely need to stop contributing to production codebase as soon as possible; I hope that sank in by now. As an EM you might fix a minor bug or two on a regular basis, just to keep your hand on the pulse of how the engineering process feels like at the moment. Or, a principal engineer, if they’re very good at what they do, might occasionally lend a hand to a team that struggles.

Outside of that, it really depends on how much do you actually value technical work, and how much spare time you have. Some of us, yours truly included, have an incessant need to build stuff, and you can keep doing that as a hobby your entire life. But, you need to recognise and respect the fact that it has very little to do with the day job.

Wrapping up

Look, management can feel very lonely at times. I’ve seen a fair bit of people who struggled with this very question, and I can assure you, you are not alone in this. In fact, most engineers that worth their salt wrestle with this problem sooner or later.

The reality of it is this. At some point in your career you will have to choose whether you want to grow, or you want to keep working on the tools. Yes, some companies might accommodate both to a degree through role crafting, but those are rare and fleeing setups. I wouldn’t count on them long term.

You will eventually have to let go of the tools, even if you choose the technical track. Simply because of the economic realities. There is no point of paying very senior people a whole lot of money for the work that a tech lead can do. And so you will eventually transition into architecture and strategy anyway.

If you want my advise, it is this: get your fill while you’re young and hungry, because you won’t have a whole lot of time for the tools when you move up the ladder. And if you’re truly love just building stuff and ready to sacrifice your career for it, then stay a tech lead forever. There are people who do that, and plenty of them are happy with their choice. But, sacrifice you will, either way you go.

P.S.

Well, this turned up a bit more gloomy than expected, didn’t it. So, if you’re really bummed up about letting go of the tools, there are couple of options still available.

1. Coding as a hobby. Day job is not everything, and if your circumstances allow you to keep spending time outside of 9-5, you can still keep working on side projects. I know this is not for everyone, but it’s an option. I’ve seen some very senior people smurfing in open-source and that keeps them happy and sane over extended hauls in management.
2. Consider detours on your management career path. Some managers occasionally step down in their roles and work on the tools for a bit to regain their footing. Short term contract work between management gigs is always an option and the pay might be quite comparable to a manager’s salary.

I myself never really stopped coding despite running a 50+ engineering team. There are always interesting things to build out there. Just keep a clean line of separation between day job and your hobbies, and you will be fine.