When I started my career as a software engineer, I was deep in the code—debugging, optimizing, and shipping features. I loved solving problems, but over time, I found myself more curious about why we were building things, who we were building them for, and how our decisions impacted the bigger picture.
That curiosity ultimately led me to project and product management—a pivot that challenged me to shift from solving technical problems to solving people and process problems.
This post is about what I’ve learned in that transition, what I had to unlearn, and why I believe former engineers make uniquely effective PMs (when they’re willing to grow).
1. Why I Made the Jump
For a while, I was the engineer who always wanted to be in the sprint planning meeting and the customer call. I enjoyed building, but I was more energized by connecting the dots between user needs, technical feasibility, and business goals.
After several conversations with mentors and stakeholders, it became clear: I was ready for a more people-facing role that required strategic thinking and coordination across disciplines. I took the leap into project and product management—and haven’t looked back.
2. What Carried Over (and Gave Me an Edge)
- Systems Thinking: As an engineer, I had a natural inclination to see how parts connected—whether that’s backend infrastructure or cross-functional workflows.
- Technical Empathy: I don’t micromanage devs, but I do understand what they’re up against. I can ask the right questions, challenge assumptions with respect, and shield them from unnecessary thrash.
- Detail Orientation: Years of debugging taught me to sweat the small stuff. That same mindset helps me manage scope, timelines, and dependencies precisely.
This foundation made me a trusted bridge between engineering and stakeholders—someone who could translate in both directions.
3. What I Had to Unlearn
- Being the Expert: As a PM, it’s not my job to have all the answers. I had to get comfortable saying “I don’t know” and instead focus on facilitating the answers.
- Binary Thinking: Engineering taught me precision. But product work lives in ambiguity. Stakeholders want trade-offs, not yes/no answers. I had to lean into nuance.
- Solo Wins: In engineering, individual contribution is easier to measure. As a PM, success is collective and often invisible. I had to find pride in enabling others to succeed.
4. Lessons That Made Me a Better PM
- Speak Everyone’s Language: Whether talking to devs, designers, or execs, I’ve learned to adapt my language. Code-level precision doesn’t work in a strategy deck, and business jargon won’t win over your engineers.
- Make Priorities Ruthlessly Clear: Engineers want focus. Stakeholders want outcomes. It’s my job to find the overlap—and protect it.
- Never Underestimate Follow-Through: The best strategy is worthless without execution. I’ve made it my mission to ensure that ideas move forward with clarity, ownership, and momentum.
5. The Bridge Role is the Most Human One
Being a PM isn’t just managing timelines or translating specs. It’s about building trust, clearing blockers, and creating space for others to do their best work. It’s where logic meets empathy—two qualities I’ve come to value equally.
PM Perspective 
Leave a comment