You Got Promoted to Staff Engineer. Now Nobody Can Tell You What Your Job Is.

You made staff engineer. Your calendar immediately filled with architecture reviews, strategy meetings, and cross-team planning sessions. You write documents more than code. You are supposed to have "influence without authority," which sounds inspiring until you realize it means convincing people to do things when you have no power to make them.

Welcome to the paradox. You chose the IC track because you wanted to stay technical. But the organizational demands consumed your schedule incrementally — first one standing meeting, then another, then a planning session, then a cross-team sync — and suddenly your calendar looks like an engineering manager's calendar without the positional authority that would make the meeting load productive.

This is the universal experience of new staff engineers, and almost nobody prepares you for it. The blog posts about the role are aspirational. The job descriptions are vague. And the actual work is messier, more contradictory, and more ambiguous than anyone admits.

The Three Currencies That Actually Create Influence

"Influence without authority" is the phrase that appears in every staff-plus job description, and it has been repeated so often that it has become a cliché that people nod at without examining what it actually means.

Here is what it means in practice: you need to drive technical outcomes across your organization without the ability to assign work, set priorities, approve budgets, hire people, fire people, or write performance reviews. You cannot mandate anything. You can only persuade.

When a manager makes a technical decision, they can enforce it. The team complies because compliance is part of the employment contract. When a staff engineer makes a technical recommendation, nothing happens automatically. Teams can ignore it, argue with it, agree in the meeting and then quietly do something different, or implement it half-heartedly.

Influence operates through three currencies, and effective staff-plus engineers learn to use all of them.

Credibility is the foundation. People follow your technical guidance because they believe you know what you are talking about. It comes from a track record of good judgment — the systems you designed that worked, the problems you anticipated, the trade-offs you identified that others missed. Credibility is earned slowly and lost quickly. One bad architectural recommendation that costs a team months of rework will damage your credibility more than ten good recommendations will build it.

The most counterintuitive credibility builder: admitting mistakes quickly and clearly. "I recommended the event-driven approach, and it is not working for this use case. Here is what I got wrong and what I think we should do instead." This signals that you care about the right outcome more than about being right.

Trust is different from credibility. Credibility means "I believe you know what you are talking about." Trust means "I believe you have my interests in mind." You can be credible without being trusted — people might respect your technical judgment but suspect that your recommendations serve your agenda rather than the team's needs. Trust is built through following through on commitments, giving credit generously, keeping confidences, and being consistent across audiences. Say the same things in one-on-ones that you say in group meetings.

Relationships are the mechanism through which credibility and trust convert into actual influence. You might be highly credible and deeply trusted, but if you do not have relationships with the people who make and implement decisions, your influence has no channel to flow through. The critical move: invest time before you need something. The worst time to build a relationship with an engineering manager is when you need their team to change their approach.

In practice, this means when you want to change a team's technical direction, you start by understanding — genuinely — why they chose their current approach. You acknowledge what is right about it before proposing an alternative. You frame the problem rather than prescribing the solution: "I am concerned that synchronous calls to the three downstream services will create cascading failure scenarios under peak load. How have you thought about that?" This invites collaboration rather than triggering defensiveness.

The Coding Question That Haunts Every Staff Engineer

How much code should you be writing? This generates more anxiety than any other aspect of the role, and it comes from both directions.

Write too much code and you are doing work that senior engineers should be doing, blocking growth, and neglecting the strategic responsibilities your role demands. Write too little and you lose touch with the codebase, your technical opinions become less credible, and you start feeling like a fraud who talks about engineering without actually doing it.

Most staff engineers who struggle with this fall into one of two failure modes.

The Reluctant Manager spends most of their time in meetings and documents, rarely touching the codebase. Their technical credibility erodes slowly and then suddenly. For the first six months, people still trust their opinions based on track record. By month twelve, engineers start quietly noting that the staff engineer's recommendations do not account for recent changes. By month eighteen, their architectural guidance is politely received and quietly ignored.

As one staff engineer put it: "I realized I was in trouble when a senior engineer asked me a basic operational question about a system I had designed eighteen months earlier but had not touched since. That was the moment I understood that my technical credibility was a depreciating asset, and I had not been reinvesting."

The Hero Coder writes as much code as before the promotion and takes the hardest, most critical implementation work. They are technically excellent and deeply grounded — but they are hoarding the work that should develop other engineers. By taking the hardest problems, they prevent growth. By being on the critical path, they create bottlenecks. They justify it with "nobody else can do this as well as I can," which reveals a staff engineer who has not made the leverage shift from personal output to organizational output.

The right question is not "how much should I code?" but rather: "Is this code that only I can write?" If you are the only person with the expertise to implement a critical algorithm, your direct contribution is the highest-leverage use of your time. But be honest about whether "only I can write this" means "only I have the knowledge" or "only I can write it this well." The first justifies your involvement. The second does not — someone else can write it adequately, and the learning opportunity is worth more than the quality delta.

The highest-value coding for staff engineers is prototypes that demonstrate architectural approaches, reference implementations that establish patterns for other teams, investigative spikes that evaluate technology choices, and critical-path unblocking when a team is stuck on a problem that requires expertise they do not have. The lowest-value coding is feature work a senior engineer could handle, routine maintenance, and rewriting things that already work to match your preferred patterns.

And the biggest practical obstacle is the calendar. Staff-plus calendars are fragmented into 30-minute blocks with meetings scattered everywhere. The solution is not hoping that space appears. It is blocking two-to-four-hour chunks at least twice a week and protecting them like a meeting with your VP. If you let meetings expand into your coding time, the meetings will always win.

Technical credibility has a half-life. Each month without visible technical contribution reduces it slightly. After six months of purely organizational work, it starts to show cracks. After a year, it is significantly diminished. The staff engineers who maintain their credibility long-term are the ones who never fully leave the technical work — because they understand that their organizational effectiveness depends on their technical grounding.