After six years as a Team Leader, I went back to hands-on engineering work, and I’m very happy about taking this step. While it may appear surprising at first, it was a well-thought-out decision, and actually I’ve already performed such a maneuver once before.

Background

A few years ago I stumbled upon The Engineer/Manager Pendulum by Charity Majors, and the follow-up post Engineering Management: The Pendulum Or The Ladder. I found both pieces interesting, and quite in line with my own experiences: in my previous job some time earlier I had been a team leader, but consciously joined Allegro as a software engineer. After a while, I became a team leader again, and recently, another few years down the line, I went back to engineering yet again.

Both above-mentioned posts make very good points, so I recommend you read them first. What I want to add on top of them are my personal experiences and some tips on organizing a transition between a management and an individual contributor role. The journey in the other direction (from developer to team leader) has been discussed in depth elsewhere, so I won’t delve into that.

Why

Why would I want to switch between developer and team leader roles? The problem is they are both interesting and have their own highlights, but you can’t do both at the same time. When you become a manager, not only do you have less time for technical tasks, but you also pretty much lose the ability to focus on these tasks even if you do find a time slot. This is because, like it or not, you end up with a manager’s schedule.

Over time, your technical skills start deteriorating, and if you miss the right moment, you may find yourself at a point of no return. Like a circus artist on a flying trapeze, you have to time your actions right to avoid disaster. I think this metaphor fits the situation better than that of the pendulum, which moves in its own rhythm, independent of external influences.

Obviously, you need to ask yourself whether you actually want to prevent your technical skills from deteriorating. Some people move on to management, wave goodbye to getting their hands dirty, and are completely fine with that. Some tinker with technology in their spare time. As for me, I like technology and would not only prefer to not lose what I have learned so far, but actually want to learn something new. However, due to a number of other hobbies and already spending more time in front of the screen than I would like, doing tech in the afternoons was not a viable option for me. Hence, the decision to make technology an important part of my job again.

How

A crucial factor to take into account when planning such a change is that it will take time. If you take your team seriously, you can’t just disappear overnight. You need to think ahead. Do not ask yourself “have I already lost my tech skills beyond repair?”. Ask yourself “how will my tech skills be a year from now?”.

Also, keep a cool head. Just as when moving in the opposite direction, from engineer to manager, consider all consequences, both positive and negative. It has been repeated many times that becoming a manager is not a promotion (being a lateral move to another career path), but in practice sometimes it is. In particular, it may come with a higher level or salary. Make sure you check all details of your target role in order to avoid unpleasant surprises when going back. In my case, I was aiming for the Principal Software Engineer role, which is the same level as the Team Leader role at Allegro, so there were no issues in this regard.

When I started thinking about making the switch, once I had a rough idea of what I wanted, I talked to my superior. This was an important step: it allowed him to plan ahead, and also to look for opportunities for making the reorganization easier. Some elements of the process would depend only on our actions, but some, such as finding a good replacement team leader, would also depend on a number of factors outside our control. Knowing that my boss understood my need, and supported it, mattered a lot, and made the wait and preparations easier.

Chance favors the prepared mind, as Louis Pasteur supposedly said. There happened to be a team leader in another part of the company who was thinking about moving on to a different area. Thanks to being aware of my plan, my boss was able to grab the chance, and we had a perfect match. We discussed with the potential new leader the team and the project, and he found them interesting. We planned a transition period, as short as possible, but long enough for me to transfer to him a reasonable part of my knowledge about the team and its work.

Now that we had a specific plan, we could tell the team. It was important to let everyone know as soon as possible, but not before we had a specific plan. Without it, this information would only stir uncertainty. Apart from telling the team as a whole, I also talked to each person individually, in order to resolve any questions or doubts and to try to reduce any problems resulting from the transition as much as possible.

Waiting for the switch date, we kept meeting online with the new leader, transferring knowledge and preparing him for working with the team. There’s actually quite a lot of stuff a leader needs to know: not only how the project works on technical and business levels, but also current plans, who the stakeholders are and how to work with them, and each team member’s individual strengths and development plan. The new leader himself also started meeting people he would now work with, both team members and our product’s stakeholders, and attending team meetings such as the daily stand-up. Despite gradually moving on to other tasks after the switch date, I was still available to clarify any doubts, and our boss would also help out when necessary, so the new leader knew he would not be left on his own. While it required quite a bit of work, the switch went smoothly, and we didn’t notice any serious disturbance to the team’s functioning.

The Aftermath

It’s been several months since the switch now. Me changing back to a technical role has certainly required extra work, for me, my boss, and the new team leader. Despite our best efforts, it probably put a little extra strain on the team as well. Nonetheless, I think it was a win-win, even more so thanks to us being able to spot and exploit a happy coincidence. I am glad to be closer to technology again, and the new leader also got to try something new, just as he wanted.

There is one more subtle advantage to the whole process. When people leave the team, some knowledge inevitably gets lost. One of the reasons is tacit knowledge: there are always things you know, but are not aware of knowing. You can use this knowledge when it’s needed, but you will probably not transfer it to others because you are not even aware of its existence in the first place. Removing someone from the team in a controlled manner as happened here (and being still able to reach out to them if needed) causes such latent knowledge to be discovered, and once discovered, to be propagated. This causes a little disruption short-term, but in the long run it reduces knowledge silos and increases the bus factor.

When I first started thinking about going back to hands-on technical work for the second time, I had some doubts about how much my technical skills had already deteriorated and how difficult it would be to go back. It seems I made it, but not by much. Had I delayed by one more year, I might have really struggled. It’s not a matter of knowledge: theory, especially generic things that do not change that fast with technology, is not lost so quickly. Also, while a team leader, I tried to stay in touch with technology by taking part in task refinement, architecture discussions, on-call rotation, etc.

However, I really felt, and to some degree still feel, a difference in practical, hands-on work, such as actually writing code. There are many small quirks that you need to be aware of in order to accomplish things quickly that you don’t even notice if you use them every day and know inside-out. Knowing all the little useful tools, the less often used features of your IDE, or what to do when something breaks unexpectedly, make a world of a difference, but this practical knowledge gets lost when not used and I had to rebuild it almost from scratch. Another thing that I still experience is the difficulty in focusing on a single topic. Working on a manager’s schedule for several years has taken its toll, and now that I often have large contiguous blocks of time, I find myself not using them as effectively as I could, because I have become accustomed to always doing multiple things at once and without a chance to stay focused anyway. It’s gradually getting better, but I still feel the impact, and this is probably my biggest surprise of the whole process.

About the Principal Software Engineer role

My current role is that of Principal Software Engineer (PSE). It is a relatively new addition to the junior, mid, and senior roles we’ve had so far. It has gone through a number of revisions, and is still evolving. Most people in this role come from a Senior Software Engineer background, so my case of getting there after being a Team Leader is a bit untypical. At many companies, roles like this are called Staff Software Engineer or similar. While still an individual contributor role, a PSE differs from a senior in several ways.

First of all, a PSE is expected to spend significant time on topics whose scope is much larger than a single team can handle. Seniors can also do this, but it’s not a requirement for them. Such topics may be area-wide, such as planning a major change to a single subsystem’s architecture, or have a company-wide scope. Much work on this level consists of coming up with ideas and discussing them while implementation is often left to others. So, while still technical, this role encompasses less coding than that of a senior. Not very surprising given that generally moving up the career ladder means more coming up with ideas, teaching others, and planning work, while coding less yourself.

Secondly, a PSE should be very autonomous. Most PSEs are not members of regular development teams since they move from task to task depending on where they can help most. This means you cooperate with more people from different parts of the company, but you don’t have the few peers you work with every day that most people have. You don’t get a backlog of tasks to work on, but have to plan your work yourself. People do come to you, asking for support or doing something for their project, but that’s just one of many inputs.

Thirdly, since there are few PSEs compared to other positions, for each person the role is a little different. On one hand this means you can’t fully know what to expect when you start. On the other, you get to shape the role yourself, and personally I enjoy this flexibility.

Summary

I think the idea of swinging back and forth between engineering and management described in The Engineer/Manager Pendulum, is valid, and my own experience backs it up fully. One element which I want to additionally stress, however, is that the switch is more like a flying trapeze than a pendulum: timing is crucial, and missing the right moment can have serious consequences. Becoming a Principal Software Engineer was a unique experience, both on a technical level and as my de facto last task as a team leader. Who knows what the future holds? Perhaps some time from now I’ll take another swing on the flying trapeze and go back to management?