In May 2026, I started a new role as Senior Principal Product Manager at Red Hat, focused on AI and the company’s Digital Workforce initiative. On paper, it’s a PM role. In practice, it’s a homecoming - and a culture shock at the same time.

I spent the last 6+ years leading engineering teams. Before that, I was a PM. Now I’m back, and the job I returned to is not the job I left.

This post is the story of those first 30 days - what transferred from my engineering leadership years, what didn’t, and why I think the gap between PM and engineering leadership is both narrower and wider than people assume.

Why I went back

I want to be clear: I loved engineering leadership. Mentoring engineers, watching people grow into roles they didn’t think they were ready for, building teams that shipped great products - that was some of the most rewarding work of my career. I’d do it again, and honestly, I might go back to management someday.

But as you climb the leadership ladder, the work naturally shifts. More of your time goes to people, process, and organizational design - and less to the technology itself. That’s not a complaint, it’s just the nature of the role. Over time, though, I noticed I was spending most of my energy on staffing plans, reorgs, and cross-team alignment, and less and less on the technical problems that drew me to this industry in the first place.

I missed being close to the technology. Forming opinions about architecture, understanding trade-offs at the system level, being in the room where technical direction gets set - not as the person approving headcount, but as someone with a point of view on the product itself. At the same time, I found myself drawn more to the what and why than the how. PM lets you stay technical while owning the direction - that combination appealed to me.

When the opportunity came to own an AI product portfolio - a domain I was genuinely curious about, at a company I already knew deeply - it felt like the right move at the right time.

What transferred

1. Technical credibility buys you time.

Walking into a new PM role with a strong engineering leadership background gives you a head start that’s hard to overstate. Engineers trust you faster. Architecture conversations are productive from day one. You don’t need someone to translate the trade-offs for you.

This matters more than I expected. In AI specifically, the gap between understanding the technology and not understanding it is the difference between asking good questions and nodding along. PMs who can engage meaningfully in architecture conversations and evaluate technical trade-offs on their own - they earn a seat at the table faster.

2. Organizational intuition is portable.

After years of navigating engineering orgs - managing managers, working across teams, handling reorgs, building consensus in open source communities - I came in with a feel for how large organizations actually work. Who to talk to. When to escalate. How to read the room in a meeting where nobody is saying what they really think.

This is the stuff that doesn’t show up on a resume but determines whether your first month is productive or just busy. Working in open source communities, where you have no authority by definition, turns out to be pretty good practice for this.

3. Empathy for the engineering side of the house.

I know what it’s like to receive a vague RFE that could mean five different things. I know what it’s like to be mid-sprint when priorities shift. I know what it’s like when a PM doesn’t understand the cost of what they’re asking for.

So I try not to be that PM. Every feature request I write includes the why, the user problem, and an honest assessment of complexity as I understand it. When I don’t know the cost, I say so and ask. When the engineering team pushes back, I listen - because I’ve been on their side of that conversation.

What didn’t transfer

1. Domain knowledge resets to zero.

Technical credibility gets you in the room. Domain knowledge keeps you there. And in a new domain - AI enterprise products, sales tooling, LLM-powered agents - I was starting from scratch.

The first few weeks were humbling. I was in meetings where every acronym was new. I was reading internal docs where the context assumed two years of history I didn’t have. I was forming opinions about product direction while still figuring out what the product actually did.

The temptation is to fake it - to nod along and figure it out later. I decided early on to just be honest about what I didn’t know. “I’m new, help me understand why we made that decision” turned out to be one of the most useful phrases in my vocabulary. People are surprisingly generous with context when you ask directly.

2. The tempo is different.

Engineering leadership operates on a cadence: sprints, releases, quarterly planning. You know what’s coming and when. The feedback loops are relatively tight - you ship something, you see if it works, you iterate.

Product management - especially at the strategic level - operates on a different cadence. Some things move slower: you’re writing RFEs that might ship in six months, planting seeds for initiatives that won’t materialize for a quarter. The feedback loops are longer and noisier. I found myself itching to do things - to ship, to fix, to make progress that I could measure.

But other things move incredibly fast. The AI space doesn’t wait for your quarterly planning cycle. Models improve weekly, competitive dynamics shift overnight, and the product you’re defining today might need to be rethought next month based on new capabilities that didn’t exist when you started. It’s a strange combination - strategic patience and tactical urgency at the same time. Learning to hold both took deliberate adjustment.

3. The information firehose is real.

In engineering leadership, the scope is relatively bounded - your teams, your area, your stakeholders. Even as a Director, where you’re too far from the code to go truly deep, you at least know the boundaries of what you need to track.

In PM - especially a cross-functional role that touches multiple business functions - the information surface is enormous. Slack channels, customer feedback, competitive intel, market research, internal strategy docs, stakeholder updates, field reports. I attended 30+ meetings in my first three weeks.

The risk isn’t missing information - it’s drowning in it. I spent my first month absorbing much more than I synthesized. That’s natural for a ramp-up period, but it’s a pattern you have to actively break. The value of a PM isn’t in how much they know - it’s in what they do with what they know.

What surprised me

PM changed while I was away. The biggest surprise wasn’t the domain shift - it was how much the craft of product management had evolved. AI is now a first-class tool in the PM toolkit, not a curiosity. The best PMs I see aren’t just using AI to write faster emails - they’re building systems around it, using it for research synthesis, competitive analysis, and stakeholder preparation at a depth that would have been impossible three years ago.

But here’s the flip side: building things has never been easier, and that makes the PM’s core job - truly understanding the problem, scoping the right solution, knowing what not to build - more critical than ever. When the cost of building drops toward zero, the cost of building the wrong thing becomes the dominant risk. The PMs who will thrive aren’t the ones who ship the fastest. They’re the ones who make sure the team is pointed at the right problem before anyone writes a line of code.

I leaned into both sides of this. Within my first month, I built an AI-augmented workflow that goes beyond just reducing operational overhead. It’s about being AI-first across the entire PM lifecycle - from research and discovery, through competitive analysis and stakeholder prep, to feature definition and delivery tracking. The goal isn’t to automate the PM role. It’s to leverage AI at every stage so I can go deeper on the parts that actually require human judgment: understanding the problem, talking to customers, making trade-off decisions, setting direction.

The outsider advantage is real. Coming from outside the AI domain, I ask questions that insiders stopped asking a long time ago. “Why do we do it this way?” is a powerful question when asked sincerely by someone who genuinely doesn’t know the historical context. Sometimes the answer is a good reason. Sometimes the answer is “that’s just how we’ve always done it.” The second answer is where the opportunities live.

The challenge is holding onto that fresh perspective as you ramp up. The more you learn, the more you risk normalizing the same things everyone else has normalized. I’m trying to be deliberate about preserving that outsider’s critical eye - questioning assumptions, challenging defaults, not accepting “that’s just how it works here” too quickly. That fresh point of view is a temporary asset, and once it’s gone, it’s hard to get back.

Relationships compound faster than knowledge. The most valuable thing I did in my first 30 days wasn’t reading docs or writing specs. It was meeting people. Every 1:1, every “help me understand your world” conversation added a layer of context and trust that keeps paying off weeks later. Knowledge is perishable - especially in a fast-moving AI domain. Relationships are durable.

The honest version

Returning to PM after years of engineering leadership is not a lateral move. It’s a diagonal one - you carry some things across, you leave others behind, and you have to build new muscles in real time while delivering in a role that expects you to already have them.

There were days in that first month where I felt completely lost.

And then there were days where everything clicked - where my engineering background gave me an insight that a pure PM would have missed, where a relationship from my open source years opened a door in my new domain, where the outsider perspective helped me see a problem that insiders had normalized.

The answer, 30 days in, is that the transition is worth it - but only if you’re honest about what you don’t know, deliberate about what you need to learn, and patient enough to let the compound interest of relationships and domain knowledge do its work.

What I’d tell someone considering the same move

  • Your technical depth is an asset, not a crutch. Use it to earn credibility, but don’t let it become your identity. You’re a PM now. The job is to define what to build and why, not to prove you could build it yourself.
  • Be honest about what you don’t know. The fastest way to earn trust in a new domain is to ask good questions, not to pretend you have answers.
  • Invest in relationships early. You obviously need to read the docs too, but don’t let that crowd out meeting people. Knowledge decays. Relationships compound.
  • Go AI-first from day one. Don’t wait until you’re “settled in” to rethink your workflow. I started building my AI-augmented PM system during my first week, and it’s one of the best decisions I made. It’s not just about saving time - it’s been a force multiplier for onboarding itself, helping me absorb context, track stakeholders, and synthesize information faster than I could have done manually. That investment is already paying dividends.
  • Give yourself grace. The first 30 days are supposed to be uncomfortable. If they’re not, you’re probably not stretching enough.