The Dev→PM→Dev Journey: Why I Went to Product and Came Back
The Arc
I've held almost every software IC role: developer, project manager, tech lead, architect, product manager and back to developer. There's full-stack and then there's full-process. In my journey I've learned how to directly instantiate, prioritize, implement and release software products. The variety of work has kept software interesting and fueled career growth for over 20 years.
One of my managers called me a "triple threat" when I was simultaneously functioning as developer, project manager, and architect. When I added product management and in that role, I often turned heads with my technical breadth and depth. In sales and discovery calls with engineers I have the ability to speak fluently and establish instant credibitiliy.
A senior architect colleague wrote that he'd "hire me in a second to fix any wayward project." A direct manager said I "quickly assess what's within my control and take decisive action."
These skills differentiate me from many of my peers.
The Setup
After 15+ years as an engineer at NI, I knew our products deeply. I'd worked on the hardware interfaces, the test frameworks, the platform services. I had just instantiated, implemented and released an internal effort to improve our testing infrastructure and wanted to lead the company to provide this value for our external customers. I already had the technical credibility and domain expertise and wanted to expand beyond execution into prioritization, product direction, and business acumen. When a product manager role opened up to drive an externally facing test data collection and analysis tool, I applied immediately.
What Product Taught Me
Product management gave me things I couldn't have learned staying in engineering:
Customer empathy at scale: I talked to dozens of customers. Not the "can you help me debug this" conversations, but "what are you actually trying to accomplish?" conversations. End users didn't want the architectural details to leak into their experience, they just need their problems solved as simply as possible. Purchasing managers wanted to know how much time and capital solutions could save. Different audiences need different messages.
Prioritization is a skill: Engineers optimize. Product managers triage. Learning to say "not now" to genuinely good ideas because something else matters more was essential and I've become quite good at delivering what matters in a timely manner.
The politics of roadmaps: Roadmaps aren't technical documents; they're statement of intent. They communicate priority, manage expectations, and align stakeholders. They can and should change as new information is acquired. Understanding this changed how I approach any cross-team work.
Discovery before delivery: I ran customer discovery processes, validated assumptions before committing to builds. This is now how I approach personal projects too.
Why I Came Back
And it worked. I learned to run customer discovery, build roadmaps that aligned competing stakeholders, and make the hard calls about what not to build. Those years made me a better builder, not just a better talker.
Then two things shifted. First, my company recast PM as primarily sales and marketing support—less product leadership, more pitch decks. That's a valid version of product management, but it doesn't speak to my strengths. I found myself unsupported in the parts of the job I was best at.
Second, and more importantly, decision-making for product behavior and direction started swinging back to R&D.
I read the room. My influence on product is now higher and more direct as an architect than it was as a PM in the reshaped role. I'm closer to the code and closer to the decisions.
If I stay at my current company, I'm targeting a newly created Product Architect role—part implementer, part tech lead, part product owner, part project planning. That hybrid is exactly what I want. It's also what Product Engineer roles at companies like PostHog and Linear look like.
How I Lead
Early in my career I hit a point where I had more ideas than hours in the day. So I started mentioning my ideas out loud to other devs on my team. One week, an engineer came to show me one of the ideas they had heard and felt inspired to implement. That was the moment I really felt the power of multiplying progress with the help of a team and that I could lead other engineers.
That realization launched my leadership journey. Through books, training, conferences and a lot of trial and error, I figured out what kind of leader I wanted to be: a servant leader. I work best within teams, not above them. Going to bat for engineers and unblocking them is always job one.
The book "Turn the Ship Around" and its concept of intent-based leadership is still foundational for me. I learned that sharing intent and direction is one of the best ways to unlock a team's potential. I guide through discussion, build understanding through collaboration, and trust people to make good calls when they have context.
This approach has always yielded better solutions. We go faster. We produce more value. And the team owns the outcome because they share in the decisions.
What This Means for You
If you're hiring:
I understand every role: I've been one. I know what they need, how they think, and how to collaborate without friction.
I can own features: From customer problem to shipped solution. I don't need someone to write tickets; I need context and trust.
I won't over-engineer: Product thinking cured me of building abstractions nobody asked for. I start with the problem, then the architecture. I create phased approaches and wait for need to drive design complexity.
I can context-switch: Engineering depth and product breadth. I can debug a gnarly race condition and then explain to stakeholders why we're prioritizing it.
I lead by unblocking: I make the people around me faster. That's how I measure my impact.
The Twenty-Year Elephant
Yes, I've been at one company for 20 years. Here's how I think about that:
Depth, not stagnation: I've had many jobs within one company. Different teams, different tech stacks, different roles. The continuity meant I saw the long-term consequences of decisions—something job-hoppers miss.
Why now?: Enterprise constraints have gotten heavier at the company post-acquisition. Process has accumulated and more decisions have become centralized which is counter to my distributed decision-making style.
What I'm looking for: Autonomy, ownership, and tools that help people get their jobs done more efficiently. Teams where shipping fast and learning from users is the culture, not a fight against the culture. I am looking for a way to utilize more of my differentiated strengths and continue learning and growing at work (not just in my personal projects).
The Summary
I've done every IC role. I went to PM deliberately to pick up business acumen and product leadership. When the role shifted away from my strengths and product influence moved back to R&D, I followed the leverage.
I want to own features end-to-end, from problem to shipped solution, with the product instincts I built and the technical depth I never lost. Whether that's called Product Engineer, Product Architect, or something else, it's the work I want to do.