If You're a Project Manager, You're Not an Engineer Anymore.
Is that a bad thing?
I clearly remember when my job title changed from Engineer to Project Manager.
And how hard it was.
Six months into my new role, I was sitting in a stakeholder meeting. Someone was asking about the project timeline. I wasn’t listening to their question. I was mentally interrogating the technical spec in my head, wondering if anything had been missed.
I was still an engineer. I just had a new title.
Nobody told me the hardest part of becoming a Project Manager wouldn’t be the new responsibilities. It would be unlearning the habits that made me good at my old job.
If you’re an engineer moving into a PM role, or thinking about it, here’s what I wish someone had told me.
You Are Now a Communication Machine
Engineers solve problems quietly. You go heads-down, do the work, and come up for air when you have something to show. That approach works great when your job is to build things.
It will kill you as a PM.
Your job now is to make sure everyone knows what is happening at all times. Your team. Your stakeholders. Your manager. Not just when something goes wrong. Not just in the weekly sync.
I learned this the hard way across every channel. I thought my Slack updates were enough. They weren’t. I thought my standups covered the team. They didn’t. Silence creates a vacuum, and people fill that vacuum with their own assumptions. Those assumptions are almost never good.
The rule: if you think you’ve communicated enough, communicate once more.
In practice, this looks like:
A short Slack message at the end of the week, even when nothing major happened
A two-sentence stakeholder update that says “still on track, here’s what we did”
Saying the obvious thing out loud in a standup, because not everyone absorbed it the first time
It feels like overkill. It isn’t.
👋 No more Powerpoint(!)
Have you heard of the Amazon 6 Pager Memo? It’s what Jeff Bezos uses to keep his mega-company productive. But it works so well that I use it for project management. Thousands of others do too. If you want my personal Amazon 6 Pager Memo template you can find it here.
Do the Communication Style You Hate. For One Month.
Here is the tip that will make you uncomfortable.
Good.
Every engineer has a communication style they avoid. Maybe it’s presenting to a large group. Maybe it’s writing long documentation. Maybe it’s one-on-ones where you have to talk about feelings and not code. Whatever makes you cringe, that’s the one you need to do more.
I avoided all of them at different points. Presenting felt exposed. Writing felt slow. One-on-ones felt unstructured. But each time I forced myself to do the thing I hated, I found the specific gaps in my skills before they showed up as real problems on real projects.
The challenge is simple. Pick the style you hate most right now. Commit to 30 days. Not perfectly. Just consistently.
Sign up to run the next team demo
Write the documentation nobody asked you to write
Schedule the one-on-ones you’ve been putting off
Discomfort is just information. It’s telling you where to grow.
You Don’t Have Authority. Use It Anyway.
As an engineer, your power came from what you knew. Technical credibility. People listened because you understood the system.
As a PM, that’s gone. Or at least, it’s not enough anymore.
You are now responsible for outcomes you cannot control directly. You can’t force the design team to move faster. You can’t make an executive change their priority. You have to influence people who don’t report to you, using nothing but trust and relationships.
The way you build that is boring and slow:
Have one-on-ones before you need anything from anyone
Ask people about their work and actually listen
Give credit loudly and take blame quietly
Follow through on small things so people believe you when the big things come
Do this before you need a favor. When a deadline is on fire and you need someone to go above and beyond, the only thing that will matter is whether they trust you.
Get Comfortable Not Knowing the Answer
Engineers are trained to figure things out. There is a problem. There is a solution. You find it.
PM life is mostly ambiguous. Requirements change. Priorities shift. Sometimes the goal itself isn’t clear. And you still have to keep the team moving forward.
Stop waiting for certainty before you act. Make the best decision you can with the information you have, write down your assumptions, and stay open to updating your view. A decent decision made now beats a perfect decision made too late.
Trust your team here. Ask for their read on a problem before you give yours. You’ll be surprised how often they see things you missed, and how much faster things move when people feel ownership instead of just instructions.
Don’t Lose the Engineer in You
This one took me a long time to figure out.
I thought becoming a good PM meant leaving my engineering habits behind. The attention to detail felt like nitpicking. The methodical thinking felt like it slowed things down.
It doesn’t. It’s a superpower.
Most PMs wing it. They write vague specs, hold loosely planned meetings, and hope things work out. Your engineering brain won’t let you do that. You will:
Write specs that actually make sense
Ask the question in the meeting that everyone was thinking but nobody said
Catch the flaw in the plan before it becomes a problem in production
The key is knowing when to use it. Not every decision needs a full breakdown. But when it matters, and it will matter often, your detailed nature will be the thing that sets you apart.
You’re Still an Engineer
Six months in, sitting in that meeting, I thought I was failing. I was thinking about error states instead of listening to a stakeholder. I felt like a fraud.
But here’s the thing. That instinct to understand the system deeply, to think about what could go wrong, to care about the details, that’s exactly what the role needed. I just had to learn how to point it in the right direction.
The transition is hard. The identity shift is real. But you are not starting from zero. You are starting from a foundation that most PMs don’t have.
Use it.
This was a great article! I work with many engineers who struggle with the decision to move into leadership, and the biggest barrier is usually identity. They think becoming a good leader means abandoning what made them great engineers. It doesn't.
The Ready Set calls this Challenge Driven and Adaptive Thinking: leadership isn't about leaving your technical foundation behind, it's about redirecting those instincts (attention to detail, systems thinking, methodical problem-solving) toward influence, clarity, and developing others instead of just solving problems yourself.
The engineers who make the best leaders don't lose their engineering brain. They learn when to apply it and when to step back so their team can own the solution. That's the shift, and it's learnable.
Thank you for the detailed breakdown and advice, I feel so seen in this post! Two great quotes and takeaways that really stood out to me:
“Discomfort is just information. It’s telling you where to grow.”
“Engineers are trained to figure things out. There is a problem. There is a solution. You find it.”
I will definitely be returning to this article in the future, thanks again!