Why This Post Exists

A large part of my role involves mentoring senior technologists in staff and senior staff roles. During my conversations with them, I have been asked what is the best way to increase influence. There is a transition point in every engineer’s career where the thing that got you here stops being the thing that gets you further. You’ve built the technical depth. You can ramp up on new systems, debug production incidents, and design architectures that hold. And then you walk into a room full of Sr. Managers, Directors and C-suite executives and you don’t speak up — even when you know the answer.

This is not a confidence problem. It is a model problem. The mental model most senior engineers carry about how influence works, how mentorship works, and what “growth” looks like is incomplete. And that incomplete model creates real friction: missed opportunities to shape decisions, stalled relationships with stakeholders, and the quiet frustration of knowing you belong in the room but not feeling like you can operate in it.

This post is about replacing that model. It draws from real mentorship conversations and hard-won patterns about what actually works when you are trying to grow from a strong individual technologist into a trusted leader — where impact is measured less by what you build and more by what you enable others to build. While you have been set up with a support system to increase your influence like mentors, operating across different roles in the organization, you have not been told on how to effectively leverage this system.

The Misconception: Mentorship Is a One-Person Relationship

The default mental model for mentorship looks like this: find a senior person, meet regularly, ask questions, get advice. One mentor, one mentee, one relationship.

This is not mentorship. It is a dependency.

The real shift is understanding that effective mentorship is a village, not a single relationship. You don’t need one person who can answer every question. You need a network of people across distinct job families, each contributing a different capability to your growth.

Here is what that village actually looks like:

A peer might be teaching you something they do better than you — maybe operational rigor, maybe system design intuition. A Technical Program Manager (TPM) might be showing you how they manage stakeholders across a large footprint, because TPMs are extraordinarily good at influencing without authority. An engineering manager (SDM) might be demonstrating how they delegate and execute — they are, in many ways, execution machines, and there are patterns worth studying in how they break down and distribute work leading through others. A product manager might be helping you understand how they define problems and prioritize, which changes how you frame technical decisions.

None of these relationships need to be formal. They don’t need standing agendas or structured formats. What they need is intentionality — you know what you are trying to learn from each person and why that specific job family has something to teach you that your own does not.

Mental model: Mentorship is not a ladder you climb with one guide. It is an umbrella you build from diverse relationships, each covering a different gap. The individuals who have an accelerated growth are the ones who build the widest umbrella, not the ones who find the single “best” mentor.

The Cap You Hit: When Technical Strength Stops Being the Bottleneck

Here is something most senior technologists don’t want to hear: you are starting to reach the cap of what technical strength alone can do for you.

This is not a criticism. It is a structural observation. At the senior level, you’ve proven you can solve hard problems, ramp up on new domains, learn and be curious, and deliver technically sound work. Those are table stakes. They got you where you are today, and they will always matter. But they are no longer the differentiator.

The next phase of growth lives under what I call the people umbrella. It includes influence without authority, stakeholder management, building trust across organizational boundaries, and the soft skills that most engineers dismiss as “not real work” until they realize those skills are exactly what separates a strong staff from a sr. staff or a sr. staff from a principal.

This matters because the problems you are asked to solve now are not harder technically — they are harder organizationally. They span multiple teams, multiple managers, multiple priorities. The technical solution is often the easy part. Getting six teams to align on it, getting a skeptical SDM to allocate resources, getting a product leader to prioritize your use case — that is the actual work. And none of it responds to technical depth alone.

Speaking Up: Why Qualifiers Are More Powerful Than Confidence

Let’s talk about a specific symptom of this transition: the hesitation to speak up in rooms with senior people you don’t know well.

The naive model says this is a confidence problem, and the solution is to “just be more confident.” That advice is useless. It is like telling someone who is lost to “just know where you are.”

The real issue is risk perception. When you are in a room with people whose work style you don’t know, whose expectations you can’t predict, and whose opinion of you matters for your career, speaking up feels like an unhedged bet. What if I’m wrong? What if I leave the wrong impression? What if these people decide I don’t know what I’m talking about?

The tool that actually works here is the qualifier. A qualifier is a framing statement that reduces the perceived risk of contributing, both for you and for the room. It sounds like this:

“I don’t think I’m an expert at this, but with the experience I’ve had on this side, I believe it should be done this way.”

Or: “I have a strong opinion here based on the post mortem my team has written, but I’d love to pressure-test it.”

Or even: “This might be a dumb question, but what would happen if we did X?”

The qualification removes the hesitation because it explicitly scopes your claim. You are not asserting authority you don’t feel you have. You are contributing a perspective while acknowledging its boundaries. And here is the counterintuitive part: qualifiers don’t make you look weaker. In rooms filled with executives, they make you look more credible, because they signal that you understand the limits of your own knowledge — which is exactly the kind of judgment those rooms value.

This is not about false modesty. It is about giving yourself a framework to contribute when the alternative is silence. Silence in a room where you have the answer is not humility. It is a missed opportunity to build the reputation that earns you influence later.

Influence Without Authority: The Actual Mechanics

Influence without authority is the phrase everyone uses and almost nobody teaches concretely. So let me be concrete.

Start From Customer Problems, Not Technology

When you are trying to influence a team you don’t manage, resist the instinct to lead with your technical solution. Lead with the customer problem.

This is not a platitude. It is a tactical choice. When you walk into a room and say “I need your team to integrate with my API,” you have framed the conversation as a resource request. The other team’s SDM is now doing mental math on capacity, priorities, and whether your request is worth disrupting their roadmap. You have made yourself an obstacle to their goals.

When you walk into the same room and say “We have a customer problem where X is happening, and I’d love to brainstorm how we might solve it together,” you have framed the conversation as a shared challenge. The technology will come naturally — it always does for engineers. But grounding on the customer problem first means you’re not asking for something. You’re inviting collaboration. And that reframe changes everything about how the conversation unfolds.

Listen Before You Solve

Here is a concrete example of what this looks like in practice. An SDM once rejected a proposal outright in a cross org group review with senior management. His team was underwater — they had launched a major product on a monolithic architecture, operational metrics were degrading, and they were in the middle of migrating to a new framework. The proposal to build on their old codebase felt like someone dumping more work on a sinking ship.

The instinct is to push harder, escalate, or find a workaround. What actually worked was a back-channel conversation: “Tell me more about the problem. What’s really going on?”

That conversation revealed the full picture — the scaling challenges, the operational mess, the migration timeline. And it opened up a different approach entirely: “What if I do the work on both the old and new systems? I’ll even activate some features on your new framework that give you a win too.”

The SDM went from blocking the work to actively supporting it. Not because the technical proposal changed — but because the relationship changed. He went from being a stakeholder who felt imposed upon to a collaborator who felt heard.

The pattern here is worth naming explicitly:

What most engineers do:
  → Present solution → Ask for support → Get blocked → Escalate

What actually works:
  → Ask about their problems → Listen → Find mutual wins → Earn support

Map the Stakeholders, Find the Decision Makers

Not everyone in a group of stakeholders has equal decision-making power. Everyone wants visibility, but only a few people will actually make the real decisions. Your job as a senior technologist is to identify who those people are.

Sometimes you’ll get lucky and connect with the decision maker directly. Sometimes you won’t. When direct influence fails, the move is lateral: find the trusted individual that the decision maker trusts. Can you build a relationship with their team’s senior technologist or trusted advisor? Can you offer to mentor someone on their team? Can you find a peer IC (individual contributor) in that organization and grab coffee?

This is not manipulation. It is how organizational influence actually works. As an IC, it is far easier to influence another IC than it is to influence a leader two levels above you. Peer-to-peer relationships are the natural channel for IC influence. Use them.

Adapt Your Communication Style

Here is a story that still stings. I once spent a month and a half failing to make progress with an senior leader in another organization. I brought well-structured documents. I brought clarity. I brought everything that had always worked before. Nothing landed.

It met with a senior engineer on his team who finally told me: “You’re doing it wrong. He doesn’t like docs. He likes open-ended conversations.”

I had been optimizing for the wrong communication medium. Every interaction was friction because I was forcing my preferred format onto someone whose brain worked differently. Once I switched to unstructured, conversational whiteboard sessions, everything unlocked.

Mental model: Influence without authority is not a single skill. It is a system of skills — reading stakeholders, adapting communication, finding mutual wins, building trust through peer relationships, and knowing when to push and when to listen. And like any system, it only works when the components are connected.

What This Means for Your Growth

If you are a senior technologist reading this and recognizing yourself — strong technically, hesitant in unfamiliar rooms, unclear on how influence actually works — here is how to think about your next phase of growth.

First, build your village. Identify gaps in your growth that a single mentor cannot fill. Find a TPM who can teach you stakeholder management. Find an SDM who can show you how they delegate. Find a peer who does something better than you and learn from them. The diversification of your mentorship network is not optional — it is structural to how you grow at this level.

Second, start using qualifiers. They are not a crutch. They are a tool that lets you contribute in rooms where silence is currently your default. Practice them until they feel natural, and notice how they change the dynamic of your participation.

Third, invest in the people’s umbrella. This is not soft, fluffy, nice-to-have work. It is the actual work of operating at the sr staff or principal position. The technical depth you’ve built is the foundation. The relationships, the influence patterns, the communication adaptability — that is the structure you build on top of it.

If there’s one takeaway, it’s this: growth from one to another level is not a deeper version of the same game. It is a different game entirely. The engineers who make that transition successfully are not the ones who get even better at technology. They are the ones who build a village, learn to influence without authority, and understand that the hardest system to design is the one made of people.