- Authors
- Name
- Introduction
- The Four Staff Engineer Archetypes
- Technical Decision-Making: RFC and ADR
- Expanding Influence: Beyond Code
- Mentoring and Sponsorship
- Strategic Tech Debt Management
- Building Engineering Culture
- Staff Engineer Career Growth Roadmap
- Conclusion
- References
Introduction
After becoming a senior engineer, career paths generally diverge into two directions. Transitioning to an Engineering Manager (EM) or growing along the Individual Contributor (IC) track to Staff Engineer and beyond. While the Staff Engineer title may not be familiar in many Korean organizations, it's an established key stage in the career ladder at global tech companies.
What differentiates a Staff Engineer from a Senior Engineer? In a nutshell, it's the scope of influence. While a senior engineer writes excellent code within their team, a Staff Engineer influences the technical direction of the entire organization beyond their team. Writing great code remains important, but it's no longer sufficient.
This article draws on Will Larson's "Staff Engineer" and Tanya Reilly's "The Staff Engineer's Path" to practically cover the four Staff Engineer archetypes, technical decision-making through RFC/ADR, influence expansion strategies, mentoring and sponsorship, strategic tech debt management, and engineering culture building.
The Four Staff Engineer Archetypes
Will Larson categorizes Staff Engineer roles into four archetypes. Most Staff Engineers lean toward one archetype, but may move between roles depending on the situation.
1. Tech Lead
Leads the technical direction of a single team or small team cluster.
- Drives technical decisions and maintains code quality for the team
- Manages the technical aspects of project planning and execution
- Works closely with Engineering Managers, bridging technical and people aspects
- The most common archetype, representing about 50% of Staff Engineers
2. Architect
Responsible for technical direction and quality across multiple teams.
- Establishes organization-wide technical vision and strategy
- Defines cross-system interfaces and integration patterns
- Sets technical standards and best practices
- Primarily found in large-scale organizations (hundreds to thousands of engineers)
3. Solver
A specialist who tackles particularly difficult or urgent problems.
- Deployed to the most challenging technical problems in the organization
- Moves on to other problems after project completion
- Requires deep technical expertise and rapid learning ability
- Excels in highly specialized areas (security, performance, infrastructure)
4. Right Hand
Serves as the technical partner to senior leaders like VPs/CTOs.
- Supplements leaders' technical judgment and supports decision execution
- Coordinates organization-wide technical initiatives
- Requires strong organizational awareness and communication skills
- The rarest archetype
Which Archetype Fits You?
Self-Assessment Questions
============================================
1. I enjoy working deeply within a single team
-> Yes: Tech Lead tendency
2. I'm interested in ensuring technical consistency across multiple teams
-> Yes: Architect tendency
3. I get excited about solving "seemingly impossible" technical problems
-> Yes: Solver tendency
4. I want to understand and influence the direction of the entire organization
-> Yes: Right Hand tendency
Note: Archetypes are not fixed. They can change based on career stage and organizational context.
Technical Decision-Making: RFC and ADR
Why Documented Decisions Matter
One of the most important roles of a Staff Engineer is making technical decisions transparent. Decisions communicated only verbally lose context, and later no one can answer "Why did we do it this way?"
RFC (Request for Comments)
An RFC is a process for proposing significant technical changes and gathering organizational feedback.
# RFC: Introducing Event Sourcing for Order Service
## Metadata
- Author: Youngju Kim
- Status: Under Review
- Created: 2026-03-01
- Reviewers: Seojun Park, Minha Lee, Dayun Jung
- Decision Deadline: 2026-03-14
## Summary
Transition the Order Service's state management from the current CRUD approach
to Event Sourcing to meet order history tracking and audit log requirements.
## Motivation
1. Financial regulation compliance: Mandatory 5-year retention of order state change history
2. Customer support: Need accurate answers to "Why was my order canceled?"
3. Analytics: Need granular event data for order funnel analysis
## Proposed Design
(Detailed technical design content)
## Alternative Analysis
### Alternative 1: CDC (Change Data Capture) + Separate History Table
- Pros: Minimal existing code changes
- Cons: Difficult to guarantee consistency between history and current state
### Alternative 2: Audit Log Library
- Pros: Simple implementation
- Cons: No event replay, only partial history retention
### Alternative 3: Event Sourcing (Selected)
- Pros: Complete history, event replay, time-travel queries
- Cons: Learning curve, requires separate read model
## Implementation Plan
- Phase 1 (2 weeks): Event store infrastructure setup
- Phase 2 (3 weeks): Order creation/modification event sourcing migration
- Phase 3 (2 weeks): Read model (CQRS) development
- Phase 4 (1 week): Existing data migration
## Risks
1. Team learning curve (Mitigation: 2 event sourcing workshops)
2. Potential read performance degradation (Mitigation: Separate read model via CQRS)
3. Increased operational complexity (Mitigation: Event store monitoring dashboard)
## Open Questions
- Event store: EventStoreDB vs PostgreSQL + Outbox pattern
- Event schema evolution strategy (upcasting vs versioning)
ADR (Architecture Decision Record)
ADRs are a lighter format than RFCs, recording the context and outcomes of individual technical decisions.
# ADR-042: Choosing JWT for API Authentication
## Status
Approved (2026-03-10)
## Context
We need to unify API authentication across microservices.
Currently, services use a mix of API Key, Session, and JWT,
making security audits and debugging difficult.
## Decision
Adopt JWT (JSON Web Token) as the standard authentication method for inter-service communication.
- Token issuance: Auth service (Keycloak-based)
- Token verification: Local verification using public keys at each service
- Token expiry: Access Token 15 min, Refresh Token 7 days
## Consequences
- Positive: Unified auth, eliminated Auth service bottleneck for inter-service calls
- Negative: Token revocation not immediately reflected (must wait for expiry)
- Neutral: JWT verification middleware needed in each service
## Alternatives
- API Key: Simple but complex key management, limited fine-grained permissions
- mTLS: Strong security but high certificate management overhead
- OAuth2 Opaque Token: High Auth service dependency
RFC/ADR Best Practices
- Manage RFC/ADR in the code repository: Version control decisions alongside code
- Set review deadlines: Open-ended RFCs delay decisions
- Provide templates: Consistent format reduces writing burden
- Archive rejected RFCs: "Why we didn't choose this approach" is also valuable knowledge
Expanding Influence: Beyond Code
The Power of Writing
For Staff Engineers, writing is not optional — it's essential. Code impacts one team, but well-written technical documents impact the entire organization.
Effective Technical Writing Types:
- Technical vision documents: Paint the target state of the tech stack 6-12 months out
- Postmortems: Extract lessons the organization can learn from incidents
- Onboarding guides: Help new engineers become productive quickly
- Tech blog posts: Share knowledge with the external community, strengthen hiring brand
Leveling Up Through Code Reviews
A Staff Engineer's code review goes beyond simple defect detection to serve an educational function.
Typical Senior Engineer Code Review:
"Rename this function from getUser to fetchUserById."
Staff Engineer Code Review:
"Since this function does a DB query, the fetch prefix would be more
appropriate. Our team convention is to use get/compute for pure
calculations and fetch/load for I/O operations. What if we documented
this convention as an ADR?
Related example: payment-service's fetchOrderHistory"
Influence in Meetings
Staff Engineers should facilitate decisions in technical meetings.
- Before decisions: Prepare and share options with trade-offs in advance
- During meetings: Redirect with key questions when discussions go off track
- After decisions: Clearly document decisions and action items
Mentoring and Sponsorship
Mentoring vs Sponsorship
Many senior engineers mentor but don't sponsor. They're different.
- Mentoring: Sharing knowledge and experience, giving advice ("Here's how to do it")
- Sponsorship: Creating opportunities and increasing visibility ("Let's assign you as the lead for this project")
Sponsorship is more powerful because it provides the growth opportunity itself.
Effective Mentoring Framework
1:1 Mentoring Structure (biweekly, 30 min)
============================================
5 min - Check-in: "What's been most challenging lately?"
10 min - Technical depth: Discuss technical concerns in current work
10 min - Career growth: Review long-term goals and current position
5 min - Action items: Set goals for next meeting
What a mentor should do:
- Guide thinking through questions rather than giving answers
- Honestly share personal failure experiences
- Adjust difficulty based on mentee's growth
What a mentor should not do:
- Do the mentee's work for them
- Present their career path as the only correct answer
- Share mentoring content with the mentee's direct manager (trust violation)
Strategic Tech Debt Management
Translating Tech Debt into Business Language
Saying "We need to pay off tech debt" won't move business leaders. Staff Engineers must be able to translate tech debt into business impact.
Bad example:
"Test coverage is low, so we need to refactor."
Good example:
"The current payment module has 30% test coverage.
2 of the 3 payment-related incidents last quarter occurred
in untested code paths. Each incident averaged 2 hours of
service downtime and approximately 5 million won in lost revenue.
2 weeks of test reinforcement could reduce the expected
incident rate by 60%."
Tech Debt Prioritization Matrix
High Business Impact
|
Q2: Planned Repayment | Q1: Immediate Repayment
(Next quarter roadmap)| (Include in sprint)
|
────────────────────────┼──────────────────────
|
Q4: Accept | Q3: Gradual Improvement
(Maintain current state)| (Boy Scout Rule)
|
Low Business Impact
Left: Low change frequency Right: High change frequency
- Q1 (Immediate Repayment): Tech debt in code with high business impact and frequent changes. Top priority
- Q2 (Planned Repayment): High business impact but infrequently changed code. Include in roadmap
- Q3 (Gradual Improvement): Frequently changed but low business impact code. Apply Boy Scout Rule
- Q4 (Accept): Both low. Accept current state
Building Engineering Culture
Psychological Safety
As Google's Project Aristotle research revealed, the most important characteristic of top-performing teams is psychological safety. Staff Engineers are responsible not just for technical excellence but also for team culture.
Staff Engineer Behaviors That Increase Psychological Safety:
- Publicly acknowledge mistakes: "There's something I missed in this design"
- Welcome questions: Instead of just "Good question," explain specifically why it's a good question
- No blame in postmortems: Explore "what system factors" caused the incident, not "who"
- Actively solicit diverse opinions: "Does anyone have a different perspective?"
Transparency in Technical Decisions
The more transparent the technical decisions led by Staff Engineers, the higher the organization's trust.
- Share why this technology was chosen and what alternatives were considered
- If a decision was wrong, honestly acknowledge it and course-correct
- Provide opportunities for engineers at various levels to participate in the decision process
Fostering a Learning Culture
Learning Culture Practices
============================================
Weekly:
- Tech Talk (30 min): Team members take turns presenting on technologies of interest
- Code Review Power Hour: Entire team reviews important PRs together
Monthly:
- Technical book reading group
- Incident review sessions (postmortem sharing)
- Hackathon or Innovation Day
Quarterly:
- Technology Radar update (Adopt/Trial/Assess/Hold)
- Career growth 1:1 (Manager + Staff Engineer)
- External conference attendance and internal sharing
Staff Engineer Career Growth Roadmap
Transitioning from Senior to Staff
What's needed to advance from Senior Engineer to Staff Engineer is not "writing more code."
Capability Changes Needed for Senior -> Staff Transition
============================================
Do more of:
+ Technical influence beyond the team
+ Documented technical decisions (RFC/ADR)
+ Organization-level technical problem solving
+ Supporting growth of junior/mid-level engineers
+ Understanding business context and connecting it to technical strategy
Less required:
- Writing all code yourself
- Knowing every technical detail
- Participating in every code review
Never lose:
! Maintaining coding ability (30-50% hands-on ratio)
! Learning technical trends
! Humility and curiosity
Writing an Impact Log
At the Staff Engineer level, systematically documenting your impact is crucial. Relying on memory at performance review time means missing important contributions.
# Impact Log - 2026 Q1
## Organizational Impact
- [RFC-018] Proposed and approved event sourcing for payment service (3/1)
- Impact scope: Payment team, Orders team, Settlement team
- Expected outcome: 100% compliance with audit log requirements
## Tech Debt Repayment
- Led authentication middleware unification project (1/15 - 2/28)
- Unified authentication across 5 services to JWT
- Resolved 3 security audit findings
## Mentoring/Growth Support
- Regular mentoring for 2 junior engineers (biweekly)
- Supported 1 senior promotion (successful)
- Conducted "Distributed Systems Fundamentals" internal workshop (2/10, 25 attendees)
## Incident Response
- Led payment gateway timeout incident response (1/22)
- Root cause identified and hotfix deployed within 30 minutes
- Authored postmortem with 3 recurrence prevention measures
Conclusion
The essence of a Staff Engineer is converting technical excellence into organizational outcomes. No matter how outstanding your individual coding skills, if they don't translate into improved team and organizational capability, it's not Staff-level influence.
Here are the key takeaways:
- Identify your archetype: Find your fit among Tech Lead, Architect, Solver, and Right Hand, but transition flexibly based on context
- Make decisions transparent: Record the context of technical decisions with RFCs and ADRs, and archive rejected alternatives too
- Extend influence through writing beyond code: Deliver value across the organization through tech vision docs, postmortems, and onboarding guides
- Evolve from mentoring to sponsorship: Become a sponsor who creates growth opportunities, not just an advisor
- Translate tech debt into business language: Persuade with business impact and ROI instead of "We need to refactor"
- Build a culture of psychological safety: Acknowledge mistakes, welcome diverse opinions, and encourage learning
The Staff Engineer journey has no "right answer." Each organization and person performs this role differently. What matters is expanding your influence in your own way while never losing the engineering essentials — technical excellence and curiosity.