Who this is for
A mid-to-senior engineer (IC3–IC5) at a product company who wants their next 6–12 months of work to serve double duty: ship something valuable and build a resume line that opens doors — for promotion, for the next job, or both. You’re past the “take whatever’s assigned” phase and have some agency over what lands on your plate, but you haven’t systematically used that agency to shape your trajectory.
The core insight
Most engineers evaluate projects by interest (“is this fun?”), difficulty (“is this hard enough?”), or visibility (“will people notice?”). None of these correlate reliably with career ROI. The variable that actually matters is transferable signal: does this project produce evidence of a capability that’s valued beyond your current team?
A project that’s hard but team-specific (migrating an internal service nobody outside your org has heard of) produces no transferable signal. A project that’s medium-difficulty but demonstrates a broadly-valued capability (designed and shipped a real-time processing system, reduced API latency 5x on a revenue-critical path) transfers everywhere.
The guide below is a sourcing method: how to find projects with high transferable signal at your current company, without changing teams or jobs.
The tactics
1. Audit the org roadmap for “nobody wants this” projects
The highest-signal projects are often hiding in plain sight on the roadmap. They have three characteristics:
- They’ve been on the plan for 2+ quarters without an owner.
- They’re consequential (someone VP-level mentioned them).
- They’re technically ambiguous (no clear approach, which is why nobody volunteered).
These projects are gold because the ambiguity creates scope (you define the approach), the consequence creates impact (a number will move), and the lack of owner creates ownership signal (you are the person who did this).
Concrete sourcing move: read the next two quarters of your org’s roadmap. Look for items that have been deferred once already. Talk to your manager or the relevant tech lead and say: “I noticed X has been deprioritized twice. I’d like to scope it and propose an approach. Can I take two days to investigate?”
That sentence — “I’d like to scope it” — is stronger than “I’d like to work on it.” Scoping is a senior-level activity. Working on something is any-level.
2. Look for projects at the boundary between two teams
Cross-team projects carry disproportionate signal because they demonstrate scope, leadership, and coordination — three signals that every rubric at senior+ values and that single-team projects structurally cannot demonstrate.
Where to find them:
- Integration points. Your team owns a service that another team consumes. The integration is clunky, both teams complain, nobody owns the fix. Volunteer to own the fix — both the technical design and the cross-team coordination.
- Shared infrastructure. A library, tool, or platform that multiple teams use but nobody owns. Adopting it (writing the RFC, doing the migration, being the escalation point) is staff-level scope at many companies.
- Data flows. Data crosses team boundaries constantly. The team producing the data and the team consuming it often disagree on schema, freshness, or quality. Owning the contract and the pipeline between them is a high-signal project.
The phrase to say out loud to your manager: “This problem sits between our team and [other team]. I’d like to own the coordination and the technical solution. Can you introduce me to [their tech lead]?“
3. Attach a business metric to infrastructure work
Infrastructure work is the most common trap for backend engineers. It’s technically satisfying, clearly necessary, and completely invisible at calibration time — because it produces no number a non-engineer would recognize.
The fix is not to avoid infrastructure work. It’s to connect it to a downstream metric before you start:
- “Rewrite the deploy pipeline” → “increase deploy frequency from 2x/week to daily, which the product team says is blocking their release cadence.”
- “Add caching to the search service” → “reduce search p99 from 800ms to 200ms, which product estimates drives 3% more searches per session.”
- “Migrate off the legacy auth service” → “free 2 engineers from maintenance, enabling them to ship [specific feature] next quarter.”
The tactic: before committing to the project, talk to the team or PM who benefits from the outcome. Ask them: “what metric changes if I succeed?” Write that metric into the project doc on page one. At review time, cite it.
If the infrastructure work doesn’t have a downstream beneficiary who can name a metric, it’s probably not the right project for career purposes — even if it’s important for technical health. Someone should do it; it doesn’t have to be you this quarter.
4. Prefer “build new” over “maintain existing” — but not always
Building a new system demonstrates more capabilities in a single project than maintaining an existing one: you make architecture decisions, you define the API, you own the trade-offs from scratch. Maintenance demonstrates reliability and operational depth but rarely produces a packet-ready sentence.
The exception: taking an existing system from bad to good (not from good to slightly-better). If the system is actively painful — high incident rate, performance regression, team velocity blocker — and you take it from its current state to a measurably better state, that’s a build story in disguise. The “before” number is so bad that the improvement reads as creation, not maintenance.
The test: can you write the sentence “I took [system] from [bad state] to [good state]”? If the bad state is genuinely bad, the project is as good as a greenfield build for resume purposes. If the bad state is “working fine but could be cleaner,” the project is maintenance and you should find something else.
5. Negotiate a time-boxed exploration before committing
The hardest part of project selection is that you don’t know whether a project will produce signal until you’re already deep in it. By then, switching costs are high.
The tactic: before committing to any multi-month project, negotiate a 1–2 week investigation phase. The deliverable of the investigation is a one-page doc that answers:
- What’s the scope? (Cross-team or single-team? Ambiguous or clear?)
- What’s the measurable outcome? (Metric A → metric B.)
- What architecture decision will I make? (This is the technical-depth signal.)
- Who else is affected? (This is the leadership signal.)
If the one-pager doesn’t produce compelling answers — if the scope is narrow, the metric is unclear, and no architecture decision is needed — you’ve learned in two weeks that this project doesn’t serve your trajectory. Bail before committing a quarter.
This isn’t career-gaming. It’s due diligence on the largest investment you make every quarter: your time.
6. Say no to the projects that fill none of your gaps
This is the hardest tactic and the one with the highest ROI. Saying no is a senior-level skill; doing it well requires a specific script.
When your manager offers a project that scores zero on your gap analysis:
- “I can see why this is important. I want to make sure we’re aligned on my growth trajectory — would it be okay if I took [other project] instead, since it maps better to the areas we discussed in my last review?”
- “I’m happy to do this, but I want to flag that it’s similar to the last two projects I shipped — great execution, but not growing a new signal. Can we discuss whether there’s something on the roadmap that stretches me in [gap category] instead?”
Neither script is adversarial. Both are explicit. Most managers will redirect if you frame the ask clearly — and the ones who won’t are telling you something about whether this team can advance you.
7. Build a portfolio, not a list
The resume line for a project is one sentence. But the evidence behind that sentence — the design doc, the metrics before/after, the incident where you handled the failure mode — is what makes the sentence credible in an interview or promo packet.
For every project you take on:
- Save the design doc (or write one if none exists).
- Record the before/after metric when you ship.
- Write 3–5 bullet points about what was hard, what you decided, and what you’d do differently.
This takes 30 minutes per project. The return is that you can speak to any project in your last 3 years with concrete detail and quantified impact — which is what behavioral interviews and promotion committees actually calibrate on.
Common failure modes
Picking projects for visibility alone. High-profile projects often carry low signal — they’re high-profile because a VP cares, not because they require senior-level work. A visible project where any IC3 could have done the same work reads as “was in the room when something happened” at calibration. Check the signal, not the spotlight.
Staying too long in a gap-filling project. The project served its purpose at month 3; by month 9, it’s maintenance. The diminishing returns are steep — the first architecture decision carries all the signal; the next six months of operational work adds nothing. Know when to transition ownership and move on.
Confusing learning with signal. A project where you learn a new framework or language is valuable for you, but it doesn’t produce a resume line unless the outcome is notable. Learning is input; signal is output. The question isn’t “did I grow?” — it’s “can a future employer or promo committee see the growth from the outside?”
Accepting every project that seems interesting. Interest is orthogonal to career ROI. Some interesting projects are narrowly scoped, technically routine, or produce no measurable outcome. They’re fine as 20% side work; they’re expensive as your main quarter commitment.
Never saying no. If you accept every assignment without filtering, you’re letting your manager’s optimization function (team velocity) override yours (career trajectory). These are compatible 80% of the time, but the 20% where they diverge is where project selection matters most.
What to do next
This week: run the gap analysis from aligning projects. Identify which signal category is weakest. Then read your org’s next-quarter roadmap with the sourcing tactics above and identify 2–3 candidate projects that could fill the gap.
Next 1:1 with your manager: surface your analysis. Say: “I’ve been thinking about what would be most valuable for me to work on next quarter. Here’s what I’m seeing as my gap, and here’s a project I think fills it. What do you think?”
That conversation — explicit, non-adversarial, and pre-researched — is itself a signal of seniority.
Related
- Framework: Aligning Projects With Your Next-Level Goal — the gap-analysis method this guide assumes you’ve run.
- Framework: Scope, Impact, Visibility — Three-Axis Promotion Model — the promotion model that defines what “signal” means.
- Plan: Complete Senior Backend Interview Prep — if the right project doesn’t exist at your company, prep for the move.