From Backend Developer to Engineering Manager
Wow ! September already ? That means I have already been working as an engineering manager for almost a year. To think that I was a backend developer last September… Time flies.
Last October I changed roles at OpenClassrooms : from backend developer to engineering manager (EM). I’ve learned a lot about the differences between the two jobs, some that I expected, some that I absolutely didn’t. I thought I’d write this article for anyone who might be hesitating to take on the same journey. And I believe some of these insights could easily apply outside the coding world, to anyone who would consider changing roles from individual contributor to manager.
Disclaimer : The EM position can be very different across Tech companies. I won’t be describing here how we work as EMs at OpenClassrooms : this article here explains our vision pretty well !
Why did I do that ?
In my previous job I discovered Non-Violent Communication and the power of a human connection that actively engaged our emotions. That was a 180° turn from what I had been led to believe by my engineering training, where I was always told to focus on raw facts and push emotions aside !
That was the spark that ignited an ever-growing interest for human emotions, psychology, relationships, people dynamics, and organizations.
Afterwards in the same job I also faced a lot of situations where the technical issues, though important, ended up being mere symptoms of organizational challenges — if not secondary issues, clearly less important than organizational ones. This also fueled my interest in human matters and relationship issues in tech teams.
These two experiences drove me towards a management career track rather than a technical track.
Side note :
I’m lucky to have had the luxury of asking myself that question. In too many companies and industries, the default career progression (if you keep improving in your job of course) still goes straight from good individual contributor to manager…even though the skills required to be a good manager are very different from those required to be a good individual contributor.
In the programming industry, some companies (including OpenClassrooms) have realized this skill difference, and have also realized that some people can really grow, keep improving their performance, and broadening their impact, while keeping their hands in the code ! This led to job positions such as “Staff Engineer” … and Engineering Manager for people who actually want that job.
So I could have had a career as a backend developer, and I could become a manager. The choice was all mine.
How ?
I joined OpenClassrooms as a backend developer, but with all the previously mentioned human-centric interests in mind. In the first months I made a few suggestions in that area : I started by facilitating a workshop within my new team to help everyone get to know each other and prepare ourselves to work together. Later I began facilitating Non-Violent Communication initiation workshops for people in the tech team who were interested.
That promptly led my manager to understand where I was heading, more in the management direction than towards the “expertise” career track. Having both agreed on that, I felt encouraged to continue in that direction, and got more involved in organization matters within my squad.
I also started to try to build a habit : whenever I found myself thinking “I should / will ask my manager about that”, I took a moment to ask myself : “if I were an Engineering Manager and one of my reports came to me with that question, how could I answer ?” I’m (definitely) not saying I had the right answer (or any answer) everytime, but this habit helped me picture the job in my mind. It also helped me to gain a lot more autonomy, making me realize I could figure out much more by myself than I thought I could !
A couple months later, a topic that would involve the whole engineering team came up : defining the team’s values. I was concerned about the outcome of the process so I raised my hand to help define the workshops and the decision process… And in doing so, I started working with the EMs on a management topic.
The EM team started to talk to me about joining them… I hesitated, then I read Radical Candor. That book describes very well how a manager’s job can be deeply fulfilling and enjoyable, while also providing great tips and tools. That gave me both motivation and confidence to try and change jobs !
At this point, I had to go through an internal recruitment process : as I already said before, the skills required to be a manager are not the same as those required to be a backend developer, so it’s not as straightforward as a promotion !
To sum up, if you’re beginning to consider a career change from individual contributor to manager, I would recommend to :
- get information about management (I loved the book, but there are many others and many non-book information sources you can find !)
- start getting involved in some human matters at the level closest to you (your squad for example), try to identify what slows you down and how you could improve
- find support around you, maybe you can start asking your manager to tell you about his or her job and how you could get there ?
- you can also use my thinking trick “how would I answer that as a manager ?” if you think it can help !
What I learned in the first months
I experienced quickly in my day-to-day job the main, obvious things I had already been expecting (which still apply today) : I spend much less time programming (… no time at all, actually) ; I have bi-weekly one-to-ones with my direct reports, to know what they are working on, and try to figure out how to help them if ever they encounter a problem. And mostly, I am invited to way more meetings with a lot of people.
Another thing I found out was an unexpected benefit from having been a developer, alongside people I was now managing : I already knew the people I was working with, the company culture, their way of working. That helped me get on board more quickly.
Also, having worked alongside them, I know how much they are involved in the mission, the product, and the code quality. That gave me confidence that in my first months, I could focus on one-to-one relationships and long-term vision, which were the topics that motivated me the most at that time. That also helped me get on track quickly and stay highly motivated right from the start !
I also know what is important to them in their daily jobs, so I can figure out more clearly the level of importance of their requests… For example I know how important it is to have a working CI/CD pipeline that doesn’t eat away hours of your day !
Last but not least, since everyone knows about the two career tracks (management/expertise), the relationships with the newly-appointed direct reports could start on a healthy basis : we both knew we were where we wanted to be, me, as a manager because I chose to, them, as developers because they also chose to.
What I figured out later
A couple months later, I had a weird feeling. In all my previous experiences as a developer, I started to feel more comfortable after a couple weeks or months, with at least my first feature pushed into production, or at least some working code. Now, that comfortable feeling wasn’t there.
It was then that I realized it came from the very nature of my job : a manager’s actions are by far more “blurry” than a developer’s (and I believe it can be true in general for any individual contributor’s job).
Indeed, in a developer’s job, my day was punctuated by concrete actions :
- write unit tests
- write code
- launch tests
- send my code to other developers
- review other people’s code, approve PR or ask for changes
- deploy into production
And these actions yielded clear, binary feedback at each step :
- the test result is either red or green
- the commit is successful or fails with conflicts
- my PR is approved or changes are requested
- the deploy is successful or unsuccessful
- the bug is fixed or not
But as a manager, what I do day by day doesn’t come with the same clear-cut feedback. I set up meetings, I go to meetings, I listen, I think, I give my opinion, I propose ideas and I challenge other ideas. And most of these don’t trigger an immediate feedback. People don’t turn red or green (unless there is some other major issue that requires immediate medical attention).
Don’t get me wrong, I do get some feedback on what I do! But it’s less immediate (it can take months to see the results of some actions), and less predictable (people are less predictable than machines).
All in all, that made it more difficult for me to figure out, day by day, if I was doing a good job or not.
I had to figure out other ways to get feedback, from my manager, my reports, and my peers.
What I knew but I’m still learning to do
There is another great difference between the two jobs. It struck me on my very first day… But I’m still learning today !
On my first day as a manager, I had a lot of meetings scheduled on my calendar. But I also had a couple hours without any meeting. I eagerly waited for these hours, as I usually did as a developer… And then… Meeting’s over. Wait. What do I do now ?
No Product Owner had filled my Jira board with a backlog of well-defined tasks I could just take on…
Oh. So, figure out how to organize my time, what to do, when, how… That’s on me too ? Wow. I knew it but it still feels different when I experienced it for the first time.
My former manager called it “be your own manager”. It’s a tricky work that involves
- figuring out what are the main topics to work on
- figuring out the next steps for each topic
- figuring out how to put them in motion
- actualizing the priorities very often
- all of that while managing time between meetings
- and taking into account the fact that most of the so-called “next steps” involve discussing with someone else with an agenda as busy as mine.
That also involves choosing the meetings I agree to participate in, and sometimes choosing not to participate in one, to avoid getting overwhelmed.
Yes, that’s a lot. Yes, that’s difficult. I did tell you I was still learning !
I already figured out a couple tricks that help me : every Friday, I take a look at what my agenda looks like for the week to come, and I take some time to make it cleaner (move some meetings, decline some invitations, etc). And every day, I take some time to define my daily goal : one task, no matter how small, that I want to have finished by the end of the day. That one also helps me deal with the “blurry” side of management, by the way !
Why I’m happy about my choice
All these differences I’ve listed here really are challenges. I have much to learn, everyday ; more than I ever had to learn, I think. But I don’t have any regrets and I wouldn’t want to go back. Because everyday I focus on the topics that interest me most : human relationships and team organizations.
Also, it has been a year : long enough for me to pick up some ideas that help me ; to have gained enough knowledge to be able, sometimes, to effectively help the people I work with ; and also, long enough to have been able to get some feedback on some actions I’ve done a couple months ago. In some cases, I can now offer insightful solutions to people, thanks to my knowledge of what happens in different teams, or sometimes thanks to something I had been reading about… And I really feel like sharing these ideas feels better to me, more creative, more helpful to other people, and more personal, than any idea I’ve had before in tech discussions. Sometimes also I get late feedback on an idea that I had months before… and I realize this idea had a great impact on a couple people’s relationship or motivation… The feeling I get when I hear that is very, very rewarding !
In short, I feel like I’m where I belong, and I plan to keep on growing from there !
