Journey of Transitioning from IC to Manager Role
Experience and Learnings of six months in manager role
5 min read
Transitioning to anything new is always challenging but it comes with its own learning experiences and change in mindset. Six months ago, I transitioned from Individual Contributor (Software Architect) to a Manager (Engineering Manager) role. It has been a great learning experience for me. This post is about my experience and learnings of the past six months from this transition.
Note: Working on my writing skills :)
Shared below are a few of my key learnings.
This would be one of the most important learning. In this, you learn that now your responsibility is not to jump to solve a problem directly but to find the appropriate person to handle it. One example could be like in case some issue arises on the platform, the primary task would be to find the appropriate team member who can address the issue. Though it will depend on the criticality of the issue as well :).
Resolving the issue yourself may seem to be a better and faster approach but delegation will help you to focus on more strategic tasks. You should definitely guide and mentor them, provide feedback but let them take the lead.
Mastering communication is a very crucial interpersonal skill. It will be the prime responsibility to keep all the stakeholders updated about the progress. Stakeholders can be your team, VP Engineering/CTO, Sales Team, Customer Success Team, Operations Team, etc. depending on your organization structure. I being in the IC role earlier used to like solving problems, coding and not focused much on this area. The communication was more in the form of design documents, code reviews, KT sessions, etc but lesser in form of emails, tickets, etc. But now being the spokesperson for the team, I am required to make sure folks are getting required updates. It could be details about the release deliverables, on-call support, bugs resolution status. Communication is not only limited to the updates but also informal communication with the team. You need to provide clear purpose and direction to the team, conflict resolution, having empathy with the team especially in the given pandemic situation. There is a lot more to express in this section but I will keep it brief at this moment.
In the new role, mentorship has a much broader scope. Earlier I used to do mentorship as well but it was more around being a better engineer like understanding design patterns, new technologies, etc. but now it is like seeing from overall career path which includes both tech and non-tech mentorship. Providing feedback on how to be more organized, better estimations, guiding towards taking more ownership, etc.
In the transition, I learned that I need to keep calm in any discussion when there are differences in opinions or things are not working out as per expectation. Generally, I try to gather the data points or ask for the same in case of others' opinions. In my experience, this holds good for every level (IC or Manager). Though being in the manager role, you need to be extra cautious, listen to everyone about their views, and then take the balanced next steps.
Bird Eye View
In an IC role, I was mostly required to have a short-term view with few exceptions where architecture decisions are required. In the manager role, it is required to have more mid to long-term vision related to product quality improvement, process improvements to keep up with team growth, identifying the bottlenecks, and have a roadmap for resolution. Along with this, it is also required to have better planning and prioritize the tasks correctly. In the IC role, I used to be mostly like a single thread but as a manager, it is required to take all the requests and then prioritize, delegate, and update the stakeholders. As there is a saying "You can't improve what you can't measure". One aspect of bird eye view is defining high level KPIs, equip with the appropriate tools, have effective tracking mechanism and publish them for visibility.
Since I am required to be available for different discussions and meetings, managing the time is a must. One of the techniques I found for better time management is to defragment your calendar. What it means is to schedule the meetings on few specific time blocks. It may not work for the cross-function meetings but should be able to handle discussions happening within the team. In the initial few months of my role, I used to have small blocks of time available between different meetings which were not enough to do any productive work. After following this defrag technique, I have bigger time blocks to concentrate on different tasks. Another co-related thing from time management is availability. Being an IC, you have the flexibility to work based on your schedule (at least in my organization) like early morning or late night. But as a manager, you need to be available at a general time when most of the team is available.
This transitioning also brings learning new tools. From code editor to Jira board, from measuring API response time to measuring sprint velocity, things get evolved. I needed to make sure I learn the new tools to have better visibility and measurement of team progress.
There are many more learnings during the journey but I felt the above contributed majorly. I feel there is still a long way to go to acquire the skill and maturity level. Till now it's been a fun journey. Though sometimes I miss the hands-on coding time ;).
I hope this post provides some insights about the mindset changes and learning of the transition. One thing to note here that the responsibilities may differ from organization to organization. You may have lesser involvement on the tech side in large organizations where tech leads handle it mostly while in case of startups there can be more involvement in tech.
Connect with me if you would like to discuss more about the journey and please do let me know if you have any suggestions/feedback for my management track or the content of the blog.