• You break down tasks yourself before starting
• Your PRs rarely need architectural-level feedback anymore
• You handle edge cases proactively, not after code review comments
• You write tests without being asked
• You can debug production issues in your area without hand-holding

• Waiting for perfect specifications instead of clarifying ambiguity yourself
• Not reading enough production code written by senior engineers
• Avoiding unfamiliar parts of the codebase

• You write the design doc before you write the code
• You push back on requirements when they don’t make technical sense
• You proactively identify and address tech debt, not just complain about it
• Other engineers come to you with questions about your domain
• You can estimate work for your team, not just yourself
• You think about failure modes during design, not after the first outage

• Optimizing for code elegance over system reliability
• Not developing opinions about architecture (always deferring to others)
• Avoiding cross-functional conversations with PMs, designers, and stakeholders

• You have authored RFCs or design docs that were adopted across multiple teams
• You are pulled into architectural decisions outside your team
• You mentor senior engineers, not just juniors
• You identify systemic problems (tooling, patterns, processes) and fix them at the org level
• Leadership asks for your input on technical strategy
• You can articulate trade-offs to non-technical stakeholders

• Staying heads-down in code and never building organizational influence
• Not writing — design docs, RFCs, blog posts, postmortems
• Inability to communicate technical decisions to non-engineers
• Not building relationships outside your immediate team

• You define multi-year technical roadmaps that align with business goals
• Your decisions affect hundreds of engineers
• You identify existential technical risks before they become crises
• You shape hiring, team structure, and engineering culture
• Industry peers look to your work as a reference point
• You can translate between CTO-level strategy and individual team execution

• Thinking “principal” means “the best coder” — it means the best technical decision-maker
• Not understanding the business deeply enough
• Inability to influence without authority
• Not developing a point of view on where the industry is heading

• Functions do one thing and have descriptive names
• Error handling is explicit, not an afterthought
• Complex logic has comments explaining why, not what
• Tests document expected behavior, including edge cases
• You follow established patterns in the codebase (consistency over personal preference)

// Junior: clever but opaque
const r = d.filter(x => x.s > 2 && x.t !== 'b').map(x => ({...x, p: x.a * 0.15}));

// Senior: clear and maintainable
const activeNonBetaUsers = users.filter(user => {
  const isActive = user.sessionsThisMonth > MIN_ACTIVE_SESSIONS;
  const isNotBetaTester = user.accountType !== AccountType.BETA;
  return isActive && isNotBetaTester;
});

const usersWithDiscountApplied = activeNonBetaUsers.map(user => ({
  ...user,
  discountedPrice: user.annualPrice * LOYALTY_DISCOUNT_RATE,
}));

• You monitor your services proactively, not just when paged
• You write runbooks for on-call scenarios before they happen
• When you find a bug in another team’s service that affects yours, you fix it or file a detailed issue with a proposed solution — not just “it’s broken”
• You own the outcome of a project, not just your individual tasks
• You follow up after deployment to verify the feature works as expected in production

• Your code reviews teach, not just gatekeep — you explain why something should change
• You create shared utilities, templates, and tooling that the whole team uses
• You document tribal knowledge so it is not locked in your head
• You pair with struggling teammates instead of just solving it yourself
• You create a “paved road” for common patterns so others don’t reinvent the wheel

• You push back on features that add complexity without proportional value
• You choose boring technology for critical systems
• You can articulate: “We should use a third-party service for this because building it ourselves would take 3 months and maintaining it would take 0.5 FTE forever”
• You avoid premature optimization AND premature abstraction
• You know when a quick hack is the right call and when it is technical debt

1. What is the simplest thing that could work?
2. What are the maintenance costs over 2 years?
3. Who else will need to understand this?
4. What happens when this fails at 10x scale?
5. Is this reversible? If not, how much certainty do we need?

• Every feature you build has metrics and alerts before it ships
• You think about: What does graceful degradation look like?
• You design for zero-downtime deployments (feature flags, blue-green, canary)
• Your error messages are actionable, not just “something went wrong”
• You write postmortems that actually prevent recurrence, not just document the outage

• Can I roll this back in under 5 minutes?
• Do I have dashboards that will show me if this is broken?
• What happens to users if this feature fails?
• Have I tested this with production-like data volume?
• Is there a runbook for when this goes wrong at 3 AM?

• Your design docs have a clear problem statement, proposed solution, alternatives considered, and trade-offs
• You can run a productive technical discussion without it becoming a debate
• Your postmortems are blameless and focused on systemic improvements
• You give feedback that is specific, actionable, and kind
• You document decisions and their rationale so future engineers understand why

• Partners with a single team’s manager to set technical direction
• Drives execution on the team’s most important projects
• Day-to-day: code reviews, design docs, unblocking engineers, sprint planning
• Risk: becomes a bottleneck if they don’t delegate effectively

• Responsible for technical direction of a broad area (e.g., “frontend architecture” or “data platform”)
• Depth of knowledge in their domain, breadth of influence across teams
• Day-to-day: RFCs, reviewing designs from multiple teams, defining standards
• Risk: becomes disconnected from implementation reality

• Parachutes into the hardest technical problems across the org
• Moves from team to team as needed
• Day-to-day: deep technical work on the most ambiguous, high-stakes problems
• Risk: never builds lasting relationships or institutional knowledge

• Extends a senior leader (VP, CTO) by taking on their hardest problems
• Operates with borrowed authority
• Day-to-day: organizational strategy, cross-cutting initiatives, special projects
• Risk: impact is invisible and hard to attribute

• Write design docs that change how your org builds software
• An RFC adopted by 3+ teams is stronger signal than any amount of code
• Focus on: problem framing, trade-off analysis, alternatives considered
• Your RFCs should teach, not just propose

• Identify problems that affect multiple teams but nobody owns
• Examples: shared authentication, observability standards, CI/CD improvements, API design guidelines
• Lead the initiative without formal authority — this IS the staff skill

• Write the “state of the world” for your technical domain
• Include: where we are, where we need to be, how we get there, what we stop doing
• Present to engineering leadership and get buy-in

• Help senior engineers make the jump to staff
• This is a multiplier on a multiplier
• Share your frameworks for decision-making, not just your technical knowledge

Think of a brag document like a highlight reel. You don’t remember every shot you took, but you SHOULD remember the ones that mattered. Without a highlight reel, your entire season of work gets compressed into whatever your manager vaguely recalls from the last two weeks before review time. That is not a system for getting recognized — that is a lottery.

# Brag Document — [Your Name] — [Quarter/Year]

## Projects
- [Project Name]: [1-sentence description]
  - My role: [what you specifically did]
  - Impact: [quantified outcome]
  - Skills demonstrated: [technical, leadership, etc.]

## Design and Architecture
- [RFC/Design Doc Title]: [outcome — adopted? by how many teams?]
- Key decisions I drove: [list]

## Mentoring and Team Building
- Mentored [Name] on [Topic] — [outcome]
- Improved onboarding: [specific improvement and result]

## Operational Excellence
- On-call improvements: [what you changed, impact on MTTR/incident count]
- Reliability wins: [uptime improvements, toil reduction]

## Learning and Growth
- Learned [Technology/Skill] — applied in [Project]
- Conference talk / blog post / internal presentation: [title]

## What I Want to Do Next
- [Goals for next quarter]

1. Update it every Friday. Set a calendar reminder. If you wait until review time, you will forget 80% of your impact.
2. Quantify everything. “Improved performance” means nothing. “Reduced p99 latency from 800ms to 200ms, saving an estimated $50K/year in compute” means everything.
3. Include the work that was hard to do, even if it was invisible. This is your evidence.
4. Share it with your manager before review season. Don’t make them guess your impact.

• Tools that solve a real problem you personally had
• Projects with actual users (even 10 users is meaningful)
• Contributions to infrastructure, developer tooling, or open source
• Projects that demonstrate systems thinking, not just UI building
• Well-documented projects with clear READMEs, architecture docs, and deployment instructions

• A collection of tutorial follow-alongs (“I built a todo app in 15 frameworks”)
• Repos with no README, no tests, and no documentation
• Projects started but never finished (demonstrates nothing)
• Copy-paste from a YouTube course with no original modifications

1. Blog posts that teach — Explain something you learned. The bar is not “original research.” The bar is “clearly explaining something that others struggle with.”
2. Internal documentation — The engineer who writes the best internal docs is often the most valued on the team. Architecture decision records (ADRs), runbooks, onboarding guides.
3. Conference talks — Start with lightning talks (5 min) at local meetups. Work up to full talks. You do NOT need to be a world expert. You need to explain one thing well.
4. Postmortems — A well-written postmortem is one of the highest-leverage documents in engineering. It teaches the whole org.
5. Design docs and RFCs — These are the primary “currency” at staff+ levels. Practice writing them even if your org doesn’t require them.

1. Define your T-shape: Deep expertise in 1-2 areas. Broad familiarity with many. Decide what your “deep” areas are and protect that depth.
2. Weekly learning budget: Allocate 3-5 hours per week. Block it on your calendar. Protect it like a meeting.
3. Input sources (curate ruthlessly):
   • 2-3 newsletters (e.g., TLDR, Pointer, ByteByteGo)
   • 1 technical book per quarter (not per year)
   • Follow 10-15 high-signal engineers on social media
   • Read 1-2 RFCs/design docs from top companies per month
4. Output requirement: Learning without output is just entertainment. For everything you learn, produce something:
   • Write a summary in your own words
   • Build a small prototype
   • Teach it to a teammate
   • Add it to your notes system
5. Prune aggressively: Unsubscribe from noisy channels. Ignore hype cycles. Ask: “Will this matter to my work in 12 months?” If not, skip it.

• “What does your deployment pipeline look like? How often do you deploy to production?”
• “How do you handle incidents? Walk me through your last major outage.”
• “What’s the ratio of feature work to tech debt / infrastructure work?”
• “How are architectural decisions made? Who has input?”
• “What’s the oldest, most painful part of your codebase, and what’s the plan for it?”

• “How do code reviews work here? What’s the average turnaround time?”
• “What does on-call look like? How often are people paged, and how is it compensated?”
• “How does your team handle disagreements about technical direction?”
• “What did the last person in this role go on to do?”
• “Can you tell me about someone who was recently promoted and what they did to earn it?”

• “What does the career ladder look like for ICs here?”
• “How are engineers evaluated? What does the performance review process look like?”
• “What learning budget or professional development support exists?”
• “How much autonomy would I have in choosing what to work on?”

1. Never give a number first. “I’m focused on finding the right fit. What’s the range for this role at this level?” If pressed: “I’d want compensation to be competitive with the market for this level in this area.”
2. Negotiate total compensation, not just base salary.

3. Get competing offers. This is the single most effective negotiation tool. You don’t have to be aggressive. “I have an offer from [Company] at [Level]. I’d prefer to work here — can you match?”
4. Negotiate for level, not just comp. Starting at L5 vs L4 has compounding effects on your career trajectory. Fight for the right level.
5. Everything is negotiable. PTO, remote work, start date, relocation, learning budget, conference attendance. Ask.

• Interviewers are unprepared or late — shows they don’t value your time
• They can’t explain what the team is building or why it matters
• Nobody asks if you have questions — they’re not evaluating mutual fit
• High turnover they explain away as “culture fit” issues
• The tech stack is ancient AND there’s no migration plan
• “We wear many hats” means “you’ll do 3 jobs for 1 salary”
• They focus entirely on trick questions instead of real problem-solving

• Cannot explain past projects clearly — suggests limited ownership
• Badmouths previous employers or teammates
• No questions about the team, product, or engineering culture
• Cannot articulate what they want to learn or where they want to grow
• Over-indexes on compensation without curiosity about the actual work
• Claims credit for team achievements without acknowledging others

1. Start with the problem — why did this project matter? What was the cost of not doing it?
2. Explain how you identified the opportunity (did someone assign it, or did you see the gap yourself?)
3. Walk through how you built alignment — who did you need to convince, and how?
4. Describe the execution — what was your approach, what trade-offs did you make, what went wrong and how did you adapt?
5. End with measurable impact — revenue, reliability, developer productivity, user metrics, whatever is relevant
6. Briefly mention what you learned or what you would do differently

• Describing a project you contributed to but did not drive — interviewers will probe and the distinction becomes obvious
• Focusing entirely on the technical implementation without explaining the business context or stakeholder management
• Not quantifying the impact — “it was really successful” is not an answer
• Skipping the obstacles — the interesting part is how you navigated problems, not that everything went smoothly

1. Show that you know what glue work is and why it matters — reference the concept directly
2. Explain your approach to making invisible work visible: tracking it, quantifying it, framing it as organizational impact
3. Describe how you would have the conversation with your manager — proactively, not resentfully
4. Discuss distribution — how you would create systems so the glue work does not depend entirely on you
5. Acknowledge the balance — you still need visible technical contributions alongside organizational work
6. Show judgment about when to push back — if an organization consistently refuses to value this work, that is signal about the org, not about you

• Saying “I’d just stop doing it” — this is immature and shows you do not understand organizational needs
• Being resentful or passive-aggressive about it — the interviewer wants to see mature problem-solving
• Not knowing what “glue work” is — if this question catches you off guard, you have not thought about career management deeply enough
• Pretending it has never happened to you — it happens to almost everyone at some point

1. Acknowledge the fork — show you know there are two paths and you have thought about which one fits you
2. Be specific about the type of impact you want to have, not just the title you want to hold
3. Connect your answer to this role — explain why this position is a logical step toward your goals
4. Show depth over breadth — “I want to go deep on distributed systems and be the person my org trusts with our hardest scaling challenges” is better than “I want to be a tech lead”
5. Be honest about what you are still figuring out — “I’m leaning toward the IC track but I want to try leading a small project team first to test that assumption” shows maturity

• “I want to be a manager” without explaining why or what kind of manager — sounds like you just want a title
• “I just want to keep coding” — sounds like you have not thought about growth
• Being so vague that it could apply to any role at any company — “I want to grow and learn” says nothing
• Giving an answer that this company obviously cannot support — if it is a 20-person startup, do not say “I want to lead an organization of 200 engineers”

1. Written communication — design docs, emails, Slack messages, documentation
2. Verbal communication — presenting ideas, running meetings, explaining trade-offs
3. Giving and receiving feedback — code reviews, performance conversations
4. Stakeholder management — working with PMs, designers, leadership
5. Conflict resolution — technical disagreements, priority conflicts
6. Teaching and mentoring — making others better

• You don’t see the 70-hour weeks, the failed projects, the lucky timing, or the privilege that enabled their path
• Career trajectories are not linear — many successful engineers had “slow” periods that were actually foundational
• “Staff at 28” at a startup that folds means nothing. “Senior at 35” at a company building meaningful technology means a lot.

1. What are the 2-3 things I’m best at technically?
2. What kind of problems do I enjoy solving most?
3. Where do I want to be in 3 years — and what specific skills gap stands between here and there?
4. Who do I admire in my field, and what specifically about their career path appeals to me?
5. What am I avoiding that I know would accelerate my growth?

1. What was the measurable impact? (If you can’t measure it, figure out how)
2. Who benefited besides you? (Your team? Other teams? Users? The company?)
3. What did you learn that you didn’t know before?
4. What would you do differently if you did it again?

1. Current level and target level
2. 3-5 projects demonstrating target-level scope and impact
3. Evidence of influence beyond your immediate team
4. Evidence of mentoring or multiplier effects
5. Areas of growth and how you’ve addressed them

1. What are you actually trying to learn?
2. What would a great answer sound like?
3. What would a red-flag answer sound like?

• Must include a concrete example or code sample
• Must explain WHY, not just HOW
• Must be understandable without specialized knowledge of your specific codebase

• “An Elegant Puzzle” by Will Larson — The best book on engineering management and organizational design. Even if you are on the IC track, understanding how engineering orgs work gives you an unfair advantage in navigating your career. Larson writes from deep experience at Digg, Uber, and Stripe.
• “Staff Engineer” by Will Larson — The companion to An Elegant Puzzle, focused specifically on the staff+ IC track. Includes detailed interviews with staff engineers about what they actually do day-to-day. Essential reading if you are targeting senior or staff level.
• “The Staff Engineer’s Path” by Tanya Reilly (O’Reilly, 2022) — The definitive guide to operating as a staff+ IC. Covers the three pillars (big-picture thinking, execution, and leveling up) with practical frameworks drawn from Reilly’s experience at Google and Squarespace. More tactical and actionable than Larson’s book — the two complement each other well.

• StaffEng.com — A collection of stories from staff+ engineers across the industry, organized by the four archetypes (Tech Lead, Architect, Solver, Right Hand). Read 5-10 of these stories and you will develop a much clearer picture of what staff-level work looks like in practice. Also includes guides on getting the title, operating at the level, and building a promotion packet.
• Julia Evans’ blog (jvns.ca) — Julia Evans writes about learning, debugging, and demystifying technical topics with infectious enthusiasm and clarity. Her posts on “how to ask good questions,” “things that surprised me about management,” and her zine series on systems concepts are career-growth gold. Her approach to learning in public is a model worth emulating.
• Levels.fyi — Crowdsourced compensation data across tech companies, broken down by level, location, and company. Essential for understanding where you stand in the market and for negotiation preparation. Also useful for understanding how different companies map their leveling systems.

• The Pragmatic Engineer by Gergely Orosz — The best newsletter for understanding how the tech industry actually works. Orosz covers compensation, engineering culture, industry trends, and career strategy with insider knowledge from his years at Uber and Microsoft. The free tier is valuable; the paid tier is one of the few subscriptions worth paying for as a career investment.
• “Don’t Call Yourself a Programmer” by Patrick McKenzie (patio11) — A foundational essay on how the software industry actually works, written over a decade ago but still deeply relevant. McKenzie’s core argument: companies do not hire engineers to write code, they hire engineers to increase revenue or reduce costs. Understanding this reframes every career decision you make. Read this early in your career and revisit it annually.
• Charity Majors on the IC-to-management journey — Majors has written extensively on her blog and on social media about the transition between IC and management roles. Her core insight — that management is a career change, not a promotion — is one of the most important reframes in engineering career thinking. Search for her posts on “the engineer/manager pendulum” for the key pieces.

• Tanya Reilly’s “Being Glue” talk — Available on YouTube and as a written blog post. If you have ever felt like your important contributions are invisible, this talk will validate your experience and give you a framework for addressing it. Required viewing for anyone on the IC track and for every engineering manager.
• The career advice compendium from senior engineers — There is no single URL, but searching for career advice threads from staff+ engineers on platforms like HackerNews, the StaffEng blog, and engineering blogs from companies like Dropbox, Stripe, and Netflix will surface patterns. The consistent themes: write more, build relationships deliberately, own outcomes not just tasks, and make your impact measurable.