From Senior Developer to Manager and Back: The Journey of Returning to Coding

Imagine this. One day you join the meeting and you're getting the proposal to move to the leader-manager position. Wow, such an occasion, promotion, far, far, ta-da. But within a moment, a storm of questions starts brewing in your mind. Will I forget how to code? Will my skill become obsolete? Will I still be a technical person? Is it a good decision and is it possible to get back to being a specialist?

You're thinking about it, and yeah, you're doing it, but with the assumption that it will be an experiment and you will leave yourself a loophole to get back. Yeah, that's me. And that was my story. I was at that point. I worked at Atlassian as a senior software engineer and transitioned to a team leader role. I led a six-person team. I worked in this role for 15 months, and me. So my name is Michał Michalczuk. As you see, I don't work anymore in Atlassian. After my experiment, I got back into a software developer role and work as a consultant in texting consulting, a small Berlin-based consultancy agency.

I'm also a talking head at the various JustJoin IT formats. You can find me as well on their socials. But getting back to the topic, small disclaimer, I am sharing with you exclusively my perspective. So what was my context as a manager in Atlassian? Team leader had to be at least a senior software engineer. Previously, the P5 position, it was the large organization. At the moment when I was leaving the company, it was 8,000 employees. We were multi-layer hierarchy and cross-geo, Europe, Australia, US, India, and we were collaborating with a lot of teams around the world. Also, the company had a great engineering culture and a huge support for the engineers. Side note, when I mention manager, I am referring to the role in which we have the direct reports.

So what was my role then? I was a team leader, but what's behind the term team leader? Well, the scope of the duties and responsibilities may vary from company to company. So let's take a look at the entire spectrum of the technical roles and try to spot mine.

So we have three main areas. The building software one, the strategy and alignment, and the people management. The green cycle, which represents the role with people management, are actually the managerial roles. They are the roles in which you have people reporting to you, as bad as it sounds. And tech leader, tech lead manager, and engineering manager can be confusing a bit. So let me try to split between those two. The tech lead manager is responsible for technology, for example, for specific systems and they write the code themselves. They are more likely to delegate people there, to distribute there, but they still write a software. Then on the right, the engineering manager is responsible for the development of people and their teamwork. What's to add? At the top, you can see the staff engineer, which can also be known as a principal developer or an architect. And in the very middle, there's a danger zone, where the most CTOs of the startups and the founders are in. A lot of hats to wear at the same time, but this is not the topic for today's talk. And as we already mentioned those roles and this split, I must add that the managerial path is not the only option to get promotion and to be promoted after the role of the senior developer, at least in many companies, thankfully. So we can go down the engineering path and become staff or principal engineer. We can go to the managerial path. We can move between those roles or even turn down to completely different path. And here is the example from the GitLab. You see those paths here, the managerial one, which is on the top and the engineering one, they are parallel and almost to the last level, they still go in parallel.

But going back to the diagram, my role was engineering manager. I had the team which was reporting to me. I was responsible for organizing their work and the team strategy, the team goals and the team development. I was also technically representing the team outside, when necessary. Outside of the team, outside of the company, from time to time.

And I made some top-level technical decisions with the support of my team, mainly based on their recommendations. What I didn't do anymore was writing the code by myself. But I wasn't left alone. I mean, in both leading the team and the project, we were running it as a triad. So me as a manager, the product manager, so the product person, plus UX, so the design person. And my team was also part of the bigger organization, so I also wasn't alone there.

And getting back to the roles itself, which roles cover what? The smaller the company, the more responsibilities is concentrated in one role, even on one person. I worked in a larger company, so let's focus on that. I was responsible for how? As a team, we could achieve the goal and when. So in a nutshell, since there were more responsibilities. So, by the way, in the preparation for this very talk, I wrote down a list of topics that I will not be covering. And guess what? I accidentally wrote a list of topics which I had to deal with as an engineering manager, so I had to deal with cross-communication, team member development, be part of the hiring, using the right management strategies, and so on and so on. Sorry for the wall of title, but I found it pretty funny.

And there is a bit of it, and it can be a bit overwhelming, especially in the beginning. So what was my beginning then? Well, we started the team with two people, with whom I already worked with. Then the team grew. In parallel, I was on the upskilling course, the Atlassian Apprentice Manager. It took like three months with commitment around five to six hours per week, and a lot of external resources. We had a chance to walk through, we had sessions with other managers, sessions with HR, role-play sessions, and exercises. It was really great and a huge support. And for me, it was a very soft start. Also, because you can always get back to the IC. By IC, I mean individual contributor role. If you decide that, hey, this is not for me, being a manager is not for me, it's a common practice in big tech. Also, I started to appear in a large number of the new meetings and the new conversations on Slack, but no one at that point requires a lot of input or contribution from me.

It was more like a form of learning by osmosis. And in my honest opinion, that soft start was really helpful. Yeah, but there are buts, of course. The word manager, it just doesn't go down well. You don't feel it represents you. It sounds very stupid, but yeah, that was the issue, at least for me.

The initial reaction to the courses I watched or read as part of the upskilling program was like, this is bullshit. Everything is super vague. In the end, it was very concrete and helpful knowledge, but as an engineer, it sounded like bullshit, like initially, at least. Also at the time, I tried to write all the code or tried to write some technical specifications, but there is no option to do that anymore when the topics are multiplying and the team is growing. So yeah, I just have to let it go.

And I started asking myself what am I even delivering? Do I even deliver anything? And that sense of the delivery, the gratification is strongly delayed in this role, and that was hard. That long-term gratification, on the days and weeks, which is the feedback loop for you as an engineer, you're turning into months and years. Suddenly, you have a lot of small topics to deal with, which are distracting you from those big, fat topics, which are important. You have context switching at the finest, a lot of reactive work, which is awful. You feel that you're drifting away, technically, at the code level, and you have to do that was the worst. You have to do a step back and hand over to the team the topics that you would love to pick up as an engineer. Those were really tough ones.

And the important one, the most important one is now that, after changing the role, the center of gravity shifts from you as an individual contributor and your individual work to the team. The team becomes the center of gravity. If the team is the center of gravity, what gives you, as a manager, satisfaction? Well, team success. New releases, innovations introduced, blog posts published, and so on. When you see that the team sees the goals and contributes to it, when you see that the team's visibility and role in the organization grows, when you see that people in the team grow themselves and they develop, when you can promote them, and when the team works on its own and it has influence and is independent, because then you have the time for your work, which is developing strategies, designing changes, and your own innovations. Please note, still everything revolves around the team, not around you as a manager.

And there is one thing... One sip of water as well. And there is one thing that concerns you. I felt great when I finally got it and understood it. It's that as a manager, you have a way greater impact on the organization than you being a developer, because now you work as a team and the team is working to achieve this goal and this impact. All right, so I'm praising it a lot, but why did I go back to work as a developer? Well, working as a manager was fun.

I really mean it. It was a great time. My team was very satisfied, my co-workers, my management as well. But at the same time, I've missed the hands-on, I've missed building things, designing things. I just missed working as an engineer.

And I remember the moment when I was preparing for one of the morning shows with the front news, which we used to record at that point of time, and I was reading the article by Ryan Carnato, the creator of Solid.js, about inconsistencies of local site management in various JavaScript frameworks. And it hit me like, oh my God, I didn't work with something so low-level for a while. Suddenly, React component details become low-level for me. Not the assembler code, the assembly code, the React component details, which is fine and is expected for you as a manager, because you're not interested into the such details until you're, I don't know, the manager of React team. But you're rather focused on the systems and the interactions level. But for me, personally, it was the point when I knew that I'm just missing it and that I love to deep dive and work with the details. Yeah, and at that point, I just wanted it back.

So was my experiment a success? What did I learn? That it's not only about you. It's about the team, always. I've learned how to do time and task management better, that effort overpasses the results, especially if you're evaluating other people's work. That feedback, safety, and sense of goal, sorry, feedback, sense of security and goal are the foundations of a healthy team, always, regardless of the role you have at the time. And that manager is not the accountant, that it's not a person who just feels the axle. And if that's how it works in your organization, it's missing its point. And that it's still not one-way ticket possible to get back in the role, even in the same organization. And I know people who returned from the managerial role to the developer role within the same company. It's more likely to do in the different teams, and especially if you have the bigger company, then it's just easier to do. And in general, what's changed for me after the transitioning back to being a developer? Yeah, which you already know. I've changed my roles back. And I also moved from the 8,000-people organization to the 20-people organization. And from the one which has a multi-level hierarchy to the flat structure one. And from the company which has all products, I was working at the Jira and Atlassian ecosystem fork to basically outsourcing. Here, I still prefer product companies. But getting back to the development, after a month, I felt very comfortable with programming and coding again. But returning to the individual contributor role and moving to a small company with a flat hierarchy, it took me five to six months before I felt 100% comfortable. And I'm putting this all together because it's hard to point which actually change had the most impact.

And it was probably also a matter of the new organization, which was quite a technical style. I won't go into details. Happy to chat about it online or at the coffee desk at the conference.

So at the end, from me, a few tips for those of you who are starting out as a manager, or consider it my top three. Remember, you're not alone. Helpfully, talk to other managers. The second one, have regular one-on-ones with your team and with your manager, your supervisor. Don't let things fall between the cranks and be open to the feedback, which can be hard. And it's not about you anymore. It's about the team. If they're delivering and they're performing well, you're doing the right job.

And if you're still on the fence, is it worth it? From my experience, yes. You will gain new skills, new perspectives, and you will grow as a team. Employee, as a person. And you can always get back to the engineering role, at least after 15 months, as I did. Please rate the speech, rate the speech and give me feedback. We speakers, we are fed by the feedback. So I would love to know your opinions on the talk and on the topic. Please do. And thank you very much for your time. Feel free to reach me online or at the event. I'm also here. Also, under this QR code, you can find my presentation with the commentary and links. So feel free to take a look at it and play with it. And thank you one more time. Have a great conference. Bye.