Assessing Project Evidence Against Staff Engineer Expectations

Good to see you again. In the previous lesson, we separated Senior, Staff, and Principal work using scope, ambiguity, influence, and time horizon. This lesson turns that model into a practical audit: you will examine one real past project and identify what it already proves—and what it does not yet prove—about your readiness for a Staff Engineer role.

Use a project you can describe truthfully and with some detail. A Spring Boot microservice delivery, REST API integration, production problem, database change, or modernization effort is suitable. Do not choose the project with the most technologies; choose one with the richest combination of business impact, dependencies, uncertainty, and collaboration.

By the end, you will have an evidence ledger: a concise record of Staff-relevant claims, supporting proof, confidence level, and specific gaps to close through current workplace opportunities or carefully labelled case-study practice.

Plan for about 40 minutes: 7 minutes calibrating expectations, 7 minutes with a resource, and roughly 25 minutes creating your project audit.

---

Assess the work, not the job title

A project does not become Staff-level because it was difficult, took a long time, or used many services. A complex Spring Boot implementation can still be excellent Senior-level work if the goal, boundaries, and major decisions were set elsewhere and the impact stayed within one team.

Conversely, a relatively modest technical change can demonstrate Staff behavior if it required you to define an unclear problem, align several teams, establish a durable direction, and improve how others could deliver afterward.

Etsy’s public engineering ladder offers a helpful benchmark. Its Senior expectation is leading moderately complex, loosely scoped work aligned to a team’s goals. Its Staff expectation moves to significantly complex, unscoped problems, broader domain impact, alignment with business priorities, technical direction, and raising the effectiveness of others.

The key distinction for this audit is:

A project is evidence of Staff-level potential when your contribution changed how a broader group understood, decided, delivered, or operated a meaningful technical outcome.

That statement has several parts. You need evidence not only that you delivered something, but also that you:

• worked toward a meaningful outcome rather than a task list;
• dealt with uncertainty that could not be resolved by coding alone;
• influenced people or teams outside your immediate delivery boundary;
• exercised technical judgment among real alternatives;
• created a result that endured after your direct involvement.

---

Use six lenses to audit one project

Create a working note titled:

Project evidence audit — [project name]

Start with a factual project snapshot. Keep facts separate from interpretation.

Field	Record only what you know
Project and period	Name, approximate dates, your role
Business objective	The customer, revenue, risk, efficiency, or compliance outcome sought
Systems involved	Services, databases, external systems, platforms
Organizational reach	Teams, functions, vendors, or stakeholders involved
Your specific role	Decisions you made, work you led, work you implemented
Outcome	Metrics, operational result, delivery result, or known limitations

If you cannot state the business objective, write the closest truthful version—for example, “reduce failures in order submission” rather than “improve the service.” Mark uncertainty explicitly. That missing clarity is itself useful evidence: it may reveal a framing gap you will learn to address in future initiatives.

Now assess the project using the six lenses below. For each lens, assign a provisional level:

• 0 — no usable evidence yet: you cannot make a specific, defensible claim.
• 1 — strong Senior evidence: you owned substantial delivery or technical judgment within a bounded team or system.
• 2 — Staff evidence: you shaped a broader problem, coordinated direction across boundaries, or created durable leverage.

This is not a promotion score. A single project rarely produces a perfect score in every category. Its purpose is to make vague impressions concrete.

1. Outcome and scope

Start with the outcome, because technical activity without a business or operational purpose is difficult to evaluate at Staff level.

Senior evidence might be:

• independently delivering a major feature in an account-management service;
• leading a migration of a team-owned REST API;
• improving latency or correctness for a known product requirement.

Staff evidence might be:

• connecting an enterprise launch delay to inconsistent workflows across identity, billing, provisioning, and support;
• defining a shared success measure across several teams;
• shaping a multi-phase technical response to a domain-wide reliability or delivery problem.

Write a claim in this form:

“I helped achieve [outcome] by leading [technical and organizational contribution] across [scope].”

Avoid inflated claims such as “I transformed the platform” unless you can name the platform boundary, affected teams, and resulting change.

2. Ambiguity and technical judgment

Staff work is often distinguished by uncertainty at the beginning. The requirements may conflict, ownership may be unclear, or no one may know whether the requested solution addresses the actual problem.

Look for evidence such as:

• competing solution options and their trade-offs;
• a design document, architecture decision record, or meeting notes;
• constraints such as backward compatibility, data correctness, operational risk, cost, or delivery deadlines;
• assumptions you tested rather than silently accepted;
• decisions that required input from teams with different priorities.

For instance, “I migrated a .NET REST API to Spring Boot” describes activity. It becomes stronger evidence only when it explains the judgment:

“We needed to reduce release risk while replacing an unsupported API. I compared an in-place rewrite, a strangler path, and a platform migration; proposed a compatibility-first incremental route; and agreed sequencing with the API consumers.”

That example is Staff-shaped only if the cross-team decision and coordination actually occurred. Never retrofit a polished architecture story onto work that was simply assigned and implemented.

3. Influence across boundaries

Staff Engineers generally lead through influence rather than reporting authority. Evidence is therefore not “I attended meetings” or “I told other teams what to do.” It is proof that a group with different incentives reached a workable, informed decision.

Look for:

• which teams had to change plans, interfaces, or priorities;
• disagreement or tension you helped surface and resolve;
• mechanisms you created: RFCs, design reviews, decision meetings, dependency tracking, shared principles, or rollout plans;
• stakeholder feedback that identifies your concrete contribution;
• evidence that teams adopted a direction without depending indefinitely on you.

A useful distinction:

Weak wording	Evidence-oriented wording
“Worked with the platform team.”	“Facilitated agreement between application and platform teams on deployment ownership, health-check requirements, and a phased rollout.”
“Communicated with stakeholders.”	“Presented two delivery options with reliability and timeline consequences; the product and operations leads chose the phased option.”
“Helped other developers.”	“Delegated API contract design to a senior engineer, reviewed the decision criteria, and enabled them to lead the consumer-team review.”

4. Leverage and capability created

A Staff Engineer’s contribution should make future work easier, safer, or more coherent for others. This may be technical leverage, organizational leverage, or both.

Potential signals include:

• a shared API convention, reusable Spring Boot library, or deployment template;
• a service-ownership or data-ownership boundary that reduced recurring confusion;
• a migration approach that several teams could reuse;
• a mentoring relationship that resulted in another engineer taking on broader technical leadership;
• a recurring decision process that replaced ad hoc escalation.

Be precise. “Created standards” is weak unless you can show adoption and a practical consequence. “Introduced a contract-testing template adopted by three services, reducing integration regressions during releases” is a verifiable claim.

5. Delivery, operational result, and durability

Staff is not merely planning. The direction must eventually produce results, including safe execution and a sustainable operating model.

Search for evidence of:

• a baseline and a measurable outcome: latency, incident rate, release time, manual effort, support volume, adoption, cost, or revenue-related result;
• safe rollout: compatibility strategy, feature flags, canary releases, rollback plan, data migration checks;
• operational ownership: dashboards, runbooks, alerting, service-level objectives, or a clear handover;
• results that persisted beyond initial release.

If no metric was collected, do not invent one. Instead record the evidence available: an incident reduction visible in support records, deployment history, customer feedback, or operational logs. If even that is missing, the gap is “outcome measurement,” not “lack of impact.”

6. Growth of people and the technical organization

At Staff level, raising the capability of others is not a side activity. It is part of how impact scales. This does not require formal management or a large mentoring program.

Evidence may include:

• helping a teammate develop a design, rather than rewriting it yourself;
• giving structured technical feedback that changed a team practice;
• teaching a reliability, testing, or design-review practice that others used;
• enabling another engineer to own a consequential decision;
• creating documentation or onboarding material that reduced dependence on a single expert.

The important test is what changed for the other person or team. “I mentored junior developers” is a start; “I coached an engineer through leading a database migration plan, then they independently led its rollout” demonstrates clearer leverage.

---

A Staff project includes the “people mountain”

Technical complexity matters, but it is not the only kind of complexity. Legacy constraints, unclear ownership, conflicting priorities, incomplete information, and organizational history are part of the system you must navigate.

In this excerpt, Tanya Reilly presents Staff engineering through three pillars: understanding the larger picture, executing bigger and more ambiguous work, and leveling up people and the organization. She then distinguishes influence without direct authority from management.

A calendar full of technical tasks, meetings, and incidents can look like senior responsibility. But activity is not the same as impact or Staff scope.

Use this as a caution when reviewing your own project. “I was very busy” is not evidence. The relevant questions are: What outcome changed? Who could act differently because of my work? What would have gone wrong, or remained unclear, without the intervention?

---

Build an evidence ledger, not a retrospective story

A common interview mistake is producing an eloquent narrative first and searching for proof later. Reverse that order. Build the evidence first; the narrative will become more credible and concise.

The promotion-packet guide from Staff Engineer: Leadership beyond the management track provides practical prompts for this kind of evidence collection: project impact, complexity, organizational leverage, mentorship, “glue work,” advocates, and visible gaps.

Create a ledger like the one below for your selected project. Use short, factual phrases. A blank cell is better than a confident but unsupported claim.

Staff expectation	Your factual claim	Proof or possible source	Confidence	Gap classification	Next action
Business outcome	“Reduced manual reconciliation work during order processing”	Operations ticket trend; stakeholder confirmation	Medium	Measurement gap	Recover before/after volume or hours saved
Broad scope	“Changed integration behavior used by two teams”	API documentation; deployment history	High	Scope may still be Senior-level	Find or create a project involving three or more dependent groups
Technical direction	“Chose PostgreSQL retry approach after evaluating alternatives”	Design notes; pull requests	Medium	Decision-context gap	Reconstruct constraints and rejected options with a former teammate
Cross-team influence	“Coordinated the release”	Meeting invitations only	Low	Influence-evidence gap	Identify who made decisions and what alignment mechanism you led
Durable leverage	“Created shared error-handling code”	Repository; adoption data	Medium	Adoption gap	Verify which services used it and what failure mode it prevented
Raising others	“Reviewed a teammate’s work”	Pull-request comments	Low	Experience gap	Delegate a meaningful design or migration decision in a future initiative

Classify each gap correctly

Not all gaps have the same remedy.

1. Evidence-recovery gap
   You did the Staff-shaped work, but the proof is scattered or undocumented. Recover design documents, pull requests, diagrams, deployment records, metrics, stakeholder feedback, or a short written confirmation from a collaborator. Be accurate about your role.

2. Framing gap
   The project may have had broader potential, but you never articulated the business outcome, constraints, success measures, or alternatives. In future work, write these down at the start. The next lessons in this module will give you formats for doing that.

3. Experience gap
   The work genuinely remained within a team, or decisions and cross-team leadership were led by someone else. This is not a failure of honesty; it is a development priority. Do not attempt to repair it with wording. Seek a new opportunity with a broader boundary.

4. Capability gap
   You had the right scope but could not confidently evaluate the distributed-systems, reliability, cloud, or stakeholder trade-offs involved. This course addresses these gaps directly, and you should apply each new capability to a workplace initiative where possible.

5. Outcome gap
   The project was delivered, but no one measured whether it worked. For future projects, agree on a baseline and a success measure before delivery. Where retrospective measurement is possible, recover it carefully.

This classification matters because the next action differs. A missing metric might be recoverable this month. Lack of cross-team influence requires a new opportunity over the coming months. A simulated architecture case can build your reasoning and communication skills, but it is not a substitute for claiming production impact in an interview.

---

Turn the audit into a six-month evidence plan

You are preparing to interview in roughly six months. Your aim is not to manufacture a single oversized “Staff project.” Instead, build a small portfolio of credible examples with complementary strengths.

For your chosen project, write three final statements:

1. Strongest existing evidence
   One sentence naming the clearest Staff-adjacent behavior you can defend.

2. Most important missing evidence
   One sentence naming the gap that most limits the story today.

3. Next opportunity to create it
   One concrete action at work, such as leading a problem-framing session, writing an architecture brief, defining a measurable reliability objective, coordinating a dependency decision, or delegating a meaningful technical decision.

For example:

Existing evidence: I independently led a high-risk API migration and preserved compatibility for existing consumers.
Missing evidence: I cannot yet show that I set technical direction across several teams or connected the work to a measurable business outcome.
Next opportunity: For the next integration change, convene consumers and operations early, document alternatives and ownership, and agree on a baseline for manual support effort and failed requests.

This plan is deliberately grounded. Given your backend experience, credible near-term opportunities may arise around integration reliability, API evolution, database change safety, production issues, or modernization. The Staff dimension will come from widening the frame: make the broader outcome, stakeholders, trade-offs, ownership, and measurements explicit.

Keep the ledger. It will become raw material for future behavioral stories, your résumé portfolio, and conversations with potential managers. Update it when you recover evidence; do not rely on memory six months from now.

---

Key takeaways

• Assess projects through observable evidence, not job title, years of experience, technical complexity, or busyness.
• Staff-level evidence combines meaningful outcomes with ambiguity handling, cross-boundary influence, technical judgment, durable leverage, and growth of others.
• A project can be strong Senior evidence without being Staff evidence. That is useful calibration, not a reason to exaggerate its scope.
• Separate evidence-recovery, framing, experience, capability, and outcome gaps; each requires a different response.
• Build a small portfolio of complementary examples rather than trying to make every past project prove every Staff expectation.

Next, you will take the first practical step toward closing a framing gap: converting a business objective into a concise technical problem statement.