IC or EM? Why not both? — My journey in Exploring the two roles beyond Senior Software Engineers
Naturally, when one has been in a senior engineer position for a while, one would wonder what’s next. Your manager may have queried whether you’re interested to grow in ‘technical’ (IC — Individual Contributor) or ‘management’ (EM — Engineering Manager) path more. You may already know what you want, or the situation may already have force-selected the path for you.
Some of you may have born ‘people-oriented’. You might have a superpower to understand, emphasize people. You might have a passion to grow people (or just like me — wanna make them happy so that I can be peacefully surrounded by happy humans).
Some of you may be deeply fascinated and excited purely with the technology. You might have a superpower of producing robust, scalable and high quality software products from design to deliver (or just like me — fell head-over-heels in love with Android development and always seek opportunities to code for it).
Or some of you, may be just like me, have a bit of those two points. The problem is… What do we choose?
But do we really need to choose??
We’ll come to this question later. I’ll share some of my experience on the responsibilities & tastes of both roles I’ve explored so far.
Background a bit — Me & My company
I’ve joined my current company in 2018 as a Senior software engineer (focusing mainly on Android), it was a very early stage StartUps company. They have just launched an MVP pilot test with the first customer a month before I joined.
Years after that, we’ve worked together to develop the products and scaling the team. For the first few years we didn’t really know how to structure the software team yet. We did trials & errors, which, as a result of that, I was promoted to a mobile team leader in late 2019. That was the first time I touched the ‘EM’ surface. However, the mobile team members couldn’t scale up from 3 people until 2022 (We recruited, they left, repeat). This means that, as I was the only ‘stayed’ person, I needed to take care of the technical knowledge and development direction of the mobile applications. This is the part where I tasted some of the ‘IC’ tasks.
Fast-forward to mid-2022, we have re-organized the team structure, with more description of each levels from junior (T3) until very high up (T9 or T10 I think). Someone like me, who did a bit of both things (and enjoyed some of this and some of that from both sides) now is expected to ‘pick’ one path to grow.
In 2022, I picked IC
To be honest, at that point, as someone who joined the company early and participated in almost every high level technical discussions before, I didn’t really know what are the differences between senior & senior+ software engineer positions. I selected IC only because I was the most senior mobile engineer in the company, and someone needed to take care of the technical aspect of that, wasn’t it? I have expanded my skills from Android, to Flutter, to iOS, to satisfy the company’s needs. I went to meetups, pursued a lot of mobile-related practices & knowledge for each platform, to ensure that the company still has adequate and up-to-date knowledge to maintain our mobile apps at high quality.
Apart from mobile technical, I also learned how to do product management and basic concepts of UX / UI design, and some of software testing principles (I also tried to study Javascript full stack thingy, but didn’t work. I just wasn’t cut up for that). All of this effort is, to ensure that, if necessary, I can step in to perform any tasks in the development pipeline.
Little did I know that, those wasn’t the ‘real’ expectation for the senior+ IC software engineers, at least in the context that our CPO would like to build the team to be.
Then in early 2023, we’ve successfully recruited an exceptional mobile engineer, which is a very good example of a real IC engineer. And that’s where I begin to think that, maybe, I might not be well suited to that path because I’m not as tech-y as him.
Anyway, around the same time, there was a project that required someone to lead. At first I volunteered only for a small part of it, but then, higher up, there wasn’t really a responsible software engineer to look over the big picture. With that, I was forced to take up the challenge and led the project to almost successfully launch (we got a product direction change in the last minute, delaying the launch). I needed to write a technical spec, managed the timeline and ensured every connected parts were done on time. This included a lot of conversations, both with the software engineer peers (QA included) and the non-technical product managers / owners. I also drafted a test plan because the project itself touched many domains, and required more than one squads to contribute.
Leading that project, I got a glimpse of what a senior+ IC engineer is expected to do for the first time.
And in mid-2023, I was asked to explore the EM path
Stepping back a bit, in fact, throughout 2022, I directly managed four mobile engineers and voluntarily supervised one QA engineer (until we recruited a QA manager). In the end of 2022, The software team was restructured to be squad-based, with (ideally) every squad members should be managed by their squad lead. I (might be cockily incorrectly) believe I was a candidate for one squad lead, but I have decided to pick IC then (with the reasons above). This caused another EM to lead two squads, managing 9 engineers, including me (I offloaded my two mobile engineers from him to reduce his workload though).
Jumping back to mid-2023, in an 1–1 session with that EM, I’ve agreed to manage my squad, mainly because I want more control on the deliverables, the team morale, and the process. At first it wasn’t the commitment to be an (intern) EM, but the CPO talked me into it. In the 1–1 with him, he asked if I want to explore the EM path. I told him that I didn’t really know what to expect and what to do in that role. I did know that what I enjoy was analyzing the product problems and crafting solutions. He assured me that such I’ll still do those activities even if I act as an EM. With that, and with the company’s needs, I accepted the challenge.
And here we are. Currently I’m managing the squad’s 5 software engineers. It’s challenging for many reasons. I begin to learn that being a coach is a different art from a problem solver. Sometimes, people just want to be heard, rather than hearing solutions. Asking the right questions for them to think is a key in growing them. My main responsibility now is not solving the problem, but helping the people to solve them. Lucky that I’ve practiced some of my mentor, coaching and other people skills before in & out of work scope.
But do we really need to choose??
Back to this question now.
I would say it depends on yourself, and your context (company). I saw people juggling back between these two. In the end, growing beyond senior levels always involve ‘people’. Actually, prior to then, it also always involves people, mostly yourself, your teammate and your manager. The senior+ expectation requires you to involve with wider range of people. You need to own larger scope of the product development, in which you will need to utilize both technical and management skills. No matter what you choose now, you will gradually learn another bit as well. Either through someone who help you on that part, or by you yourself do it. So I would say that, you might need to choose, but rather than like a ‘either this or that’ choose, you choose how much ratio you want to work on each bit. You may do 40% IC and 60% EM, if you are (and your manager is) happy about it.
Let me know your views on this. As a newbie post-senior software engineer, I would like a lot more ‘how to’ insights from the experts as well. The resources are quite limited comparing with the pure tech-y ones. I hope that my experience benefits someone who’s in (or about to be in) the similar situation.
