A Transition: From Being a Software Engineer to a Program Manager
The Why
I have been exploring the idea of taking a new role in the Software Development Lifecycle process for quite some time (will be shortened to SDLC onwards). I believe it’s mostly because of my curiosity, of wanting to have a broader yet generalized knowledge, rather than being an expert in a set domain.
Being in the software development industry for quite some time, I feel that this industry is actually intriguing and still has a lot of areas yet to be explored. After some self-exploration, I found that being a Program Manager is suitable for me, as the role really hugs the process tightly, yet it somehow doesn’t stray too far from the familiar engineering world that I had been accustomed to. Hence a path was paved for me, as there was an opening in the role itself at Moka.
The Knowns
Nearing the role transfer, I have a gut feeling that the transition will come smoothly. I believed that I already knew how to navigate my way when I decided to take a new role. These are some things that I already knew will help me in performing my tasks.
- References from Reading Sources and Others
I’ve read a couple of articles about being a Program Management. I’ve spent some time getting to know the outer layer of the role because I wanted to make sure I’m ready before I actually get hands-on experience at being a Program Manager. It is easy to get into references nowadays, since the internet is a great source of information. - Besides that, I have been privileged to be able to ask questions to other Program Managers at Moka, who are also my best coworkers. They are my go to person on the know-hows on the job. Hearing their personal stories helps me understand their personal difficulties in handling a team.
- SDLC and the Terminologies Used.
I have experience with the SDLC process from being an Engineer myself for almost 5 years already. Being that long in the software industry helps me understand the terminologies used in day-to-day discussions. Knowing how the API works, how the databases work, usage of different development environments; most are the concepts that are familiar for engineers, which I believe helps me in getting context of what is being discussed. - Scrum
We are using Scrum for the project methodology, of which I am proud I can stand my own weight in. The whole Scrum process is very familiar to me as my previous company also uses Scrum. This enables me to quickly understand how to do the Scrum events and set up the Scrum for the improvement of the team.
The Unknowns
Even though there are things that I am familiar with, there are still some unexpected things that pop up when I myself become a Program Manager.
- Scheduling Time
The time scheduling can be very difficult for the Program Manager position. I only realized that there are a lot of catch ups and meetings that I need to attend. I also have to fit in the Scrum events into my weekly schedule, that sometimes might conflict with each other. Not to mention, if someone has to manage more than one team, it adds the complexity of an effective scheduling. - Being Vigilant
I also only learned the real meaning of the word ‘vigilant’, as I became a Program Manager. Currently if there are any incidents that might happen, I have to be one of the first people to grasp the situation and relay that to the team, to find the solution. It also teaches me that being vigilant is not only by being reactive to an issue, but also being proactive in listening and sensing other’s needs, as your assistance might be needed at any given moment. - The Number of Documents
It is quite surprising knowing the number of documents we have gone through. While software developers have their own fair share of documents themselves, it can be mitigated with the codebase itself, which some might say self documenting. - However, in Program Management, the documentation is a different thing. It enables cross functional teams to collaborate with each other. Hence, the documents should encompass all the things that might affect the organization as a whole, which explains the sheer number of documents. On top of that, documents have to be extra clear and easy to understand.
The Helpers
Learning these new things I hadn’t known before set me back a bit. But this is not without its remedy. A couple things come in mind, which helped me get back on my feet
- A Clean Handover
A smooth handover and knowledge transfer gave me a glimpse of what the team is doing and what are the impediments that halt the success for the team. This enabled me to quickly grasp what the team really needs. - Support from Peers and Supervisor
My very supportive peers are the main reason for me to be able to adapt to this transition quickly. They are very cooperative and responsive for everything I inquire. The supervisors at Moka are also very open and very constructive on how to build my career in this new path. - Accepting that Everything Has a Learning Curve
A dear friend says to me that everything has a learning curve. There is always something new in life. Hence, instead of worrying, I tell myself that making mistakes is part of the learning. This gives me the courage to strive on.
That was the thing that I am experiencing in my transition to a Program Manager. It gives me a much soughtful different perspective in the software industry, which I am keen to explore more.
Special thanks to Rheza, for being a good friend, a good mentor, and a good editor, making this writing a realization.
