The Project Operator

90% of Engineers believe these 3 things about Project Leadership - and they're wrong.

1,030 words

When I started my career in engineering, I assumed project management was just a more advanced form of what I was already doing. You know the drill: get the design right, build a solid plan, then execute it with discipline. Logical enough, right?

But when I transitioned into actual project leadership — leading teams, dealing stakeholders that change their priorities like other people change underwear, navigating real-world impossibilities — I ran head-first into a different reality.

And I’m not alone.

The more I’ve worked with engineers who are stepping into Project Leadership roles, the more I see the same patterns play out. Most of them hold on to the same three beliefs I did—beliefs that are not only wrong, but actively holding them back from becoming the kind of great project leaders they could be.

So let’s unpack those.

Myth #1: "If the plan is solid, the project will be fine."

Engineers are trained to value precision. We’re used to working in systems where control, logic, and detail produce the right outcomes. So naturally, when we move into project leadership, we think: “All I need is a better plan.”

We build elaborate schedules, define every task, align every dependency. And we feel confident—sometimes even sooo very smug—about how great the plan is. On paper.

Plan. Meet Reality. You're going to hate each other.

Because the moment something changes—weather delays, a contractor goes silent, a stakeholder changes their mind — that sense of control vanishes. The entire plan starts to wobble.

And that’s when it hits: the plan was never the point.

The value of a plan is in the conversations it forces. The gunshot that starts the race. But the route itself is always a guess. You’re not rewarded for having the best plan — you’re rewarded for how well you adapt when the plan stops working.

Project leadership means staying steady in the mess. It’s not about preventing all risk; it’s about managing through it when it inevitably shows up.

Myth #2: "If I do good work, people will see me as a leader."

This one’s personal. I spent the first few years of my career quietly grinding away—head down, solving problems, trying to be the most reliable engineer on the team. I figured if I was good enough, if my work spoke for itself, then leadership opportunities would follow. Someone would "hand me" opportunities.

And to be fair, I did get some, to a point. I got invited to more meetings, was given more autonomy. But I also noticed something strange: other people, with less technical experience, were getting tapped to lead bigger projects.

That’s when I started to realize: being technically strong isn’t the same as being trusted to lead.

Project leadership isn’t about being the smartest person in the room—it’s about helping the room work smarter. It’s about discovering risks early, managing conflicting priorities, and giving clear direction when no one else wants to step up.

You still need to understand the work, but again, to a point. Your value skyrockets, when you move your focus from doing the work yourself to enabling others to do theirs better. And unless you make that shift, you’ll keep getting passed over for leadership roles, no matter how good your work is.

Myth #3: "The key to successful projects is removing uncertainty."

This one sounds right—at least at first.

Engineers are uncomfortable with ambiguity. We’re taught to get rid of it. Define objectives, make clear assumptions, refine the scope using standards until there’s no confusion left.

So when we manage projects, we apply the same mindset. We spend endless time writing detailed charters, building granular WBS structures, and defining RACI matrices so that everyone knows exactly who’s responsible for what.

And sometimes, that helps. Sometimes. But more often than not, it gives us a false sense of control.

The truth is, uncertainty is part of the job. Projects are inherently uncertain, they live in the future. We can't predict the future. Not yet anyway. Facts only exist in the past, no uncertainty in yesterday, but you can't do a project yesterday.

Stakeholders say one thing and mean another. Team members nod in meetings, then go off in a different direction. A supplier responds to your email confirming they're on it, and then 2 weeks later send you a delivery schedule for 3 out of the 40 urgent items you asked for.

If your instinct is to keep tightening the structure every time that happens, you’re fighting the wrong battle.

Real project leadership isn’t about eliminating ambiguity. It’s about navigating it. It’s about creating enough psychological safety that people feel comfortable saying what they’re unsure about. It’s about clarifying expectations in conversation—not just in documentation.

If you can build trust and comfort in uncertain moments, you’ll deliver better outcomes than any schedule ever could.

What to believe instead

Looking back, I wish someone had said this to me in my first year as a PM:

1. You don’t succeed because you had the cleanest plan. You succeed because you know how to adapt.
2. You don’t become a leader by doing the most work. You become a leader by helping people do the right work—together.
3. And you don’t win by eliminating ambiguity. You win by leading through it.

That’s the mindset shift. That’s what turns a technically capable Engineer into a trusted Project Leader. And it’s what will accelerate your career faster than any certification or new PM tool ever could.

Andy Barbirato ​Find me on LinkedIn​