Where Expertise Ends and Leadership Begins
A great many project managers were specialists first, and they bring a real advantage: they can read a technical argument, spot an optimistic estimate and tell when an answer does not smell right. The same background carries a specific trap, and it is not arrogance. It is helpfulness. The quickest way to stop a capable team from thinking is to be the person who always supplies the answer, kindly, about four minutes before anybody else would have got there.
Section 2.4.5 of The Standard for Project Management lists applying expertise among the functions a project needs, alongside the others it describes. Both the expertise and the leading are functions, and the skill is knowing which one the moment calls for.
Two functions, both needed
Applying expertise means contributing what you know so the work is better. On a project that is short of a particular skill, a project manager who has it should use it, and pretending otherwise is a pose.
Leading means creating the conditions in which other people's expertise is used. Those two can conflict directly, because the same hour spent supplying your own answer is an hour in which somebody else's was not produced. Where the project manager is the only one who can answer, that is a resourcing problem wearing a leadership costume.
Where a project manager's expertise helps most
Asking the question that reveals the gap. Knowing the subject lets you ask what happens when the file arrives out of order, or whether that has been tested against the legacy identifiers. The team then answers, and the answer is theirs. This is by a distance the highest-value use of a project manager's technical knowledge.
Recognising a wrong answer early. Not correcting it in the room, but knowing to slow down: asking for the reasoning, asking who else has looked at it, asking what would show it was wrong. Expertise here buys time and attention rather than a conclusion.
Translating outward. Explaining to a sponsor, a regulator or an operations director why a technical constraint matters, in terms that carry. Specialists are frequently poor at this and it is genuinely difficult, and a project manager who can do it protects the team from a class of unreasonable demand.
The best engineer in the room
A SaaS company ran customer implementations with small teams, and one implementation manager had been a lead engineer on the product before moving into delivery. He knew the integration layer better than anybody on his team, which was an asset, and he used it continuously.
The pattern was consistent. A design question would come up, the team would begin working through it, and within a few minutes he would set out the answer, which was almost always right. Nobody objected; it saved time and his answers were good.
The effect showed up on the wall. The team's design thinking lived on handwritten cards pinned in columns, and on one column a single printed sheet had been pinned flat over the cards beneath it, square-edged against the curling handwritten ones around it. He had written it up over a weekend, and it had been pinned over what the team had produced.
Two things followed. The team stopped working design questions through, because the answer was coming anyway, which slowed them whenever he was unavailable. And when the integration hit an edge case he had not anticipated, involving a customer's unusual identifier format, nobody in the team had enough ownership of the design to see it early.
What he changed was mechanical and hard for him: he stopped answering in the first twenty minutes of any design discussion, and asked questions instead. The quality of the designs dipped for about three weeks and then exceeded where it had been, because five people were thinking instead of one. The edge cases that surfaced in the following quarter were found by analysts, which is where they should be found.
Knowing when to hold it back
Withhold when the team can get there. If the answer will arrive within the time available, from people who will own it afterwards, the project manager's version is not worth what it costs. The exception is genuine urgency, and urgency is rarer than it feels.
Say which hat you are wearing. When you do contribute as a specialist, name it: this is my view as somebody who worked on that layer, and it is one input. That single sentence stops your opinion carrying the weight of an instruction, which it otherwise does whether or not you intend it.
For a PMP® candidate, the thing to carry is that expertise and leading are separate functions, so a scenario where a technically strong project manager has a quiet team is describing an imbalance between them. A response that has the project manager resolve the technical question keeps the team where it is. A structured PMP exam preparation course works on situations where the project manager knows the answer and should not give it.
Watch one of your own meetings with a single question in mind: how many of the technical answers came from you? If it is most of them, try a fortnight of asking rather than answering and see what the team produces. The first week is uncomfortable and the second is informative.
Interested in going further?
Technical strength is an advantage in delivery and it quietly becomes a ceiling on the team when it is used as the primary tool. Omega's PMP® Exam Preparation works through the judgement about when to contribute and when to convene.
Applying expertise is one of the project functions described in The Standard, published with the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A007: The Standard for Project Management vs the PMBOK Guide
A039: Servant Leadership in PMP: When It Fits and When It Doesn’t
A038: Accountable Leadership: Leading Without Command and Control
A024: Facilitation as a Core Project Management Skill
A149: Coaching vs Directing: Choosing the Right Leadership Response
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
