• 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

Cross-chapter connections: The senior-to-staff transition depends heavily on skills covered in other chapters. See Communication & Soft Skills for frameworks on presenting technical decisions to non-engineers and running effective design reviews. See Leadership, Execution & Infrastructure for the staff+ skills around influence without authority and driving cross-team initiatives.

• 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

For a deep dive into the specific communication frameworks that senior engineers use — including how to write design docs, run blameless postmortems, and present technical trade-offs to executives — see the Communication & Soft Skills chapter.

• 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

1. Your self-assessment: Where do you honestly sit on the level expectations? Which dimensions are you strong in, which are gaps? Be specific — “I’m strong at system design within my team but I haven’t demonstrated cross-team architectural influence yet.”
2. Your impact summary: Bring your brag document. Highlight 3-5 items from the last quarter that demonstrate the level you are operating at (or aspiring to). Use the impact story formula — problem, action, measurable result.
3. Your growth hypothesis: “I believe the gap between where I am and where I want to be is [specific skill or scope]. Here is my plan to close it: [concrete actions].”
4. Your asks: What do you need from your manager? Specific project assignments? Introductions to engineers on other teams? Air cover to take on a cross-team initiative? Feedback on a specific dimension?

1. Send a written summary within 24 hours. “Here’s what we discussed, here’s what I committed to, here’s what I’m asking from you.” This creates a paper trail and ensures alignment.
2. Update your brag document with the agreed-upon focus areas.
3. Set calendar reminders for the monthly check-ins.
4. Track progress against the specific gaps identified. When you make progress on a gap, document it with evidence.

• Ask for examples: “Can you point to someone who recently got promoted to [target level]? What did their impact look like?”
• Ask for specificity: “You mentioned I need more visibility. Can you give me an example of what that would look like concretely?”
• Seek other sponsors: Talk to skip-level managers, staff+ engineers, or mentors outside your team. Your manager is not the only person who can help you grow.
• If all else fails, this is signal about whether this organization can support your growth.

Cross-chapter connection: Career conversations are high-stakes communication moments. The frameworks in Communication & Soft Skills — especially the sections on giving and receiving feedback, framing technical decisions for non-technical audiences, and navigating difficult conversations — apply directly here.

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.
5. Frame every item as a story, not an activity. Not “I built X” but “I built X, which resulted in Y, saving/generating Z.” The impact story formula (covered in the next section) is the difference between a list of tasks and a compelling promotion case.

I noticed [PROBLEM] affecting [WHO/WHAT].
I proposed [SOLUTION] and got buy-in from [STAKEHOLDERS].
I led [SCOPE — team size, timeline, complexity].
The result was [MEASURABLE OUTCOME — revenue, cost savings, time saved, reliability improvement].
The second-order effect was [BROADER IMPACT — team velocity, engineering culture, customer satisfaction].

For a deeper dive into how to communicate your impact in design reviews, postmortems, and stakeholder meetings, see the Communication & Soft Skills chapter. The frameworks there pair directly with the impact storytelling approach here.

• 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.

Learning is the input. Your personal brand is the output. For strategies on turning your learning into visible career assets — blog posts, conference talks, and open-source contributions — see “Building Your Personal Brand as an Engineer” later in this chapter.

• Check their engineering blog (most mid-to-large companies have one). Search “[Company Name] engineering blog.”
• Look at their open-source repos on GitHub. What languages? What frameworks? What problems are they solving publicly?
• Check job postings for the team you are interviewing with — the required skills tell you what they use.
• Look at StackShare or BuiltWith for their technology profile.

• Find 2-3 recent posts relevant to the role. Read them carefully.
• This gives you ammunition for the interview: “I read your blog post about migrating to Kubernetes and I would love to discuss how you handled state management for the stateful services during that transition.” This single sentence signals more preparation and genuine interest than anything else you could say.
• Note any technical challenges they mention — these might be problems you would be working on.

• Read the engineering-specific reviews. Look for patterns, not individual complaints.
• Pay attention to: management quality, work-life balance, promotion velocity, on-call burden, tech debt attitudes.
• Prepare questions that probe the patterns you see — but do NOT say “I read on Glassdoor that…” Instead, ask open-ended questions that let interviewers confirm or deny the patterns organically.

• How does the company make money? Who are their customers? What is their competitive position?
• What has been in the news about them recently? Funding rounds, product launches, layoffs, acquisitions?
• Engineers who understand the business context of their work get promoted faster — and interviewers notice when you connect technical decisions to business outcomes.

• From your research, prepare 2-3 specific things you can reference during the interview:
  • “I noticed your team open-sourced [tool] — I’ve been using it and I’m curious about the design decision to [specific detail].”
  • “Your recent blog post about [topic] resonated with me because at my current company, we faced a similar challenge with [specific parallel].”
  • “I saw that your team is working on [initiative from job posting or blog]. I have experience with [relevant skill] and I’d be excited to contribute to that.”

• “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.

• You do not need to lie or bluff. Apply to multiple companies simultaneously and time your processes to align. Having two or more offers at the same time is the single most powerful negotiation lever.
• Be transparent but strategic: “I have an offer from [Company] at [Level] with total comp of [Range]. I prefer your team and mission, but I need the compensation to be competitive.” This is not adversarial — recruiters expect it.
• If you only have one offer, you can still reference market data: “Based on Levels.fyi data and conversations with peers, the market range for this level in this location is [X-Y]. I’d like to be in the upper half of that range.”

• A 20-40% higher total compensation band
• Larger equity grants and refresh rates
• More scope and autonomy from day one
• A head start on your next promotion cycle

1. Pause. Do not react. Say: “Thank you for sharing this. I appreciate the offer.”
2. Buy time. “I’d like to take a couple of days to review the full details.”
3. Counter with reasoning, not just a number. “After reviewing the offer and considering [my competing offer / market data / the level discussion], I’d like to discuss adjusting the [base / equity / level]. Here is why…”
4. Be willing to walk away. This is the hardest part and the most powerful. If you cannot walk away, you cannot negotiate. Always have a BATNA (Best Alternative To a Negotiated Agreement).

Cross-chapter connection: Negotiation is only one piece of the offer process. For strategies on managing multiple interview timelines, handling exploding offers, and the psychology of decision-making under pressure, see the Interview Meta-Skills chapter. For evaluating whether a company’s values and practices will actually match what they promised during the interview, see the Ethical Engineering chapter’s sections on organizational culture assessment.

• 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

Cross-chapter connections: For a comprehensive framework on spotting and reasoning about ethical red flags during company evaluation — beyond the technical and cultural signals above — see Ethical Engineering. For interview-day strategies on how to probe these red flags effectively without being adversarial, see Interview Meta-Skills.

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. Write detailed PR descriptions — Not just “fixes bug.” Instead: “This fixes the race condition in the payment queue that caused 3 duplicate charges last week. Root cause was X, fix approach was Y, I considered Z but chose Y because [trade-off reasoning].” Every PR description is a micro-advertisement for your engineering judgment.
2. Send weekly impact summaries — Every Friday, send your manager a 3-5 bullet update. Not what you did (activity), but what impact it had (outcome). “Reduced p95 query latency by 40ms by adding a covering index to the orders table” beats “worked on database optimization.” This takes 10 minutes and is the single highest-ROI visibility habit for remote engineers.
3. Be the person who writes things down — After every meeting, post a summary in the team channel: decisions made, action items, owners, deadlines. The person who documents becomes the person who shapes the narrative. This is especially powerful because most people hate doing it.
4. Demo your work — Volunteer to demo completed features in team meetings. A 3-minute live demo creates more visibility than a week of Slack messages. Record demos for async consumption when timezone differences make synchronous attendance impractical.
5. Share learnings publicly — When you debug a tricky issue, write a short post in your team’s knowledge base or Slack channel. “TIL: Our Kafka consumer was silently dropping messages when the payload exceeded 1MB because of [config]. Here’s how I found it and how I fixed it.” This builds your reputation as someone who makes the team smarter.

1. Write for someone reading it 8 hours later — Provide full context. Instead of “Can we talk about the auth issue?”, write “The auth service is returning 401s for 2% of requests since the deploy at 3pm UTC. I’ve traced it to the token refresh logic — the new code expects a refresh_token field that legacy clients don’t send. I see three options: (a) add a fallback path, (b) force-upgrade legacy clients, (c) roll back. I recommend (a) because [reasoning]. Thoughts?”
2. Batch your communication — Do not send 12 Slack messages in a row. Collect your thoughts, write a single coherent message. Threaded, structured, with headers if it is long. Respect other people’s focus time by making your messages complete and self-contained.
3. Use the right medium for the right message:
   • Slack/Chat: Quick questions, status updates, social interaction
   • Document/RFC: Anything requiring input from multiple people or lasting more than a day
   • Video (recorded): Complex explanations, demos, design walkthroughs
   • Meeting (synchronous): Decisions requiring real-time debate, sensitive conversations, relationship building
4. Set expectations about response times — “I’ll review this by EOD Tuesday” is better than silence. Acknowledging a message even when you cannot respond fully builds trust across timezones.
5. Over-communicate context in code reviews — Remote code reviews lack the ability to walk over and discuss. Write detailed review comments. When suggesting a change, explain the reasoning. When approving, say what you checked and what you liked. “LGTM” is lazy in any context; remotely, it is almost hostile.

Cross-chapter connection: The async communication principles here are the remote-specific application of the broader communication frameworks in Communication & Soft Skills. The design doc structure, feedback frameworks, and stakeholder communication techniques in that chapter all apply — they just need to be adapted for async delivery.

1. Schedule intentional 1:1s with people outside your team — 30 minutes, biweekly, with engineers on adjacent teams, your skip-level manager, engineers whose work you admire. The agenda is simple: “What are you working on? What’s challenging? How does your team think about [shared concern]?” These conversations build the cross-organizational network that is essential for staff+ visibility.
2. Be generous in public channels — Answer questions in shared Slack channels, even when they are not about your area. Help debug issues. Share relevant articles. The goal is to become known as someone who is helpful and knowledgeable beyond their immediate team.
3. Create virtual “watercooler” moments — Join optional social channels. Participate in team rituals (show-and-tell, Friday demos, book clubs). Share something personal occasionally. Remote relationships require more deliberate effort, but they are not less real.
4. Pair program across timezone boundaries — Even 30-60 minutes of pairing per week builds stronger relationships than months of async-only interaction. You learn someone’s thinking style, build trust, and often solve problems faster.
5. Travel for high-leverage moments — If your company has offsites or optional in-person gatherings, attend them. The ROI of spending 3 days in person with your team is enormous. Prioritize relationship-building over agenda items during in-person time — the documents can be written async, the trust cannot.
6. Proactively share your working style — Create a personal “working with me” document: your timezone, preferred communication channels, when you are most responsive, how you prefer to receive feedback, what energizes or drains you. Share it with your team. This transparency reduces friction in a way that is uniquely valuable in remote settings.

1. A profile README — Create a repository with the same name as your GitHub username and add a README.md. This becomes your profile page. Include: a one-sentence bio, your areas of expertise, 2-3 pinned projects with brief descriptions, and links to your blog or talks. Keep it concise and professional — this is not a MySpace page.
2. Pin your best 6 repositories — Choose projects that demonstrate the skills you want to be known for. A hiring manager for a backend role does not care about your React todo app. Pin: projects with real users, open-source contributions, tools that solve real problems, and well-documented codebases.
3. Write real READMEs — Every pinned project should have a README that includes: what the project does and why it exists, how to set it up locally, architecture overview (even a brief one), screenshots or demo links if applicable, and what technical decisions you made and why. A well-written README is more impressive than the code itself because it demonstrates communication skills.
4. Maintain a contribution streak (but don’t game it) — Consistent green squares signal active engagement with code. But do not game this by making trivial commits — experienced engineers can tell. Genuine contributions — code, documentation, reviews — count.
5. Contribute to projects you actually use — A PR to a well-known open-source project is worth more than 10 personal repos. Even documentation fixes or bug reports demonstrate that you operate in the broader engineering ecosystem.

• Do not pin tutorial follow-alongs (every bootcamp grad has the same ones)
• Do not have dozens of repos with a single commit
• Do not neglect issues and PRs in your own repos (if someone opens an issue, respond)
• Do not use auto-generated profile readmes with flashy badges and no substance

1. Headline — Not just your title. Include what you do and what you care about. “Senior Backend Engineer | Distributed Systems | Building reliable data pipelines at scale” tells a recruiter exactly what roles to send you. “Software Engineer at Company” tells them nothing.
2. About section — Write 3-4 sentences in first person about what you do, what you are good at, and what kind of work excites you. Include specific technologies and domains. This is SEO for recruiters — they search by keywords.
3. Experience descriptions — Do not list responsibilities. List impact. Use the impact story formula: “Led the migration of 200+ microservices from ECS to Kubernetes, reducing deployment time by 60% and infrastructure costs by $400K/year.” Numbers. Impact. Outcomes.
4. Featured section — Pin your best blog posts, talks, or open-source projects. This is prime real estate that most engineers leave empty.
5. Skills and endorsements — Add skills that reflect your target role, not just your current one. If you want to move into ML engineering, add those skills even if your current title is “Backend Engineer.”
6. Engage minimally but consistently — Share one post per month: a learning, a project update, a thoughtful comment on an industry trend. You do not need to become a LinkedIn influencer. You need to be visible enough that your profile appears active.

1. Lightning talks (5 minutes) — Find a local meetup and volunteer for a lightning talk slot. Five minutes is low-risk and forces you to be concise. Topics that work well: “A bug that taught me something,” “One thing I wish I knew about [technology],” “How we solved [specific problem].”
2. Internal tech talks (15-30 minutes) — Most companies have internal presentation slots (brown bags, tech talks, show-and-tell). Present to your colleagues first. The stakes are low, the feedback is immediate, and the practice is invaluable.
3. Regional conferences — Once you have 2-3 internal talks under your belt, submit to a regional conference CFP (Call for Papers). Target conferences with 200-500 attendees. Acceptance rates are higher than you think, especially for talks with concrete, specific topics (“How We Reduced Our P99 Latency by 80%”) rather than abstract ones (“Thoughts on Microservices”).
4. Major conferences — After regional experience, aim for larger venues. Your talk proposal should include: a specific, outcome-oriented title, a clear description of what attendees will learn, your credibility to speak on this topic, and why this talk is timely.

• The hook (2 minutes) — A specific problem or story that grabs attention
• Context (3 minutes) — What the audience needs to understand before the solution
• The journey (15-20 minutes) — What you tried, what failed, what worked, and why
• Key takeaways (3 minutes) — The 3-5 things the audience should remember
• Q&A (5 minutes) — Where the real learning often happens

Cross-chapter connection: The communication frameworks in Communication & Soft Skills — especially the sections on presenting to different audiences and structuring technical arguments — apply directly to conference talks. A conference talk is essentially a design review presented to a larger audience.

• Something you just learned that was harder to find than it should have been
• A debugging journey — the problem, what you tried, what failed, what worked
• A comparison of two approaches with concrete trade-offs (not “X vs Y” hot takes, but “Here’s when X wins and here’s when Y wins and here’s how to decide”)
• An internal tool or process your team built and why
• A conference talk summary with your own commentary

• Personal blog (using a static site generator like Hugo, Gatsby, or Astro) — Maximum control, builds your personal domain authority
• Dev.to or Hashnode — Built-in audience, lower setup friction, good for early posts
• Company engineering blog — If your company has one, contribute. It carries the company’s brand weight and demonstrates internal leadership

• Request a transfer to a different team with harder problems
• Propose a stretch project that requires skills you want to develop
• Ask for sponsorship to lead a cross-team initiative
• Set a personal learning goal with a 3-month deadline: if the org cannot support it, that is your answer

• The company ships features you believe are harmful to users and dismisses concerns when raised
• Leadership says one thing publicly and does another internally
• Ethical shortcuts are normalized (“just ship it, we’ll fix the privacy issues later”)
• You find yourself defending the company’s decisions to friends in ways that feel dishonest
• The company’s business model fundamentally conflicts with your values (and this was not clear when you joined)

Cross-chapter connection: The Ethical Engineering chapter covers the frameworks for reasoning about ethical decisions in engineering — when to push back, how to escalate, and when walking away is the right call. If you are feeling values misalignment, read that chapter’s section on ethical career decisions before making a move.

• Raise your concerns explicitly with your manager or skip-level
• Find allies who share your concerns — collective voice is more powerful
• Document specific instances where values were violated (for your own records, not as a threat)
• Give the organization a reasonable window to change (3-6 months)

• Check Levels.fyi for your level, location, and company type
• Talk to peers at other companies (engineers are surprisingly open about comp in private)
• If you have been at the same company for 3+ years without a significant adjustment, you are almost certainly below market — internal raises rarely keep pace with market movement

• You have been told “we don’t have budget” for two consecutive cycles
• New hires at your level are being offered significantly more than you earn (inversion)
• The company’s equity has declined significantly and there is no adjustment to base compensation
• Cost-of-living adjustments are below actual inflation

• Have a direct conversation with your manager using market data: “Based on Levels.fyi data and conversations with peers, I believe my current comp of [X] is below market for my level. I’d like to discuss an adjustment to [Y range].”
• If your manager is supportive but says they need approval, set a deadline: “I understand this needs to go through channels. Can we have an answer by [date]?”
• Get a competing offer. This is the nuclear option but it works because it provides concrete proof of your market value. Only do this if you are genuinely willing to leave.

• Talk to your skip-level manager (sometimes the toxicity is one manager, not the org)
• Transfer to a different team (culture varies significantly between teams, even at the same company)
• Use anonymous feedback channels if they exist
• Set a personal deadline: “If X does not change by [date], I will start interviewing”

• You are being asked to do something illegal or deeply unethical
• Your mental health is seriously affected (sustained anxiety, depression, sleep disruption)
• You have experienced or witnessed harassment that HR has failed to address
• You have retaliation concerns for having raised legitimate issues

• Nobody at your target level exists on the IC track at this company (if you want to be staff, but the highest IC is senior, the path does not exist)
• Promotions require “hero moments” rather than sustained impact
• Your manager does not understand your target level or cannot articulate what you need to do to get there
• The company is too small to offer the scope you need (you cannot do staff-level cross-team work at a 15-person startup with 3 engineers)
• You have been told to wait for a specific project or reorg that keeps getting delayed

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.

1. Severity times frequency. A problem that causes a minor annoyance once a month is different from one that blocks a deployment pipeline three times a week. I start by quantifying the actual cost — in engineer-hours, customer impact, or revenue. At my last company, I noticed our test suite was flaky, failing about 8% of runs. Gut instinct said “fix it.” But when I measured the actual cost — roughly 2 hours of wasted CI time per week across the team — it was a medium-priority issue, not the urgent crisis it felt like during a frustrating retry.
2. Trajectory. Is this problem getting worse, staying stable, or naturally resolving? A database that is 60% full and growing 5% per month is a very different problem from one that is 60% full and stable. I always ask: “If we do nothing for 6 months, what does this look like?” The problems worth solving are the ones that compound.
3. Opportunity cost. What am I NOT doing if I work on this? The hardest part of senior engineering is not solving problems — it is choosing which ones to solve. I maintain a rough mental ranking of the 3-5 highest-leverage things I could be doing, and I evaluate new problems against that list. If fixing flaky tests means delaying a data pipeline migration that three teams are blocked on, the tests wait.

• When a project succeeds, what gives you more satisfaction — the elegant architecture, or watching a team member you coached deliver something they could not have done before?
• Would you rather spend an afternoon debugging a complex distributed system issue or helping an engineer navigate a career crisis?
• When there is a conflict between two engineers about a technical approach, do you want to resolve it by analyzing the options and deciding (IC), or by coaching them to resolve it themselves (management)?
• Are you drawn to management because you want to have impact through people, or because you think it is the only path to seniority and higher compensation?

• Business context. Where is the company headed? What are the revenue goals, the product roadmap priorities, and the competitive pressures? I schedule 30-minute conversations with the product lead, the engineering director, and ideally a business stakeholder. The technical strategy must serve the business strategy, not exist in isolation.
• Current state assessment. What is the honest state of our systems? I review incident data, deployment metrics, developer satisfaction surveys (if they exist), and the top pain points from the last three retrospectives. I also assess the team’s skills inventory — what can we do well and where are we weak?
• Team input. I run a lightweight exercise with the engineers: “What are the three things that slow you down the most, and what are the three things you think we should invest in?” This surfaces ground-level reality that leadership often misses.

1. Executive summary (half a page) — What we are investing in, what we are not, and what business outcomes this enables
2. Current state (1-2 pages) — Honest assessment of where we are, with data
3. Strategic priorities (2-3 pages) — Each theme with problem statement, proposed direction, investment estimate, and success metrics
4. What we are explicitly NOT doing (half a page) — And why. This section builds credibility
5. Risks and dependencies (half a page)
6. Timeline — Rough quarterly milestones, not a detailed project plan

1. I protect recovery time like I protect production uptime. I do not work weekends except for genuine incidents. I take every day of PTO I am allocated. I do not check Slack after 7 PM. These are not casual preferences — they are commitments I treat with the same seriousness as a deployment checklist. When a manager pushed back on my boundaries during a crunch period, I said: “I will deliver exceptional work during working hours. If the project cannot be done within those constraints, we have a scoping problem, not an effort problem.”
2. I manage energy, not just time. Some tasks give me energy (system design, mentoring, debugging hard problems), and some drain me (long meetings, organizational politics, repetitive operational work). I deliberately structure my week so that draining activities are followed by energizing ones. I never stack five meetings in a row if I can help it.
3. I have an explicit “shutdown ritual.” At the end of each workday, I write down where I left off and what I will start with tomorrow. This clears the mental cache and prevents the “lying in bed thinking about work” problem. It is a small habit that has an outsized effect on my ability to actually rest.
4. I watch for early warning signals. The first sign of burnout for me is not exhaustion — it is irritability. When I start feeling resentful about code reviews, annoyed by reasonable questions, or cynical about projects, I know I am approaching my limit. I have learned to treat these emotional signals as seriously as I would treat a monitoring alert.

1. Timeline — Minute-by-minute, no opinions, just facts. “14:03 UTC: deploy of commit abc123 began. 14:07: error rate exceeded 5% threshold. 14:09: PagerDuty alert fired.”
2. Five Whys — But I stop when I hit a systemic cause, not a human one. “The engineer deployed without checking the dashboard” is NOT a root cause. “Our deployment pipeline does not have automated health checks that block rollout on error rate spikes” IS a root cause.
3. Action items with owners, deadlines, and verification criteria. Not “improve monitoring” but “Add a Datadog monitor on payment-service error rate > 2% sustained for 3 minutes, alert to #payments-oncall, owner: @jane, deadline: 2024-03-15, verified when: alert fires correctly in staging load test.” Every action item must have a name, a date, and a definition of done. I track these in Linear and review them weekly until complete.

1. A quarterly developer satisfaction survey — 5 questions, takes 2 minutes. “On a scale of 1-5, how would you rate the deployment experience?” We tracked NPS across quarters. Starting score: 2.1 out of 5. After two quarters of focused improvement: 3.8.
2. Office hours — We held 30 minutes of open office hours every Thursday. Any product engineer could show up with questions, complaints, or feature requests. The first session, two people came. By month three, we had 8-10 regulars. More importantly, we caught usability issues weeks earlier than we would have through formal bug reports.
3. “Eat your own cooking” policy — Every platform engineer had to deploy a production service using our own tools once per sprint. Not their platform service — a product service, using the same workflow product engineers use. The bugs we found by being our own users were embarrassing. One of our engineers discovered that our retry logic silently swallowed errors if the auth token expired mid-deploy — an issue that had been reported three times by product teams and marked “cannot reproduce” because it only happened with long-running deploys.

1. Deploy contention. Multiple teams are regularly blocked waiting to deploy because another team’s changes are in the pipeline. If your deploy frequency is declining and the bottleneck is coordination (not test failures or pipeline speed), that is a real decomposition signal.
2. Blast radius problems. A bug in one module causes an outage in an unrelated module because they share a process or a database connection pool. If you are regularly experiencing incidents where the root cause is “module A affected module B through shared resource C,” your modules need process-level isolation.
3. Team ownership boundaries are clear. If you have distinct teams that own distinct business domains and they are stepping on each other’s code, a service boundary might help. But if the same 4 engineers work on everything, splitting into services just means 4 engineers now have to context-switch across 4 repos instead of navigating one.

• What systems does this new team own? (List them explicitly — ambiguity about ownership is poison)
• What are the active projects and their status? (In progress, paused, cancelled, unknown)
• Who is the on-call contact for each system? (Even if it is temporary)
• What decisions are pending that need a decision-maker?

1. My personal fix: I added a personal checklist for migration reviews that includes “check for null/default values in affected columns using a read-replica query.” I shared this checklist with the team.
2. Team process fix: We added a required section to migration PRs: “Production data impact analysis” where the author must include a query result showing the data distribution for affected columns.
3. Tooling fix: We built a CI step that runs migrations against an anonymized production data snapshot. This catches the “works in staging, fails in production” class of bugs automatically. It took one week to build and has prevented 4 similar issues since.

• Migrations, security-sensitive code, and public API changes: I review with maximum depth. I block time for these. I run queries against staging data. This might take 1-2 hours for a complex migration. The team knows these PRs will take longer, and they plan accordingly.
• Feature code in well-tested areas: I review for design, readability, and test coverage. I trust the CI pipeline to catch correctness issues. I aim for 30-minute turnaround. If I have more than 3 comments, I suggest a pairing session instead of async back-and-forth.
• Documentation, config changes, dependency updates: I skim for obvious issues and approve quickly. These do not need deep review, and slow-rolling them is pure waste.

• Security vulnerability: What is the CVSS score? Is it actively being exploited, or theoretical? Is it in a public-facing service or an internal tool? Is customer data at risk? A CVSS 9.1 RCE in a public API with known exploits in the wild is a “drop everything” situation. A CVSS 4.0 information disclosure in an admin tool used by 3 people can wait a sprint.
• SLO breach: How far below SLO are we? Is it getting worse or stable? What is the customer impact? If we are at 99.5% against a 99.9% SLO and trending down, that is urgent — we are consuming error budget at an unsustainable rate. If we dipped to 99.85% due to a one-time incident that has been resolved and we are recovering, it can wait.
• Feature request: What is the revenue or retention impact? Is there a contractual deadline? Is a customer churning without it? “Would be nice to have” is very different from “our largest customer’s renewal depends on this being live by end of month.”

• “What if the feedback is ‘you are a strong IC but not a leader’ — how is that different to address?” - Strong answer: That is code for “you have not influenced people outside your direct team.” The fix is not to become more charismatic but to produce written artifacts (RFCs, strategy docs, post-mortems) that other teams reference when making decisions — influence scales through writing, not through meetings.
• “How long should you stay stuck before job-hopping becomes the right move?” - Strong answer: My rule is two full promo cycles with concrete, documented feedback and a credible path forward. If after cycle two the feedback has shifted or the ‘path forward’ has not materialized, the company is signaling — intentionally or not — that they will not promote you. Staying a third cycle is optimism punishing your career.
• “Is it ever right to threaten to leave to force a promotion?” - Strong answer: Only if you have a real offer and are genuinely prepared to take it. Fake leverage is the fastest way to permanently damage the relationship with your manager, and companies increasingly track ‘counter-offer’ promotions and penalize them at the next cycle.

• “I would just work harder and take on more projects.” - This is the trap. Volume of work does not produce staff-level impact; one well-chosen project does. More projects often means more glue work that stays invisible.
• “I would ask my manager what I need to do differently.” - You have done this for two years and it has not worked. Asking the same person the same question expecting different information is not diagnosis; it is avoidance of the harder conversation with peers or a job search.

• “The Staff Engineer’s Path” by Tanya Reilly (O’Reilly, 2022) — especially the chapter on scope and the “big three” staff archetypes
• Will Larson’s StaffEng.com interviews — patterns across engineers who made staff at Stripe, Slack, Google
• Related chapter: Communication and Soft Skills on writing RFCs that influence across teams

• “How do you convince a hiring manager you will not ‘stealth manage’ on an IC team — telling everyone what to do?” - Strong answer: I commit explicitly to the team norms: I do not run standup, I do not run 1:1s with teammates, I bring decisions to the manager and tech lead rather than making them unilaterally. I also say it out loud in my first week: “I used to manage, I am here to IC, please call me out if I slip into manager-mode.”
• “What if the only IC role available is a Senior role, but you want Staff?” - Strong answer: I would not make the jump for a Senior role if I was managing team scope. Better to stay managing while I interview at companies that have open Staff IC roles, and time the move to a title that reflects my actual scope. Accepting a Senior role ‘to rebuild my coding’ almost always locks you into that level for 2+ years.
• “How do you handle the pay conversation — managers usually earn more than ICs at the same level?” - Strong answer: I negotiate based on total comp and market data for Staff IC, not on my previous manager base. At most tech companies, Staff IC and Senior Manager are paid equivalently on the compensation bands; if a company cannot match that, it tells me their IC track is not actually respected.

• “I would just take any IC role to get back to coding.” - This undervalues your management experience and locks you into a level below your actual seniority. You will spend 2 years climbing back to where you were.
• “I would not tell new employers I used to manage.” - Hiding it backfires when it comes up in reference checks, and it wastes the single biggest differentiator you have over other senior IC candidates.

• Charity Majors, “Engineering Management: The Pendulum or the Ladder” (2017 blog post)
• “The Manager’s Path” by Camille Fournier — the chapter on whether to manage is equally useful in reverse
• Related chapter: Leadership, Execution, and Infrastructure on leading without authority, which maps directly to Staff IC expectations

• “How do you decide which glue work to stop doing when saying no will make the team temporarily worse off?” - Strong answer: I pick the piece that has the highest ‘cost to me’ and ‘lowest switching cost to the team.’ If dropping it for one sprint would cause a critical failure, I keep doing it while I build the documentation or tool that replaces me. If dropping it for one sprint just means someone else is inconvenienced, I drop it now — the short-term pain trains the team to distribute the load.
• “Isn’t refusing glue work just offloading it onto others, often women and underrepresented folks who feel more pressure to take it?” - Strong answer: Yes, and that is why the solution is not ‘refuse glue work’ but ‘make the work visible and distribute it equitably.’ I flag the pattern to my manager — “this work is essential and falling on a few people; we need to rotate it or fund it explicitly” — rather than silently dropping it for someone else to pick up.
• “What if your manager explicitly asks you to do the glue work?” - Strong answer: Then I ask them to explicitly value it in my review. “You are asking me to prioritize onboarding and cross-team coordination — I will do it, and I want us to agree now that this work will count as technical leadership impact in my next review, with these specific artifacts as evidence.” If they will not commit in writing, I know what the review will say before it happens.

• “I would just refuse to do glue work and focus only on coding.” - This tanks team health, and at senior level, team health is part of your job. You will get feedback that you are ‘not a team player’ and the promotion will move further away.
• “I would do the glue work and trust that my manager sees the impact.” - This is the exact failure mode Tanya Reilly’s talk warns about. Invisible work stays invisible no matter how much of it you do. Trust is not a substitute for legibility.

• Tanya Reilly, “Being Glue” (2019 talk and essay) — the definitive piece on this problem
• “The Staff Engineer’s Path” by Tanya Reilly — Part II on “Big-Picture Thinking” and documentation
• Related chapter: Communication and Soft Skills on making written artifacts the unit of influence