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. You have 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. And 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 multilayer hierarchy and cross geo, Europe, Australia, US, India. And we were collaborating with a lot of teams around the world. So the company had a great engineering culture and the huge support for the engineers. Side note, when I mentioned 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. That green cycle, which represents the role with people management, are actually the managerial roles.

So roles in which you have people reporting to you, as bad as it sounds. And 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 calls 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 is a danger zone, where the most CTOs of the startups and the founders are in a lot of hats to wear on 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 a completely different path. And here is the example from the GitLab. As 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 a team, which was reporting to me. I was responsible for organizing the 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. And 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, 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 I had to deal with as an engineering manager, which was communication, team members development, be part of the hiring, using the right management strategies, and so on, so on.

Sorry for all of that, 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 the chance to walk through. We had the sessions with other managers, sessions with HR, role play sessions, and exercises. It was really great and 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 on the 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.

As a manager, it doesn't go down well, like 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. Like, everything is super vague. In the end, it was very concrete and helpful knowledge. But as an engineer, it sounded like bullshit, initially, at least. Also, at the time, I tried to write all the code or try 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 to ask myself, what am I even delivering? Do I even deliver anything? And the 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. So, those were really tough ones.

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. And the team becomes the center of gravity. So, 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 the 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 it's independent, because then you have the time for your work, which is developing strategies, designing changes, and your own innovations.

As a manager, you have way greater impact on the organization than you being a developer. Now you work as a team and the team is working to achieve this goal and this impact. Working as a manager was fun, my team was very satisfied, my coworkers, 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. But I know people who returned from the managerial role to the developer role within the same company. It's more likely to do in different teams, especially if you have a bigger company. And in general, what's changed for me after transitioning back to being a developer? 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 the products, I was working at the Jira and Atlassian ecosystem, to basically outsourcing.

Which is fine and is expected for you as a manager, because you're not interested in the such details until you, I don't know, manager of the React team, but you're rather focused on the systems and the interactions level. But for me personally, it was the point where 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 others' people work. That feedback, safety, sense of goal, sorry, feedback, sense of security, and goal are the foundations of a healthy team, like 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 to get back the role, even in the same organization.

But 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, 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. 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 the products, I was working at the Jira and Atlassian ecosystem, 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 like 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 was probably also a matter of the new organization, which was quite a detailed style. I won't go into details. I'm 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 an employee, as a person. You can always get back to the engineering role, at least after 15 months, as I did.

Please rate this speech and give me feedback. 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 a 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.