Managing technical projects without being the technical expert.
It’s a question that comes up often, particularly for Project Managers working in technology, engineering, software, or product development.
Do you need an engineering background?
Do you need to understand the architecture?
Should you be able to challenge the technical solution?
My answer is probably simpler than expected:
You need to understand the technology well enough to manage the project. You do not need to understand it well enough to build it.
And there is an important difference between the two.
I Am an Engineer, But I Don’t Try to Be the Engineer in the Room
My background is in electrical engineering, and I spent many years working in technical environments before and after moving into Project Management.
That background certainly helps me.
I can follow technical discussions. I understand how engineering teams work. I can usually recognize dependencies and understand why something that sounds simple may not actually be simple.
But today, when I manage a technical project, I deliberately stay out of the detailed technical decisions.
Why?
Because that is not my role.
The engineers and technical specialists own the solution. My responsibility is to understand what that solution means for the project.
What needs to happen?
Who needs to be involved?
What depends on what?
How long will it take?
What could prevent us from delivering?
Has something changed that affects scope, schedule, cost, quality, or risk?
Those are the questions I need answered.
I don’t need to design the solution myself.
Technical Knowledge and Technical Ownership Are Different Things
This distinction becomes especially important for Technical Project Managers.
The word technical can sometimes create the expectation that the PM should be deeply involved in engineering decisions.
That can actually become a problem.
A PM with a strong technical background may be tempted to jump into solution discussions, propose designs, troubleshoot problems, or challenge engineers on implementation details.
I understand that temptation. When you know the subject, it can be difficult to stay out of it.
But every hour I spend trying to be another engineer is an hour I am not spending managing the project.
The PM should make sure the technical decision gets made, by the right people, at the right time, with the right information.
That doesn’t necessarily mean the PM should make it.
What About a Project Manager Without a Technical Background?
This is where I think we sometimes go too far in the opposite direction.
You don’t need to be an engineer to manage engineers.
You don’t need to be a developer to manage a software project.
You don’t need to understand every component, protocol, line of code, or design decision.
But “I’m not technical” cannot become permission to understand nothing.
If someone tells me a feature that was expected next month will now take another six weeks, I don’t necessarily need to understand how that feature is being implemented.
But I absolutely need to understand why the estimate changed.
What was discovered?
Was an assumption wrong?
Is there a dependency we didn’t know about?
Are additional resources required?
Are there alternatives?
What else is affected?
Does this change the critical path?
Does somebody need to make a decision?
That is Project Management.
The PM’s Job Is to Translate Technical Reality Into Project Reality
Technical teams naturally think about the solution.
Project Managers have to think about what the solution means for the project.
A technical decision may create a schedule dependency. An architecture change may introduce a new risk. A component issue may affect procurement. A firmware change may require additional testing. A design decision may affect another team that wasn’t originally involved.
The PM doesn’t need to solve each of those technical problems. The PM needs to recognize that they exist, connect the right people, understand the impact, and make sure they don’t disappear between teams.
That’s where technical understanding becomes valuable. Not because it allows you to do someone else’s job, but because it allows you to manage your own job better.
Ask Until You Understand Enough
One of the most useful skills a PM can develop is being comfortable saying:
“Explain that to me at the level I need to understand its impact on the project.”
There’s nothing wrong with asking technical people to simplify something. I would rather ask another question than leave a meeting pretending I understood something that could later affect the project.
You don’t need to leave the conversation knowing how to build the solution. You should leave knowing what it means for your project.
That’s the difference.
So, Technical PM or Project Manager?
Titles vary enormously between companies. In one organization, a Technical Project Manager may be expected to have significant engineering knowledge. In another, the title simply means the PM manages highly technical projects.
The title matters less to me than the boundary.
A strong PM understands enough to ask good questions, identify dependencies, recognize risk, challenge assumptions, and translate technical information into project impact.
A strong PM also knows when to stop.
You don’t need to understand the technology well enough to build it. You need to understand it well enough to manage what it takes to build it.
And sometimes, knowing what not to own is just as important as knowing what you do.
Rosana Inacio | PM Insight
Leave a Reply