Influence Without Authority and Managing Up

Past a certain level, your impact is not limited by what you can personally build. It is limited by what you can persuade, align, and enable across teams that have no obligation to follow your direction. This is the influence challenge — and it is one of the most significant shifts in operating mode from senior to staff.

Alongside it is the managing-up challenge: most engineers have a transactional relationship with their manager, treating it as a reporting structure rather than a strategic partnership. Both are worth doing better.

Why Authority Does Not Scale

Authority works in a hierarchy. You have authority over your direct reports, and they do over theirs. But most of the work that matters at senior level happens across this hierarchy: aligning with a team in a different org, convincing a platform team to prioritize your dependency, getting buy-in from a PM who does not report to your manager.

In these situations, you have no authority. What you have is expertise, relationships, and the quality of your arguments. The engineers who figure out how to be effective in this environment are the ones who build influence rather than expecting authority to be delegated to them.

The Influence Toolkit

Clarity over volume. The engineer who writes a clear, concise explanation of why a technical decision matters will convince more people than the engineer who talks about it at length in meetings. When you need to persuade someone, start by writing down your argument. If you cannot write it clearly, you do not yet understand it well enough to be convincing.

Data over opinion. "I think we should use approach X" is an opinion. "Approach X reduced p99 latency by 40% when Team Y tried it under similar load characteristics" is data. Whenever possible, anchor technical arguments in evidence — benchmarks, incident data, existing case studies, prior art in the codebase. Opinions require trust. Data invites verification.

RFC as an influence mechanism. An RFC (Request for Comments) is not just a design document. It is a mechanism for building shared ownership of a decision. When you circulate an RFC widely, invite the engineers who will be affected to comment, and incorporate their feedback visibly, you are doing two things: improving the decision and building the coalition that will implement it. Engineers who were consulted in the design phase are far more likely to be aligned in the execution phase.

Timing matters. The same argument lands differently depending on when you make it. After an incident that exposed a dependency risk is a good time to advocate for the investment that would have prevented it. Before a major planning cycle is a good time to raise architectural concerns that should be addressed in the next quarter. Influence is partly about having the right argument, and partly about making it at the moment when the organization is ready to hear it.

Build the relationship before you need it. The engineer who asks another team for a favor before ever having interacted with them is at a disadvantage. The one who has been consistently helpful, visible, and respectful in prior interactions has credit. Influence across team boundaries is built incrementally through a dozen small interactions before it is called upon in a significant ask.

Managing Up: The Strategic Partnership

Most engineers relate to their manager as if the relationship is primarily about reporting status and receiving direction. This is underselling the relationship significantly.

Your manager has organizational context you do not have: what the leadership priorities are, what risks are being discussed at the level above your team, what is coming that has not been announced yet. They also have resources you may need: headcount, priority on the roadmap, political capital to move a dependency. And they have a significant voice in your career trajectory.

A good relationship with your manager is a strategic asset. Here is how to build it:

No surprises. The single most important thing you can do for a manager is make sure they are never blindsided. If a project is at risk, tell them before it is obvious. If there is a conflict with another team, tell them before it escalates. If you are unhappy with something, tell them before it affects your work. Managers who are surprised by bad news lose trust in the people who surprised them, regardless of how good those people are otherwise.

Know what you own and say so. When your manager can predict where your attention is and what you are responsible for delivering, they can manage their own expectations and represent your work accurately to their managers. Ambiguity about what you own creates anxiety for managers. Regular, brief updates on what you are working on and what the status is — not micromanagement, just visibility — reduce that anxiety significantly.

Bring problems with proposed solutions. The manager who gets a problem dropped on their desk without any analysis must do the analysis themselves before they can help. The manager who gets a problem plus a recommendation can either endorse it or redirect it — both of which are faster. "Here is the situation, here is what I think we should do, here is what I need from you" is a more effective interaction than "here is the situation."

What Your Manager Needs From You

Beyond no surprises and problem-solution framing, there are three things that managers universally value and that engineers frequently underdeliver:

Honest signal about what is going well and what is not. Managers get filtered information from everywhere. Their own engineer being honest with them — not complaining, but being genuinely clear — is valuable. If a dependency is consistently blocking your team, say so. If a process is creating waste, name it. This is not whining; it is useful data delivered by someone with direct context.

Taking ownership of outcomes, not just tasks. When you tell your manager "I finished the ticket," you have reported an output. When you tell them "I shipped the feature, adoption is at X%, and the issue we were worried about with Y did not materialize," you have reported an outcome. The second conversation signals that you think about your work the way your manager needs you to think about it.

Growing before being asked. Managers notice when engineers take on new scope, develop new skills, or handle situations they could not have handled six months ago — without being explicitly assigned to do so. This kind of proactive growth is what senior-level advancement looks like from a manager's perspective. They are not looking for people who can execute assigned work. They are looking for people who identify and close their own gaps.

The Sponsor vs. Mentor Distinction

One more thing worth understanding about your manager relationship: the difference between a mentor and a sponsor.

A mentor gives you advice and perspective. A sponsor advocates for you when you are not in the room. At senior level and above, you need sponsors more than mentors. Your manager is your most natural sponsor — but only if they know your work well enough to advocate for it accurately and have enough confidence in you to put their own credibility behind you.

Build that by making your work visible, your thinking clear, and your commitments reliable. A manager who trusts your judgment and knows your work will say "you should talk to X about this" and mean it. That kind of advocacy in closed rooms is the mechanism by which careers advance at senior and above.

The Practical Move This Week

Schedule a 30-minute conversation with your manager outside of normal 1:1s. Agenda: what are the two or three things I should be focused on to have the most impact this quarter, and are there gaps in what I'm doing that would change that? This is not a performance review. It is a calibration conversation that most engineers never have explicitly.

---

Next: the practices that make feedback work — giving it in a way that changes behavior, receiving it without defensiveness — and what Staff and Principal level actually require beyond Senior.