Choosing What to Work On

The hardest skill at the Staff level is not technical. It is deciding what deserves your time. For the first time in your career, nobody hands you a backlog. No manager assigns your quarterly projects. No product manager writes your tickets. You look at the entire engineering organization and ask: "Where is the highest-leverage place I can spend the next month?"

Get this right and you become indispensable. Get it wrong and you spend a quarter building something clever that nobody needed.

Self-direction is what separates Staff Engineers who thrive from those who stall. Every other Staff skill — writing RFCs, influencing without authority, navigating politics — depends on first choosing the right problem.

Why Self-Direction Is So Hard

At every level before Staff, the feedback loop between effort and recognition is tight. You pick up a ticket, write code, ship it, and the team sees the result. The work is bounded and legible.

At Staff, the highest-leverage work is often invisible, ambiguous, and long-running. You might spend three weeks investigating a systemic reliability problem that nobody asked you to look at. If you fix it, people barely notice because the incidents simply stop happening. If you choose wrong, you have lost three weeks with nothing to show.

The anxiety of this ambiguity drives many Staff Engineers back toward comfortable Senior-level work — picking up feature tickets, doing code reviews all day, or volunteering for on-call rotations. These activities feel productive because they are visible and bounded. But they are not Staff-level work.

The Self-Direction Spectrum

Fully assigned ←————————————————————→ Fully self-directed
Junior          Senior          Staff          Principal
~90% assigned   ~60% assigned   ~20% assigned   ~5% assigned

At Staff, roughly 80% of your work should come from problems you identified yourself. If most of your time is spent on work someone else defined, you are operating below your level.

A Framework for Evaluating Opportunities

When you see a potential problem to work on, run it through four dimensions before committing your time.

Impact

What is the blast radius if this problem gets solved? Does it affect one team, one domain, or the entire engineering organization?

A real-world example: a Staff Engineer at a logistics company noticed that every team had built their own retry logic for external API calls. Some teams used exponential backoff, some used fixed intervals, and two teams had no retry logic at all. Standardizing this into a shared library affected every service in the system — high impact.

Compare that with optimizing the build pipeline for a single team. Useful, but limited blast radius. A Senior engineer on that team could own it.

Ask yourself: "If this succeeds, how many people benefit? How much engineering time does it save? Does it reduce risk at scale?"

Effort

How much time and coordination does this require? Is it a two-week prototype or a six-month migration? Do you need buy-in from three teams or thirty?

High-impact, low-effort opportunities are rare but valuable. When you find one, act immediately — they tend to disappear as the organization grows around them.

High-impact, high-effort opportunities require sponsorship from leadership. Before committing, make sure a director or VP will back you when you need resources from other teams.

Strategic Alignment

Does this work align with where the company and engineering organization are headed? A technically excellent solution to a problem the company is about to deprecate is wasted effort.

A Staff Engineer at an e-commerce company spent two months designing a sophisticated caching layer for the monolithic application. During that time, the VP of Engineering committed to a microservices migration. The caching layer was never deployed because the monolith was being decomposed. The work was technically sound but strategically misaligned.

Before committing to a large initiative, ask your manager and your skip-level: "What are the top three engineering priorities this year?" If your proposed work does not connect to at least one of them, reconsider.

Timing

Is this the right moment? Some problems are important but not urgent. Others have a narrow window where intervention is possible.

Timing considerations include:

- Is there a team currently making a decision that this work would inform?
- Is a related initiative already underway that you can attach to?
- Is the organization about to undergo a change (reorg, new leadership)
  that will shift priorities?
- Has the problem reached the pain threshold where people are
  receptive to a solution?

A Staff Engineer at a healthcare company identified that the deployment process needed a major overhaul. But the timing was wrong — two teams were mid-migration and the platform team was understaffed. Six months later, after the migrations completed and the platform team hired two engineers, the same proposal was embraced. The problem had not changed. The organizational readiness had.

The Evaluation Matrix

When comparing multiple opportunities, score each on the four dimensions:

Opportunity: Unify authentication across services
  Impact:              High (12 teams affected, security risk)
  Effort:              High (6-month initiative, cross-team coordination)
  Strategic alignment: High (security audit coming in Q3)
  Timing:              Good (new security team just formed)
  Verdict:             Commit. High effort but everything else aligns.

Opportunity: Migrate logging to structured format
  Impact:              Medium (improves debugging for all teams)
  Effort:              Medium (3-month effort, mostly tooling changes)
  Strategic alignment: Medium (supports observability goals)
  Timing:              Neutral (no forcing function)
  Verdict:             Propose but do not lead. Write the RFC, find a
                       Senior engineer to own execution.

Opportunity: Rewrite the admin dashboard backend
  Impact:              Low (one internal team uses it)
  Effort:              High (legacy code, unclear requirements)
  Strategic alignment: Low (not connected to any org priority)
  Timing:              Poor (the team using it is happy enough)
  Verdict:             Skip. Interesting technically but low leverage.

Identifying High-Leverage Problems

The best problems to work on share certain characteristics. They are systemic, not local. They affect multiple teams. They are getting worse over time. And often, nobody is working on them because they do not belong to any single team.

Where to Look

Cross-team friction points. Where are teams blocked waiting on each other? Where do handoffs break down? Where are teams duplicating effort because no shared solution exists?
Recurring incidents. Look at the last six months of incident reports. What patterns emerge? If the same category of failure keeps happening across different services, there is a systemic problem worth solving.
Developer experience pain. What do engineers complain about most? Slow builds, flaky tests, confusing deployment processes, and poor documentation are often high-leverage problems because they affect every engineer every day.
Upcoming scaling walls. What parts of the system will break at 2x or 10x current load? Solving scaling problems before they become incidents is classic Staff-level work.
Technical debt with compounding interest. Not all tech debt is equal. Some is stable — ugly but not getting worse. Some compounds — every new feature makes it harder to change. Focus on the compounding kind.

Talking to People

The most underrated method for identifying high-leverage problems is simply talking to engineers, managers, and product leaders across the organization.

Ask every team lead you meet: "What is the biggest technical problem your team faces that nobody is working on?" After five or six conversations, patterns emerge. If three team leads independently mention the same problem, you have found something worth investigating.

Saying No to Low-Leverage Work

Choosing what to work on requires an equally difficult skill: choosing what not to work on.

Staff Engineers are in demand. Every team wants your input. Every architecture review seems important. Every incident review needs a senior perspective. If you say yes to everything, you will be busy every day and accomplish nothing of substance.

How to Say No

"I am not the best person for this." When a Senior engineer on the team could handle it, say so. Redirect rather than absorb. "This is a great problem for Sarah to own — she has the context and it would stretch her toward Staff scope."
"This is important but I cannot take it on this quarter." Acknowledge the value without committing. Offer to review their approach or connect them with someone who can help.
"Let us find a smaller version of this." When someone asks you to lead a large initiative that is not high-leverage, propose a lighter-weight approach. "Instead of a full rewrite, what if we created an adapter layer? A Senior engineer could own the implementation after I sketch the design."

The Technical Fascination Trap

The most seductive form of low-leverage work is the technically interesting problem that does not matter much to the organization. Staff Engineers tend to be deeply curious, and a challenging distributed systems puzzle or an elegant algorithm optimization can consume weeks of your time.

A Staff Engineer at a streaming company spent a month optimizing the memory allocation patterns in a data processing pipeline. The optimization was technically brilliant — it reduced memory usage by 40%. But the service was already well within its resource limits and the optimization affected no user-facing metrics. The month would have been better spent on the cross-service data consistency problem that was causing weekly incidents.

Ask yourself: "Am I choosing this because it is important, or because it is interesting?" Both matter, but importance must come first.

Balancing the Portfolio

Effective Staff Engineers maintain a portfolio of work at different time horizons:

Time horizon     Allocation     Examples
Immediate        ~20%           Unblocking teams, code reviews, incident response
Short-term       ~30%           Current quarter initiative, active RFC
Medium-term      ~30%           Next quarter planning, design exploration
Long-term        ~20%           Technology radar, strategic positioning

If 100% of your time is reactive, you are not driving enough. If 100% is long-term strategic, you are disconnected from the organization's daily reality.

Review your allocation monthly. If the balance is off, adjust deliberately.

Communicating Your Choices

Once you have chosen what to work on, communicate it clearly. Your manager, your teams, and your stakeholders should all understand your current priorities and why you selected them.

The Quarterly Priority Document

At the start of each quarter, write a brief document outlining your top priorities and share it with your manager and key stakeholders.

Quarterly priorities — Q2 2026

Primary initiative: Unify authentication across services
  Why: 3 security incidents in the last year from inconsistent token
  validation. Security audit in Q3 creates a forcing function.
  Expected outcome: Single auth gateway handling all internal services.

Secondary initiative: Mentor two Senior engineers on cross-team design
  Why: Both are pursuing Staff and need practice operating at broader
  scope. This also creates capacity for future cross-team work.

Explicitly not doing: Admin dashboard rewrite, build pipeline optimization
  Why: Low organizational leverage. Redirected to team-level ownership.

This document serves three purposes: it forces you to be explicit about your choices, it gives your manager the context to support your decisions, and it creates a record you can reference when someone asks you to take on unplanned work.

Common Pitfalls

Defaulting to what is comfortable. Picking up code-heavy tasks because they feel productive instead of tackling the ambiguous cross-team problem that nobody else will own.
Working on what you were asked to do. If your manager or a VP hands you a project, evaluate it through the same framework. Seniority means you push back when the work is misaligned. "I understand this feels urgent, but I think my time is better spent on X because of Y."
Trying to do everything. Spreading yourself across five initiatives and making progress on none. Commit to one or two primary efforts per quarter and protect that focus.
Ignoring organizational context. Choosing technically optimal problems without considering whether the organization is ready to solve them. Timing matters as much as importance.
Not revisiting your choices. The right problem in January may be the wrong problem in March. Re-evaluate your portfolio when new information arrives — a reorg, a strategy shift, a competitor move.
Confusing visibility with leverage. High-visibility projects (a demo for the CEO, a conference talk) feel important but may not create lasting technical impact. Seek leverage first, visibility second.
Working alone on something that needs buy-in. Spending weeks building a solution in isolation, then discovering that the teams who need to adopt it have objections you never considered. Socialize your ideas early.

Key Takeaways

Self-direction — choosing your own work — is the defining skill of the Staff level and the most common source of struggle for newly promoted engineers.
Evaluate every opportunity through four dimensions: impact, effort, strategic alignment, and timing. All four must be favorable for a large commitment.
The highest-leverage problems are systemic, cross-team, worsening over time, and unowned — look for them in recurring incidents, cross-team friction, developer experience pain, and upcoming scaling walls.
Talk to engineers and leaders across the organization to surface patterns; if three team leads independently mention the same problem, it is worth investigating.
Saying no is as important as saying yes; redirect low-leverage work to Senior engineers who would benefit from the growth opportunity.
Beware the technical fascination trap: choose problems because they are important, not because they are interesting.
Maintain a portfolio across time horizons — roughly 20% immediate, 30% short-term, 30% medium-term, and 20% long-term.
Review and adjust your work portfolio monthly; the right problem changes as organizational context shifts.
If most of your time is spent on work someone else defined, you are operating below your level.