Who do you think will be able to run faster after a year of training, given that both have similar physical abilities: Somebody practising eight hours a day, or somebody practising two hours a day? Most likely, it will be the one practising eight hours a day. A similar logic applies with technical skills, and this logic becomes very real when you transition from an engineering or tech lead position into a management position.

Formerly, you used to be always on top of things. You could enumerate the strengths and weaknesses of library X compared to library Y version by version. You were able to type the most complex commands in your sleep. You could take part in any technical discussion on eye level or above, and people would come to you for technical advice. Now, gradually, you notice that you have been missing out on several versions of your favourite library already, without even reading the release notes. You have to look up commands and parameters that you thought had been second nature to you. You notice that you have to ask more and more questions to keep up in technical discussions, and that you have to ask others for advice on certain technical things.

If you have been defining yourself as an engineer, this gradual process is difficult to bear, because it throws you into an identity crisis. You feel your technical edge wane, and you cannot yet see clearly what is to replace it. If you cannot be the technically most proficient person in at least some niches, then what is the point of this whole engineering manager thing?

What got you here…

What many first-time engineering managers (me included) do not appreciate at the beginning is that management is not a promotion, but a career change. The skills and talents required to excel at your new job are radically different from the ones that made you great at your previous one. Or, to say it with a book title, What Got You Here Won’t Get You There.

Therefore, if you want to do a good job at managing your people, and giving them the service they deserve, it is unavoidable to spend a substantial amount of time on non-technical activities. You have to spend time managing employee performance, collecting and passing on feedback, recruiting, organizing training, and doing all sorts of administrative stuff (vacation requests, seating charts, etc.). The more reports you have, the more this adds up: Each of your engineers only has one one-on-one, but you might have eight of them.

If you deny this change instead of embracing it, you will live in a fantasy world. You might still consider yourself the leading technical expert on a topic, but you might cease to be this expert. Or, you might still be an expert, but on an earlier version of the world.

An example: When I interview JavaScript candidates nowadays, I sometimes feel like a history professor. I have pretty solid ES3/ES5 knowledge, so I like discussing about variable scopes and hoisting, binding of this, IIFEs, and the like. The problem is: A lot of candidates who grew up with ES6 do not have this knowledge any more. It is still valid knowledge, and belongs to JavaScript fundamentals, but if you work on a modern code base, you will hardly notice these things in everyday life. Should I still be testing for this knowledge in an interview? I’m not sure. My colleague Patrick stopped doing it because he says nobody knows these things any more anyway. This is how you become an expert on a previous version of the world. In the world of software (and especially JavaScript), it can happen very fast.

Clueless manager

If you do not acknowledge that your people are becoming the real experts now instead of you, you will start second-guessing their judgement, questioning their estimates, or otherwise overruling them. Because you will probably be exposed to more business pressure in your new position, you will have an incentive to make your people finish things quickly. You will forget how hard software development can be. You will be tempted to persuade them to “just get it done”. Marcus Blankenship writes about how such behaviour can create a chasm between you and your people:

“When I asked one of my programmers about […] why the task was taking so long, I got the “clueless manager” gaze. He didn’t say anything, but the look on his face spoke volumes: “You have no idea how hard this work is, do you?” I’ll never forget how he looked at me. It was like all the goodwill and respect I had earned was draining out of him right before my eyes.”

So, be aware that your expert status comes with an expiration date. When others surpass you in terms of technical skills, be humble enough to accept it, and ask them for help when you need it. When they explain something to you, and you do not understand everything right away, then don’t be afraid to ask until you do.

Besides it being the right thing to do, this humility can actually do good things to the relationships with your people. It shows that you value and respect their expertise and judgement, and that you do not consider yourself somehow superior just because you have the word “manager” or “lead” in your title. It will make you more approachable, because you demonstrate openly that you are not perfect or infallible. Because you are approachable, people are more likely to come to you with good ideas, and problems are less likely to be swept under the rug.

The baby and the bathwater

Up to now, I argued that you should embrace, or at least accept, some loss of technical edge and the consequences this brings. Nevertheless, this does not mean that you should let go of all technical topics. You are an engineering manager, and your value lies exactly at the intersection of engineering and management. Non-technical managers cannot judge technical problems as well as you can. Non-management engineers cannot develop or coordinate people as well as you can, or optimize the work environment for productivity and focus. So don’t throw the baby out with the bathwater, but keep practicing your technical abilities.

Camille Fournier declares that Engineering Management Is a Technical Discipline. She emphasizes that, as an engineering manager, you are a translator between technology and product/business, so you have to be – and stay! – technical to understand each side. Moreover, your technology background enables you to guide decision processes and to ask the right questions. As Camille eloquently puts it:

“The technical side of engineering management is a combination of being able to quickly identify technical patterns and pitfalls, being able to guide technical decisions by asking the right questions, and knowing which corners are safe to cut.”

There are many more good quotes in that article, so I highly recommend reading it. If we agree, then, that we have to take care of our technical abilities, how do we effectively do it? Keeping up to speed in technology is a full-time job, but so is being an engineering manager. You probably do not have 20 hours per week to hide away and practise your programming skills.

The good news is that you do not have to put in 20 hours per week. I think the most important goal is not to lose touch. The moment you realize you do not know how to get your local development environment up and running any more, you are headed for dangerous waters.

In order to keep in touch, John Resig recommends to write code every day for at least 30 minutes. However, I think maintaining a certain level of technical knowledge is not just about writing code. Rands, in his brilliant article A Precious Hour, describes his practice of blocking off one hour every day for “building a thing”. “Building a thing” can mean a lot of things, including writing, experimenting, and aimlessly exploring.

If you are not in the mood to explore, but really want to build something productive, Oren Ellenbogen advises to pick small tasks (ideally, you should be able to complete them in less than four hours) that are neither time critical nor mission critical. This way, it will not do huge damage if you cannot finish them as planned. Tasks that increase our teammates’ velocity are especially attractive, so if you can automate or simplify a process, or reduce technical debt, these are worthwhile choices. Also, doing some research on a new technology, and maybe producing a demo using it, can be a great use of your time.

Point of potential return

Eventually, as you get more used to your new role, you should realize that there is something compensating for the loss of your technical edge. Maybe you realize that you can run really productive meetings where there is high participation, and everyone leaves with a sense of accomplishment. Maybe you find satisfaction in people turning to you for conflict resolution. Maybe you are proud because you know what is going on in your people’s professional and personal lives, because they trust you and tell you a lot of things. Or maybe you find it fulfilling to see a junior developer grow and develop with the help of your guidance and advice.

If, after half a year or so, you do not feel that you add value beyond your technical abilities, then you should ask yourself if it is better to stay in your new position, or if you should rather strive to get back on the technical track. The same applies if you do not draw any satisfaction from the non-technical work you do.

If management is just not something you can enjoy, then you will do yourself and the people around you a favour by yielding the position to somebody who actually wants to do it. Hey, maybe it was just not the right time yet. Andy Grove, the third employee of Intel, writes in High Output Management that he saw a lot of promoted engineers step down again, and tackle a management position again after a year or two. In a lot of cases, they did great at the second try.

What I want to say is: There is no point of no return, so make a deliberate decision.

P.S.: Check out my other posts on the challenges of new engineering managers. There is one on the feeling of lost productivity and another one on the feeling of being in the wrong place.

Time investment

This blog post took me about 3.5 hours to write and research.