It surprises me when some choose not to.

First of all, let me begin with three clarifications:

1. This article is not one of those “you will succeed if you do what you like” articles.
2. It is not one of those “engineers are indispensable, managers are not” articles, either.
3. Both of the above statements are false, by the way.

“So what‘s your routine”?

I was in a gathering a while back, having drinks with some old friends of mine. Among my friends, there was a new guy there, whom I had met for the first time. Let’s call him John. John is a software developer, and he seems to adore programming. And his responsibilities revolved solely around this. However, when it comes to my position (a mid-level line manager), the duties were not so clear. John wanted to have a better idea of my day-to-day professional life (possibly to acquire knowledge about a possible future career path), so he asked me the question: “So what’s your routine”?

It had been a while since anyone asked me this question, and I had forgotten how genuine it is. The fact that we were working at different companies did not help to simplify the answer, as managerial practices across companies vary as much as their needs.

I gave him the honest response:

• “I am participating in decision-making meetings that sometimes demand a lot of preparation. In between meetings, I check pull requests from the team. And also, sometimes, I make some POCs understand if the large-scale software vision is something feasible. Team evaluations and one-to-one meetings are also part of my responsibilities.”
• “So how are you managing all of those?” he asked.
• “I don’t,” I replied. “I am leaving some things behind; for some others — mostly tech stuff — I am asking the team for help. It’s impossible to do everything; I need to put my focus where I feel it’s best.”
• “Why are you still coding if you don’t have the time to do everything, then? Can’t the rest of the team manage the load? Aren’t you afraid of becoming a bottleneck”?

I knew where this was going, so I quickly went there. We talked about whether the path towards an engineering manager involves stopping coding. I can now be considered a mid-level manager, but I have had my fair share of upper engineering managers in my career.

As many of us do, John had the Programmer Career Mantra, where everything has to be made clear for something to happen or a path to be followed. To this mindset, being both a developer and a line manager does not compute. But apart from John, I have heard stuff like these from my managers — that the path to the upper hierarchy levels does not include active software development.

Eventually, John asked me if I felt I should stop writing code to focus on more managerial stuff.

“Not completely.”

That was my answer to his question. And as vague as my response was, so is the situation when becoming a technical mid-level manager. Things are never clear because our careers are not, either.

There is this assumption that when you go up in the hierarchy levels, you stop coding and connecting with how the work is being done. In your pre-managerial days, companies pay you to produce. When you step up in the hierarchy chain, you manage others to create — and grow. The company doesn’t want you anymore; they want to have many yous, doing the job at least as good as you did in their position.

It is an irony how some people think that the award of climbing up in the hierarchy chain is to stop doing the work that brought you to this position in the first place. I like working with people, and I appreciate the human aspects of software engineering — but I do not appreciate this kind of irony.

“You Shouldn’t Code Anymore.”

Many upper managers I have encountered throughout my career (including bosses) advised me that I would have to give up coding at some point. They also said I wouldn’t even want to do it anymore past a particular career milestone. Some didn’t have any experience coding, they started by being project managers, and they climbed the hierarchy through the business path. Others had prior engineering experience, but they had to drop practicing programming to dedicate their time primarily to managerial issues.

They all had a good paycheck as an award that solidified their approach. The corporate world usually associates top salaries with senior and upper managers — non-technical people.

It gradually happens out of necessity.

There are few engineers among us who don’t seem to settle just for coding. These people can undoubtedly code but can also communicate with others, be mentors, and have a broader vision that spans way ahead of simple Jira tasks. So it’s only natural that those people are appealing to other members of the team. Those are the potential future leaders inside a company. So they are assigned tasks outside of the day-to-day coding routine to level up their soft skills: talking to people, transferring knowledge, consulting, evaluating the skills of other members, earning their trust, etc.

Acquiring new skills takes time. And for people that have been software engineers trying to make the change towards more managerial positions is challenging, as they need training themselves to understand how to be effective engineering managers. Consequently, time for hands-on development is limited, and since meetings are numerous, it’s getting difficult to find a good chunk of time to expand the technical infrastructure.

The “no-code for the technical managers” narrative

The above is why senior managers prepare the mid-level ones for gradually abandoning their old habits. Team effort and upskilling now become personal KPIs of the newly appointed leaders. Completing software tasks does not affect your yearly evaluation anymore. However, the performance of the team does. So it makes sense for new managers to put aside software development for a while and focus where they feel their new KPIs are.

And that’s what I call the “no-code for the technical managers” narrative. The narrative that people before you have contributed to, attested to, and passed on to later generations of engineers getting promoted. It dictates you to invest more time into making others better engineers, create abler teams, and making them deliver more solid results, which — don’t get me wrong — is an astounding proposition — I’m all in for that. Still, there is a catch that no one warns you about: if you don’t pay attention, it will come at the cost of your time, skill, possibly your job, and maybe your long-term career.

This brings us to my next point.

Why Everyone Should Still Code (Including Engineering Managers)

You need to know how things are created

When you are a developer, your company pays you to produce. You have abstract ideas as input and code as output. Some of this code will live on for years; other parts will disappear in the next refactor. Things are pretty straightforward and laid out when you are a developer. Writing code covers one crucial aspect of your personality: being creative. You are getting paid to exercise your creativity, find innovative solutions to new (and sometimes old) problems. You are also part of the engineering team — I mean the people who produce something. That’s where the magic happens.

When it comes to a software company, if you put aside the spreadsheets, timeframes, broken promises, vague assumptions, wishful thinkings (usually happening on the management side), there remains only one universal truth: the source code. It doesn’t matter what you said, imagined, or hoped for. What matters is the final product — the output. That’s what the team was finally able to produce, and that’s what the customers will receive at the end.

Being able to understand what the team produced is paramount in all types of businesses. Even if you are the big boss, you won’t sell anything to anyone if you don’t first understand exactly how it’s made.

When you lead a team of developers, you need to understand their career progression and development tools deeply. You must also be able to draw a low-level architecture of the system you are developing. And I don’t mean those large abstract boxes in the whiteboard for the upper managers to justify what they’re paying for. I mean those nitty-gritty details, the ones that cannot and should not be bothering the clients.

You need to maintain a long-term technical vision.

I have had my fair share of managers along my professional way — I still have. Everyone has a boss, after all.

Upon undertaking a new position, you have your superiors explaining to you your new duties. What everyone fails to mention is that your duties as a technical manager also include having a vision. This is not easy. You can be a great communicator, but it doesn’t matter if you don’t have anything long term to communicate.

Having a technical vision about the product your team is designing also means keeping in touch with the art of developing it. You need to know the impediments of your team so that you can alleviate them; you must understand how technology is progressing outside of the boundaries of your current knowledge. You will also need to make technical decisions by assuming what the technological landscape will be years ahead.

You can’t achieve that if you are not actively participating in the coding process.

Lack of vision is what drives people away from your team and your company. You should have one, and you should be an active part of the process to retain it.

You still need to be a member of the team.

It’s important to understand that in the professional world, nothing is to be taken for granted. It doesn’t matter how good a relationship you have with your superiors or if what brought you in this position is a showoff of extreme skill. The company reevaluates each job position every year. Yes, your post, too.

When you make your first steps up in the hierarchy chain, everything is good. For the first few years, you still remember how the job is done. People still come to you for software issues. That keeps you on track. However, as time passes, your team fills your last spot with a senior engineer, whether a new hire or someone within your team. This person slowly becomes the go-to person, the problem solver who knows the stack and can evolve it.

You start realizing that over time, you lose visibility on how the job is done. Technologies arrive, your team’s skills evolve, but your skills remain the same. Sure, you are learning new stuff more on the managerial side, but people around you stop seeing you as creative. As a result, you will start getting fewer requests for technical guidance. You will not be able to provide technical career advice anymore — people will not have any reason to ask you, anyway. You will be out of the technological game for so long that you will not provide solid technical input. You may also miss technology milestones and new ideas that emerge in the field of software. And in the end, you will have to rely upon others to tell you how your people are performing, instead of you being able to figure it out.

And that’s the breaking point. If you cannot provide technical advice to your team, you are only part of a big wheel called Process Management. And that’s when you become expendable. So think about this: if all you do is spreadsheets, meetings, plannings, etc., for things you have no idea how to execute tasks anymore, and if you also stop understanding the day-to-day problems of the team, you are becoming replaceable.

You need to be more than just a manager. A company may forgive mistakes made due to judgment or timing — because you will improve on that, and they know it. However, mistakes made because of professional ignorance are another thing; even if the company lets those slide, your peers and the people you manage won’t.

To continue being well-respected by both your bosses and your team, you need to know how things are (and should be) produced.

Staying On-Track

Being a manager (of any kind and level) is hard. I consider it to be more complicated than being a software engineer. As an engineer, you are dealing with deterministic systems — everything happens for a reason. As a manager (no matter how high up in the chain), nothing is deterministic. You will be dealing with people, and things are never straightforward regarding the human psyche.

It takes an insane amount of effort and courage to choose to deal with many people and be responsible for their outcomes. It necessitates a lot of time, too.

But staying on track and understanding what your team is developing (and their tools), their impediments, and the current technological trends in the world are paramount to maintaining your status as an effective leader.

You have to allow yourself some time to dive into the software side. Even if that is outside of the team’s daily tasks. You don’t have to do it every day, but you do have to do it at some point. Maybe instead of asking how much code you should write, ask your team “where.” Your team can help you with this, by the way, and allocate some tasks for you (maybe of low importance). You can visit the source code regularly and ask why the developers made certain coding decisions.

You don’t have to be at the forefront of the development process, but you can allocate time to be present, nonetheless.

Conclusion

Having discussed this with many people in many companies, I believe there is a clear pattern: Engineering managers who allocate some time to development understand their product and their team better and have a more solidified position inside the company.

I can understand and appreciate the time constraints that management brings. But I still believe that if effective communication is the key to a successful career for a software engineer, staying technical on a deep level is the key to being a successful software engineering manager.