👋 Hey, it’s Stephane. I share lessons, and stories from my journey to help you lead with confidence as an Engineering Manager. To accelerate your growth see: 50 Notion Templates | The EM’s Field Guide | CodeCrafters | Get Hired as an EM | 1:1 Coaching
Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.
There’s a conversation happening in performance reviews right now that should concern every engineering leader.
It goes something like this: “Your technical work is outstanding. You consistently deliver. But you’re not seen as leadership material because you ask instead of tell, you say ‘I think’ instead of stating things definitively, and you’re not pushing back enough when it’s needed.”
If you’re nodding along because you’ve delivered this feedback - or received it - we need to talk about what’s actually being evaluated here.
“Leadership presence”
When we tell a senior engineer they need to be more “authoritative” or “assertive” to reach staff level, we’re making an implicit claim: that the behaviours we associate with confidence are the same as the behaviours that produce results.
They’re not.
I’ve worked with staff engineers who project absolute certainty in every meeting. Some of them are excellent. Others have left a trail of architectural decisions that teams are still unwinding years later, made by someone too “assertive” to hear dissenting views.
I’ve also worked with engineers who phrase everything as questions, who say “I think” even when they’re certain, who change their approach based on PR feedback. Some of them are the most effective technical leaders I’ve encountered - people whose influence extends far beyond their formal authority because others actually want to follow their guidance.
The difference isn’t assertiveness. It’s whether the person can actually move a team toward better outcomes.
What we’re really measuring
When we evaluate someone’s “leadership presence”, we’re often measuring conformity to a cultural norm rather than effectiveness.
The engineer who states opinions as facts in meetings isn’t necessarily more confident than the one who frames suggestions as questions. They might just be more comfortable with a particular communication style - one that happens to be rewarded in many engineering cultures.
Consider what we’re actually looking for in a staff engineer:
Can they identify the right technical direction when facing ambiguity?
Can they get buy-in from stakeholders who don’t report to them?
Can they unblock teams and resolve conflicts?
Do more junior engineers grow faster when working with them?
Are their projects delivered in a timely fashion?
None of these require a particular personality type. A soft-spoken engineer who asks probing questions can absolutely set technical direction - they just do it differently than someone who opens with “here’s what we’re doing”.
In fact, there’s reasonable evidence that the question-asking approach often works better. When you tell people what to do, you get compliance. When you help them arrive at the conclusion themselves, you get commitment.
The double bind you might be creating
If you’re managing someone who doesn’t fit the “assertive leader” mould, you need to be honest with yourself about something.
Have you actually given them the opportunity to lead? Or have you watched them defer to louder voices in meetings and concluded they can’t lead, without ever explicitly putting them in the driver’s seat?
There’s a significant difference between “this person lacks leadership capability” and “this person hasn’t been given leadership authority”. Many engineers who appear passive in group settings are perfectly capable of driving decisions when it’s clear that’s their role. They’re just not going to elbow their way into that position.
If your feedback is “you need to be more assertive”, but you haven’t actually assigned them ownership of anything, you’ve created an impossible situation. You’re asking them to claim authority you haven’t granted, which is likely to backfire.
If you’re enjoying this article, consider subscribing to get:
✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers
🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide
What effective leadership development actually looks like
If you have a technically excellent engineer who doesn’t naturally project “authority”, here’s an approach that actually works:
Make the authority explicit. Don’t wait for them to assert themselves. Put them in charge of something and make it clear to everyone involved. “Alex is leading the API redesign. Decisions on scope and approach go through them”. Now they don’t need to claim authority - they have it.
Distinguish communication style from communication effectiveness. “I think we should use approach X because of Y and Z” contains exactly the same information as “We’re using approach X because of Y and Z”. If stakeholders are responding poorly to the first formulation, that’s worth addressing. But focus on whether the message is landing, not whether it sounds sufficiently commanding.
Watch for actual influence, not performed confidence. Does the team end up following this person’s technical recommendations? Do other engineers seek them out for guidance? Do cross-functional partners come back to them for the next project? These are better signals than how declarative their sentences are.
Coach on strategic communication, not personality change. There’s a real skill in knowing when to ask questions (early in a design process) versus when to give direction (when the team is stuck and needs someone to break the deadlock). That’s teachable. “Be more dominant” is not.
The question you should be asking yourself
Before you deliver feedback about someone’s leadership presence, try this exercise:
Imagine they left tomorrow and went to a company that valued their particular style. Would that company get a great staff engineer? Would they look at your organisation and wonder how you failed to recognise what you had?
If the answer is yes, the problem might not be with the engineer.
I’ve seen too many technically brilliant people leave organisations because they were told they weren’t “leadership material” - only to thrive as technical leaders elsewhere. Usually, the only thing that changed was the environment.
The staff engineer role exists to multiply the effectiveness of other engineers. There are many ways to do that. If your organisation only recognises one of them, you’re not selecting for the best leaders. You’re selecting for the best performers of a particular leadership style.
That’s a choice you’re making. Make sure it’s a deliberate one.
If you enjoy articles like these, you might also like some of my most popular posts:
See you in the next one,
~ Stephane