The “Backwards” Journey From PM to Engineer: Why I Chose Code
My journey from PM to Engineer: A series of lessons Learned from a Backwards Transition
In today's tech landscape, you often find technical PMs who were once engineers, but as you’ve probably guessed, I’m doing things a bit differently.
This article aims to begin sharing my journey with you and start a series from my experiences in this move that defies the norm.
Why Make the Switch?
As a lifelong learner, I’m always looking to discover new skills, and I initially got thrown in to be a Product Manager out of necessity.
The problem-solving was interesting, you’ll have a new unique issue to solve in an ever-evolving landscape, but dealing mostly in an abstract space.
Having good soft skills is important for thriving in a fast-paced environment. It's also crucial to maintain organization and healthy habits so you don’t fall behind.
The real reason I enjoyed it was the ability to help people directly and resolve human problems by empowering them to make beneficial decisions.
After a while, I got antsy to make tangible progress and see a more concrete result of my work. As a PM you rarely get to see the everyday consequence of your work outside of the product itself, so I wanted to be proud of the details that I helped implement daily.
Adjustments to Daily Routine
The roles of a PM and Developer differ greatly, so I’ve had to change my daily routine to better optimize the day for my job.
Pair Programming
Pair programming is a popular approach where two developers work together to implement features. One developer acts as the driver, while the other serves as the navigator.
As a PM I collaborated with other teams, but not in a constant stream within a virtual room or in-person like I do with pair programming. Although I attend fewer meetings, I still feel the dreaded “Zoom fatigue” from being on a call with someone all day.
I’ve done my best to encourage taking breaks when needed, as even a 5-minute break can refresh your brain and help you view an issue from an entirely new perspective.
Problem-solving mindset
I’ve learned it’s beneficial to place myself in a “problem-solving” mindset by doing things like Codewars exercises, watching YouTube tutorials, or reading. This helps put me in a better headspace to approach my day and whatever new learnings may come my way.
Currently, I’m reading TDD by Example and listening to The Unicorn Project by Gene Kim
Daily journal entries
Another practice I’ve learned to be vitally important to my daily routine is keeping a daily journal.
As a PM I did this, but more to keep track of taskers and what I had done that day. As a developer, my journal looks much different.
I’m learning so many new frameworks and refreshing on concepts I haven’t touched in a long time so I’m taking notes daily on what I need to go back and research, and what I’ve learned each day.
This has drastically improved my confidence, as I can specifically reference areas where I felt weak and work to improve them by setting incremental goals.
Benefits of Being a PM First
I’ve noticed a couple of things that have been advantageous about being a PM first:
Vision Beyond a Feature
As a developer, it’s easy to get laser-focused on a feature, and not have any direction on who it will be used by, or the why behind it.
With my previous experience, I feel I can maintain the higher-order vision of an issue and assist others in keeping them in mind during development.
The more developers are in tune with the vision of the product, the less tech debt will be incurred while maintaining high morale as there will be less chance of needing to rework features.
Communication Across the Board
Conversations with engineers are often joked about and sometimes the best engineers don’t want to speak up in large groups. I’ve found it helpful to have solid communication up the chain to explain the lower-level work that we do.
Even if I’m not the most technically gifted, I can explain the work that we are doing in a way that makes sense to everyone without getting too bogged down in the details. This has been key in a few instances where PMs were trying to decipher what had been implemented but other people were out.
Insight into a PM’s Frame of Mind
Sometimes both sides (PM vs. Development) are convinced the other isn’t doing anything when each practice knows the truth.
The PM might be convinced developers aren’t working on a problem because product didn’t see a new update break the development environment which required an immediate remedy.
Dev might think the PM isn’t doing anything because they’ve been unavailable when product is actually stuck in meetings advocating for the team.
Having an understanding of both sides has allowed me to bridge the gap, and act as an intermediary between the two by speaking on experience.
This practice breeds empathy and appreciation in our team helping each member feel that their work is valued.
Now, not everything has transitioned so nicely, but that’s a topic for another article.
Conclusion
This series will follow my foray into the development landscape and act as a place where I can look at my position change as an opportunity to create new goals for myself.
A few ideas for goals that I have:
- What does it take to gain trust as a developer
- How can I become a better teacher to my peers to upskill the entire team
- Try to become more than just a developer and learn what it takes to be a tech lead
I am eager to share my experiences and the lessons I have learned from both my failures and successes.
Following the mantra: DON’T BE AFRAID TO FAIL
If you want to become a Medium member and read from amazing writers, you can use this link: Become a member!
…Until Next time =)
