Truong Phung

Posted on May 5

🛠️ The Senior Software Engineer Playbook 📖: From Good Coder to High-Impact Engineer 🚀

#ai #leadership #webdev #tutorial

A deep, opinionated, practical guide for the engineer who has crossed the mid-level threshold — or is about to. The mental models, technical habits, ownership patterns, communication skills, and career mechanics that separate "solid senior" from "engineer the whole team builds around." Grounded in 2026 reality — AI-augmented coding, distributed async teams, post-ZIRP efficiency pressure, and a market that rewards impact over activity.

If you read only one section first, read §2 Mindset, §5 Ownership, and §14 Writing. Everything else is the implementation of those three.

Companion to 🧑‍💻 The Tech Lead Playbook: From Best IC to Multiplier 🚀 (the level above — read this one first), 🚀 The SaaS Template Playbook 📖 (how to build production systems), 🤖 The AI SaaS Playbook (Practical Edition)📘 (AI features), and 🏗️ Building High-Quality AI Agents 🤖 — A Comprehensive, Actionable Field Guide 📚 (agentic systems). This one is for the individual contributor at the Senior / Senior II level, at any size company, who wants to understand what "high-impact senior" actually looks like — and how to get there, stay there, and grow past it.

📋 Table of Contents

⚡ Read This First
🧠 The Senior Mindset
🎭 Mid-Level vs Senior vs Staff vs Principal
🚪 The First 90 Days in a Senior Role
🏛️ Ownership: The Core Senior Superpower
🔧 Technical Excellence & Engineering Craft
🗺️ System Design & Architecture Thinking
🔍 Code Review: Teaching, Not Policing
📦 Project Execution: From Scoping to Delivery
🎓 Mentorship & Knowledge Multiplication
🤝 Stakeholders: PM, Design, EM, Exec
🤖 The AI-Augmented Senior Engineer (2026)
⏱️ Deep Work, Focus & Operating Cadence
✍️ Writing: Your Highest-Leverage Skill
🔥 On-Call, Incidents & Production Ownership
🧹 Technical Debt & System Health
📈 Career Growth: The Senior Plateau & How to Break Through
🧑‍🔬 Hiring: How Seniors Contribute to the Loop
🏢 Navigating Org Politics & Visibility
⚠️ The Senior Engineer Anti-Pattern Catalog
🗺️ The Phased Roadmap (Year 1 → Staff)
📋 Cheat Sheet & Resources

1. ⚡ Read This First

Six truths that will save you 18 months of spinning your wheels at the senior level:

Scope, not skill, is what makes senior engineers senior. The gap from mid-level to senior isn't raw technical skill — most mid-levels are excellent coders. The gap is scope of ownership. A senior engineer sees past the ticket, past the sprint, into the system and the humans that system serves. They ask "is this the right thing to build?" before they ask "how should I build it?" If you are only executing tasks, you are operating below your level regardless of your title.
Reliability compounds faster than brilliance. The most effective senior engineers are not the most technically brilliant — they are the most predictable. They scope accurately, commit carefully, ship on time, communicate proactively about delays, and have a reputation for never dropping the ball. Reliability buys you credibility. Credibility buys you scope. Scope is how you grow. A single "10x brilliant but unpredictable" engineer creates more organizational damage than three juniors combined.
You are now a communication job that also writes code. Senior engineers spend 30–50% of their effective output on non-coding activities: design docs, code review, 1:1 mentoring, planning discussions, incident retrospectives, ADRs, and stakeholder updates. Engineers who optimize only for coding throughput at senior level are leaving 40% of their potential impact on the table. The faster you accept this, the faster you grow.
The senior engineer's job is to raise the floor, not the ceiling. Junior and mid engineers are ceiling-raisers: they do brilliant work on their own tasks. Senior engineers raise the floor: they make the team's minimum quality higher through standards, review practices, documentation, mentorship, and system design. One senior who writes a great onboarding doc and a clear testing guide creates more durable value than one who writes 3× as much code personally.
Your career is your product. Nobody else is running a roadmap for your growth. Your manager is optimizing for the team. The company is optimizing for delivery. You must invest intentionally in skills, visibility, relationships, and breadth — or you will find yourself "stuck" at senior for 7 years with a vague feeling that the career ladder is broken. It isn't broken. It just doesn't run automatically at this level. You have to drive it.
In 2026, an AI-augmented senior engineer is not optional. The gap between engineers who deeply leverage AI tools and those who use them superficially has become measurable in output velocity. Senior engineers who treat AI as a junior pair-programmer, delegate first drafts, use it to explore unfamiliar codebases, and generate test scaffolding are shipping at 1.5–2× the pace. This isn't about replacing your judgment — it's about removing the mechanical drag that used to tax your attention. Learn to delegate to AI the way you delegate to a capable junior.

The rest is implementation of these six.

Who this is for

You are a mid-level engineer who has just been promoted to (or given the responsibilities of) Senior.
You are a Senior who has been in role 1–3 years and feels like growth has plateaued.
You are a Senior aiming for Staff or Principal and want to understand what the path actually looks like.
You are a tech lead or EM trying to articulate what "Senior" means at your company.

Who this is not for

You want a tech lead playbook. That's techlead_playbook.md. Tech lead is a role (team + direction), senior is a level (scope + impact). They often overlap but are distinct; read both.
You want interview prep. This is about operating at the level, not landing the level.
You are a new grad or junior who wants to understand what senior looks like. Some of this will be useful but it assumes 3–5 years of professional engineering experience as the starting point.

A note on context

The default voice assumes a product engineering team at a startup or scale-up, 2026, with AI-assisted coding as the baseline norm. Enterprise/regulated-industry engineers: the craft sections apply verbatim; the career and visibility sections need translation (the political surface area is 2–3× larger, promotion cycles are slower, but the fundamentals are the same). Platform/infra engineers: the system design and technical debt sections are most relevant; the mentorship and writing sections are the highest-leverage gaps in most infra careers.

2. 🧠 The Senior Mindset

The skill gap from mid-level to senior is smaller than most engineers expect. The mindset gap is larger than almost everyone expects.

2.1 Identity reframe: from "task executor" to "problem owner"

A mid-level engineer is assigned a problem and solves it excellently. A senior engineer is assigned a goal and figures out the right problems to solve, in what order, with what trade-offs — and then solves them excellently. That distinction, compounded over two years, is what creates the salary delta and the promotion difference.

Mid-level operating mode	Senior operating mode
"My ticket is done, assigning back to PM"	"This ticket is done; I noticed two related issues — here's my assessment of priority"
"I'll implement what the design says"	"This design has a scaling problem at 100K rows — let me raise it before we build"
"This PR is ready for review"	"This PR is ready; here's what's in it, why I made the key trade-off, and what I deferred"
"I'm blocked waiting for the API team"	"I'm blocked; here's the workaround I'm proposing, ETA, and who I already notified"
"The tests are passing"	"The tests are passing; here's what I tested, what I didn't, and the known risk I'm comfortable shipping"
"This codebase is messy"	"This codebase has three specific pain points; here's a prioritized cleanup plan with effort estimates"

The reframe: you are not a resource that executes tasks. You are an engineer who owns outcomes.

2.2 The three modes of senior impact

Senior engineers operate in three modes simultaneously. The most common failure mode is over-indexing on Mode 1 and neglecting Modes 2 and 3:

Mode	What it is	Time allocation (healthy)	Anti-pattern
Builder	Writing code, shipping features, building systems	50–60%	"I just want to code" — 90%+ builder is a mid-level in senior clothing
Multiplier	Code review, mentorship, design doc writing, standard-setting	25–30%	"Reviews take time from real work" — treating multiplier work as overhead
Navigator	Technical direction, cross-team influence, scoping, risk identification	15–20%	"That's the PM/TL's job" — abdicating the high-information position the engineer uniquely holds

The healthy senior is one who allocates across all three modes. The stuck senior is one who defaults exclusively to Builder.

2.3 The senior engineer's actual job description

Nobody will write this for you clearly. Here is the plaintext version:

You are responsible for:

Taking a vaguely-scoped problem and producing a well-defined plan with effort estimates and explicit risks.
Shipping that plan reliably, communicating proactively when estimates are wrong.
Designing systems that handle the next order-of-magnitude growth, not just this sprint.
Leaving every codebase you touch in better shape than you found it.
Accelerating the people around you — not by doing their work, but by raising the quality bar they work against.
Representing technical reality accurately to non-technical stakeholders.
Giving your tech lead and EM fewer surprises.

You are NOT responsible for:

Running the team's ceremonies or setting the sprint (unless you're also tech lead).
Making product decisions (but you should inform them with technical data).
Approving everyone's design docs (that's the tech lead's job).
Being the only one who can review important code (if that's true, you're a bottleneck, not a senior).

2.4 The five key transitions that define senior

From "complete tasks" to "own problems" — you see the ticket's context, not just its description.
From "ask for help" to "resolve ambiguity" — you drive to a decision; you don't wait for clarity to come to you.
From "write code" to "design systems" — you think in interfaces, contracts, failure modes, and time horizons.
From "receive feedback" to "generate feedback" — your code review comments are teaching moments.
From "personal throughput" to "team throughput" — you feel your team's velocity as your own output.

3. 🎭 Mid-Level vs Senior vs Staff vs Principal

One of the most confusion-inducing aspects of engineering careers is the level definitions. Every company has slightly different labels. Here is the pragmatic model:

The level matrix

Dimension	Mid-Level (L4/E4)	Senior (L5/E5)	Staff (L6/E6)	Principal (L7/E7)
Scope	Feature / component	Service / system	Product area / sub-org	Org / company
Autonomy	Guided	Owns problems	Sets direction for area	Sets technical strategy
Ambiguity	Low — well-defined tasks	Medium — scopes own work	High — defines the work itself	Very high — defines direction from business goals
Leverage	Self (1x)	Self + 1–2 others (2–3x)	Team of teams (5–10x)	Org-wide (20x+)
Planning horizon	Sprint / 2 weeks	Quarter	Half / year	Year / multi-year
Key artifact	Working code + tests	Design docs + system proposals	Technical strategy + roadmap	Architecture standards + platform direction
Mentorship	Receives	Gives to juniors/mids	Grows seniors	Grows leads and staff
Cross-team work	Rare	Occasional	Common	Constant
Typical YoE	3–6 years	5–10 years	8–15 years	12+ years

What "Senior" actually means in different contexts

Company type	Senior means...
Startup (1–50 engineers)	You own a whole subsystem end-to-end and likely wear some lead duties. "Senior" is the primary band — most engineers here are Senior by title within 2–3 years.
Scale-up (50–500 engineers)	You own a significant service, lead projects that span 2+ quarters, and are a key voice in design reviews without being the TL.
Big Tech (500+ engineers, leveled)	The bar is explicitly higher. Senior = L5/E5 at Google/Meta/Amazon. Expected to work with high ambiguity, own multi-month projects, and influence other teams' direction.
Enterprise / regulated	More about depth of domain expertise, ownership of complex legacy systems, and cross-functional communication. Promotion is slower; the ceiling is lower; stability is higher.

The "Senior" trap

The most common career mistake at this level: using "Senior" as a destination rather than a platform. Senior is not a resting level. It is the base camp from which you choose your next direction:

Deeper technical (→ Staff/Principal IC)
Broader organizational (→ Tech Lead → EM)
Deeper domain (→ specialist with unique leverage)
Outward (→ open-source, developer advocacy, consulting, founding)

Every engineer who treats senior as a plateau does slower work, gets less interesting projects, and eventually feels under-compensated. The level requires active maintenance through growth.

4. 🚪 The First 90 Days in a Senior Role

Whether you just joined a new company as a senior, or were promoted from mid-level on the same team, the first 90 days are your single biggest leverage window. You will never again have a socially acceptable reason to ask every "dumb" question. Use it ruthlessly.

Week 1–2: Orientation — read everything, judge nothing

Goal: build the map. You cannot make good decisions about a codebase or a team you haven't understood. Resist the urge to fix things you don't yet understand.

Read the last 6 months of architecture decision records (ADRs/RFCs).
Read the last 3 postmortem reports.
Shadow every on-call rotation shift on the schedule.
Walk through the production deployment process manually from scratch.
Read every ticket in the backlog without trying to re-prioritize it.
Set up your dev environment and document every step that wasn't in the README. (This is your first contribution.)

Mindset check: You are here to understand, not impress. Premature opinions based on insufficient context are the #1 Day-1 mistake of new seniors. The codebase has decisions you don't yet understand; every architectural "mistake" you see has a history.

Week 3–4: Contribute — ship something small, learn the feedback loop

Goal: understand how the team works. The process is as important as the code.

Complete one well-scoped ticket end-to-end: pick it up, design it, code it, test it, get it reviewed, merge it, confirm it in prod.
Pay attention to: review turnaround time, PR size norms, test coverage expectations, deploy pipeline speed, and how feedback is given.
Notice the gap between the official process and what the team actually does.

What to document for yourself:

Who is the go-to person for each service?
What are the implicit quality bars (not what the README says, but what actually passes review)?
What's the biggest known source of pain in the codebase?
What has been "about to be fixed for months" but keeps getting deprioritized?

Month 2: Context — understand why, not just what

Goal: understand the system's history and the team's dynamics.

Have 30-min 1:1 conversations with every engineer on the team. Ask: "What's going well here? What would you fix first if you owned the roadmap for a week?"
Have the same conversation with the PM and designer.
Map the three biggest technical risks in the system. Write them down privately — you'll return to this in month 3.
Ask your manager: "What does high performance look like for someone in my role here?"

Month 3: Stake your ground — identify and commit to a 90-day win

Goal: demonstrate senior judgment, not just senior skill.

Pick one problem — technical, process, or documentation — and own it completely.
Ideal: a 3–6 week project that is visibly useful but not so risky that a failure damages trust.
Write a short (1-page) plan: problem, proposed solution, success metric, timeline, risks.
Execute it. Communicate weekly. Ship it.

The 90-day goal: By day 90, your team should say: "This is someone we trust with important, poorly-scoped work. We can hand them a vague problem and they come back with a plan and eventually a shipped solution." That reputation is worth more than 3 months of high-velocity ticket closure.

Common 90-day mistakes

Mistake	Why it happens	The fix
Rewrites everything on day 1	You see mess without understanding why	Build the map first; refactor with full context
Tries to impress by shipping too much too fast	IC speed reflex from mid-level	Slower, higher-quality work with clear communication beats velocity
Ignores the humans, only studies the code	Introvert engineering default	The team is the system; study both
Over-promises in the first planning cycle	Wants to demonstrate value	Under-commit, over-deliver — the senior credibility pattern
Skips the "read all the ADRs" step	Feels unproductive	Every bad decision you avoid is worth 10x the reading time

5. 🏛️ Ownership: The Core Senior Superpower

If you take nothing else from this playbook, take this: ownership is the only unambiguous signal of seniority. Everything else — system design skill, code quality, mentorship ability — is table stakes. Ownership is the differentiator.

5.1 What ownership actually means

Ownership is not:

Being assigned a component and writing its code.
Being "on call" for something.
Being the one who originally built it.

Ownership is:

Knowing the health of the system at all times.
Proactively identifying and addressing risks before they become incidents.
Being accountable for the outcome, not just the activity.
Communicating the status without being asked.
Making the call when there is ambiguity — and accepting the consequences.

The simplest test: if nobody asked you about your system for three months, would it get better or worse? An owner makes it better. A contributor leaves it as-is.

5.2 The ownership spectrum

Not Owning                                          Fully Owning
     │                                                    │
     ▼                                                    ▼
"I did my ticket"  →  "I own this sprint"  →  "I own this system's health for the next year"

Most mid-levels live at "I did my ticket." Most seniors should live at "I own this system's health." The specific position depends on role scope, but the direction is always toward more.

5.3 The four dimensions of ownership

1. Operational ownership

Know your service's SLOs, error rates, latency p99, and recent alerts without looking at a dashboard.
Be the person your on-call partner calls when something weird happens.
Run the postmortem on your system's incidents, even when you didn't cause them.

2. Quality ownership

Know the technical debt in your system by priority.
Keep a living doc of the three biggest risks and when you plan to address them.
Never let known critical bugs accumulate without a documented decision to defer them.

3. Roadmap ownership

Understand why your system exists and what it needs to support 12 months from now.
Proactively flag when the PM's roadmap will create technical problems before they get designed into the sprint.
Bring technical proposals to planning — don't just respond to product requests.

4. People ownership

Know who understands your system besides you. If the answer is "nobody," fix it.
Make sure at least one other engineer can operate your system under pressure.
Write the runbook. Not because someone asked. Because it's correct.

5.4 The "absent owner" test

The single best diagnostic for whether you are operating at senior level: What happens when you are on two weeks vacation?

Answer	What it means
Everything breaks or stops	You are a single point of failure, not an owner — the system owns you
Nothing happens because nothing was planned	You have low-ownership scope — consider whether you're under-scoped
The team handles it with minor difficulty	Healthy ownership — they have your docs, your runbooks, and your judgment captured
The team handles it seamlessly with zero escalation	You've built ownership into the team — this is the actual goal

5.5 The proactive communication habit

The single most visible ownership signal is communicating without being asked. Most engineers communicate reactively: they answer questions when asked. Senior engineers communicate proactively: they surface risks before they're asked about them.

Weekly ownership habit (10 min/week):

Check the health metrics of your system.
Is there anything you're worried about?
Write one sentence in the team's async channel: "System health is good. One note: the queue depth spiked 3× yesterday at 2pm; I'm investigating but it's not urgent. ETA on root cause by EOD."

This habit costs 10 minutes. It builds 90% of your "reliability" reputation.

6. 🔧 Technical Excellence & Engineering Craft

Senior engineering is not just about knowing more technology. It's about cleaner judgment — knowing which technology to use, when not to use it, and how to build systems that age well.

6.1 The senior engineering quality bar

The minimum bar for senior-quality code is not "it works and passes tests." It is:

Correctness at the boundary, not just the happy path. Every external input is hostile until proven otherwise. What happens at zero? Null? Empty string? 100 million rows? Concurrent writes? Clock skew?
Understandability by the next engineer. The senior engineer's code is the team's learning material. If a mid-level engineer reads your PR and is confused, that's a signal.
Testability as a design constraint, not an afterthought. If your system is hard to test, it's hard to trust and hard to change. Senior engineers design for testability from the first line.
Explicit trade-offs, not implicit ones. Every code choice has a trade-off. Senior engineers name them in comments, in PRs, in ADRs. "We chose array over hash map here because the collection is always <10 items and the constant factor matters at this call frequency."
Graceful degradation. What does your component do when its dependencies fail? The answer should never be "it crashes the entire request" unless that's an explicit, documented decision.

6.2 The "leave it better" principle

The Boy Scout Rule in software: always leave the code in better shape than you found it. Operationally, this means:

When you open a file to make a change, fix the one obvious naming issue or missing test you see — in the same commit if small, in a follow-up if medium.
Never leave TODO comments that are not attached to a ticket. Either fix it now, create a ticket, or accept it as intentional.
When you add a feature, add the test coverage the feature deserved.
When you touch a service, check whether the README is still accurate.

The trap: "Leave it better" becomes "rewrite everything I touch" for some senior engineers. The rule is proportionality: the improvement should be smaller than the original change. A one-line bug fix should not be accompanied by a 500-line refactor in the same PR. Separate concerns.

6.3 The senior engineer's toolkit by domain

Backend systems

Understand your data store's consistency model. Not "read after write" — the actual CAP/PACELC trade-offs your DB makes under network partition. Know when a read can be stale and whether that's acceptable.
Know the difference between availability and durability. Your background job can fail and retry; your financial transaction cannot. The level of care differs by an order of magnitude.
Cache invalidation and cache stampede are real. Every cache is a form of distributed state. Know TTLs, know your invalidation strategy, know what happens on cold start.
Idempotency is not optional for external calls. Every HTTP call to a third party, every message enqueue, every write that crosses a network boundary needs an idempotency key or equivalent.
N+1 queries are never acceptable in code you own. The senior engineer catches them in review; the principal architect prevents them by design.

Frontend systems

Component design is API design. A component's props interface is a contract. Break it in a minor version bump and every consumer pays the cost.
The render cost of the component matters. Senior frontend engineers profile before and after major changes, not just when there's a reported performance issue.
Accessibility is not a checkbox. It's an engineering constraint, like security. It is not the design team's job; it's built in at the component level.
State management choices have half-lives. Local state < component state < context < global store < server state. Choose the shortest-lived option that solves the problem.

Data / ML systems

Data quality is a first-class concern. A model is only as reliable as the data pipeline feeding it. Senior ML engineers own data quality metrics, not just model metrics.
Versioning applies to data and models, not just code. Model rollback requires artifact versioning, feature store snapshots, and reproducible training pipelines.
Offline metrics and online metrics diverge. Test set performance is not production performance. Know your production latency, throughput, and drift metrics.

6.4 Performance: know before you optimize

The cardinal sin of premature optimization is not wasted effort — it is wasted readability. Complex, optimized code is expensive to maintain. The senior engineer's performance rule:

Measure first, always. "I think this is slow" is not a reason to optimize. "The p99 latency on this endpoint is 800ms, profiling shows 60% of that is in this function" is.
Understand the bottleneck type. CPU-bound, I/O-bound, memory-bound, and network-bound bottlenecks have different solutions. Applying the wrong solution doubles complexity without improving performance.
Optimize the algorithm before optimizing the implementation. An O(n²) algorithm with micro-optimized inner loop will never beat O(n log n) at scale. Choose the right data structure and algorithm first.
Document what you optimized and why. Optimized code is hard to read. Leave a comment explaining the trade-off you made. "Using a pre-allocated buffer here instead of repeated allocations — 3× throughput improvement measured with pprof, see [link to benchmark]."

6.5 Security: the senior engineer's default posture

Senior engineers treat security as a design constraint, not a post-hoc audit. The OWASP Top 10 is not a checklist — it is a mental model. Senior engineers internalize it and catch issues at design time.

The minimum mental checklist for any new feature:

What data does this feature touch? Is any of it sensitive (PII, credentials, financial)?
Can any user-supplied input reach a database query, shell command, or template renderer?
What is the authentication and authorization model? Is there a way to access data you shouldn't?
Does this endpoint expose information about other users' data through timing or error messages?
If this feature is compromised, what's the blast radius? Can it be isolated?

The principle of least privilege, applied: every database user, service account, API key, and IAM role should have exactly the permissions it needs to do its job — no more. Senior engineers enforce this at design time, not at security audit time.

7. 🗺️ System Design & Architecture Thinking

The most visible senior-level skill in interviews and design reviews is system design. But the deeper skill is architectural thinking — knowing what questions to ask before you draw a box.

7.1 The design process senior engineers use

Most engineers jump to solutions. Senior engineers start with requirements.

1. Clarify requirements
   ├── Functional: what must the system do?
   ├── Non-functional: latency, throughput, availability, durability, consistency
   └── Constraints: team size, timeline, budget, existing infrastructure

2. Identify the key design decisions
   └── Not all decisions are equal. "SQL vs NoSQL" is a key decision.
       "tabs vs spaces" is not. Spend time proportionally.

3. Generate options (at least 2–3)
   └── The engineer who presents one option has decided in their head;
       the design review is theater. Generate real alternatives.

4. Analyze trade-offs, not just correctness
   └── Every option has a downside. Name it explicitly.
       "Option A: simpler, but doesn't support real-time updates.
        Option B: supports real-time, but adds an ops burden we may not be ready for."

5. Make a recommendation with explicit reasoning
   └── Senior engineers don't hedge into committee decisions.
       They say "I recommend Option A because X, Y, Z. Here's what we're giving up."

6. Identify the riskiest assumption
   └── What has to be true for this design to work?
       What do we not know yet? How do we find out quickly?

7.2 The six system design trade-offs to always discuss

Consistency vs. Availability — Can the system serve reads during a partition? What's the user impact of stale data?
Latency vs. Throughput — Optimizing for one often hurts the other. Know which one your SLA cares about.
Simplicity vs. Flexibility — Every abstraction adds complexity. Every rigid system is faster to build and harder to change. Choose consciously.
Build vs. Buy — Every tool you build is a system you own. Every tool you buy is a dependency you don't control. The decision is rarely obvious.
Synchronous vs. Asynchronous — Async systems are more scalable and more resilient. They are also harder to debug, reason about, and test. Use async where the latency is real; not as a default.
Normalization vs. Denormalization — Normalized data is consistent; denormalized data is fast. At what query rate does the trade-off shift?

7.3 The ADR (Architecture Decision Record)

The single most durable artifact a senior engineer produces is not a service — it's a well-written ADR. An ADR captures:

# ADR-042: Use PostgreSQL JSONB for flexible product attributes

**Status:** Accepted
**Date:** 2026-03-14
**Deciders:** [names]

## Context
Products have heterogeneous attribute sets that vary by category (electronics have warranty data,
clothing has size/color). Adding a column per attribute leads to a ~300-column sparse table.

## Decision
Store flexible attributes in a JSONB column on the products table.

## Rationale
- GIN indexes on JSONB provide acceptable query performance for our read patterns
- Schema changes are additive, not migrations — important at our change rate
- Data lives in PostgreSQL, not a separate document store — reduces operational surface

## Consequences
- Queries on JSONB fields are less ergonomic in raw SQL
- Type safety requires application-level validation (mitigated by Pydantic schemas)
- Schema drift is possible; mitigated by JSON Schema validation on write

## Alternatives considered
- **EAV (Entity-Attribute-Value):** Rejected. Query complexity is unacceptable.
- **Separate document store (MongoDB):** Rejected. Two persistence systems for one domain.
- **Fixed columns with optional nulls:** Rejected. 300+ nullable columns is unmaintainable.

An ADR written like this is worth more than any verbal design review. It compresses months of context into a 5-minute read.

7.4 The "good enough" principle in architecture

Senior engineers know when to stop designing. The signal is: when adding more design detail produces less certainty than building a prototype.

The failure modes:

Under-design: jumping to implementation before understanding the scope, leading to expensive rework.
Over-design: spending 3 weeks on an architecture document for a system that needs to exist in 2 weeks.

The heuristic: design until you can estimate the work with ±25% confidence, then start building. The design continues in code.

8. 🔍 Code Review: Teaching, Not Policing

Code review is the highest-leverage activity a senior engineer does for the team. A great code review does three things simultaneously: it catches bugs, raises quality, and teaches. A mediocre code review does only the first. A bad code review does none and slows the team down.

8.1 The senior code review mental model

When you open a PR, ask these questions in order:

Is this the right change? — Does this PR solve the problem it claims to solve? Is the scope correct? Is there a simpler alternative?
Is the design sound? — Are the abstractions right? Is the data flow correct? Are the error cases handled?
Is it correct? — Does it work for the happy path? For edge cases? For failure modes?
Is it readable? — Can a new team member understand this code in 5 minutes?
Is it tested? — Are the test cases sufficient? Do they test behavior, not implementation?
Is it secure? — Does it introduce any of the OWASP Top 10 vulnerabilities?

Most reviewers start at #3 or #4. Senior engineers start at #1. A PR with a brilliant implementation of the wrong abstraction is a worse outcome than a clumsy implementation of the right one.

8.2 How to give high-quality feedback

The four review comment types:

Type	Syntax	When to use
Blocking	`[Blocking]` or `Request Changes`	Bug, security issue, design error, or clear correctness problem. Must be fixed before merge.
Suggestion	`[Suggestion]`	Code quality, naming, test coverage. Author should address or respond with reasoning.
Question	`[Question]`	You don't understand something. Ask genuinely — the answer often uncovers a missing comment.
Praise	`[Nice]` or just the comment	When the author did something well. This is not padding — positive feedback teaches as effectively as critical.

The comment that teaches:

Bad review comment: This is slow.

Good review comment:

[Suggestion] This loop runs in O(n²) because we're calling `.find()` on `users` for every item in `orders`.
At our current data size (~10K orders, ~50K users) this will block the event loop for ~200ms per request.

One option: pre-build a `Map<userId, User>` before the loop — O(n) construction, O(1) lookups.
Happy to pair on this if helpful.

The good comment teaches the why, proposes a solution, and estimates impact. The author walks away smarter, not just corrected.

8.3 Reviewing large PRs

Large PRs are the single biggest drag on team velocity. Senior engineers fix the systemic problem (large PR culture) as well as the instance:

In the review:

Ask for a summary of the approach before diving into the diff if the PR lacks context.
Review the design/test files first — they tell you the intent.
Be explicit if the PR is too large to review effectively: "This PR changes 1,400 lines across 22 files. For a change of this scope, I'd want to see it split by concern: the schema migration, the API layer, and the UI as separate PRs. I'm happy to review any of those as they land."

In the culture:

Write your own PRs as the example: < 400 lines, single concern, self-explanatory description.
Discuss the "draft PR + async feedback" workflow in your next team retro if large PRs are endemic.

8.4 The review velocity balance

Senior engineers balance thoroughness with speed. Slow reviews are not "more careful" — they are a team tax:

Acknowledge receipt within 4 hours (async norm): "Looked at the first half — I'll have full feedback by EOD."
Complete reviews within 1 business day for PRs < 200 lines.
For large PRs (200–500 lines): aim for 2 business days with an interim acknowledgment.
Flag PRs that will take longer rather than silently delaying them.

9. 📦 Project Execution: From Scoping to Delivery

Senior engineers don't just complete projects — they run them. The difference between a mid-level who executes a well-defined project and a senior who runs an ambiguous one is the scoping and risk management front-end.

9.1 The scoping process

When you receive a vague requirement — "we need to support bulk CSV upload for users" — a senior engineer does not immediately estimate it. They investigate first:

The scoping checklist:

What exactly does "bulk CSV upload" mean? (1K rows? 1M rows? Real-time progress? Async with email notification?)
What are the failure modes and who is responsible for them? (Bad rows: reject all or import valid?)
What are the security implications? (CSV injection, file size limits, rate limiting)
What existing code does this touch?
Are there related systems that need to change? (API, background jobs, notifications)
What's the success metric? How will we know it's done?

The scoping artifact: a 1-page document (not a 20-page design doc) that answers these questions and gives an estimate range with explicit assumptions: "Assuming we use async processing with email notification and reject invalid rows with a report, this is a 1–2 sprint effort. If we need real-time progress and in-app notifications, add another sprint."

9.2 The estimate discipline

Engineering estimates are infamous for being wrong. Senior engineers are better at estimates because they apply discipline:

Break everything down to <2-day chunks. If a task is estimated at "2 weeks," that estimate is a guess. Decompose it until no single item is > 2 days; then sum. The act of decomposing usually reveals hidden work.
Name your assumptions. Every estimate has hidden assumptions. State them. "This assumes the auth library supports service-to-service tokens; if not, add 3 days."
Add explicit risk buffers, not percentage padding. "I'm adding 3 days for unknown integration complexity with the legacy billing system" is better than "adding 20% buffer." Named buffers get used correctly; unnamed buffers get cut.
Distinguish optimistic, likely, and pessimistic. Give a range: "Best case: 6 days. Most likely: 10 days. Worst case if we hit the auth issue: 14 days." Single-point estimates are false precision.
Update estimates as information changes. An estimate that was accurate on Monday can be wrong by Thursday. Communicate immediately when new information changes the timeline — not at the end-of-sprint retrospective.

9.3 The execution loop

Once work begins, senior engineers run a tight feedback loop:

Daily: Am I on track for my estimate?
  └── Yes → continue
  └── No → why? Can I recover? Who needs to know?

Weekly: Is the design still right given what I now know?
  └── Yes → continue
  └── No → call an async design review, don't push through with the wrong design

At milestone: Does the PM/TL/EM know the current state?
  └── Don't wait to be asked. One sentence in Slack:
      "CSV upload: backend done, working on frontend now, still on track for Thursday."

9.4 The unblocking instinct

Senior engineers have a strong instinct to be proactive about blockers. Mid-levels wait until a blocker is 2 days old before mentioning it. Seniors mention it the moment it appears, with a proposed mitigation:

"I'm blocked on the auth team's API; their ETA is Friday. I'm going to stub the interface locally so I can continue building against the contract and integrate when they're ready. Flagging in case the Friday dependency becomes a problem for sprint closure."

This message takes 30 seconds to write and prevents a Friday scramble.

9.5 The definition of done (senior version)

Mid-level "done": code merged, tests passing, ticket closed.

Senior "done":

[ ] Code merged and all tests passing.
[ ] Deployed to staging; smoke-tested personally.
[ ] Deployed to production; monitored for 24 hours after deploy.
[ ] Metrics / dashboards updated or created.
[ ] Documentation updated (README, API docs, runbook).
[ ] PM / stakeholder notified.
[ ] Follow-up tickets created for deferred scope.
[ ] Anything that broke in prod is followed up to resolution.

10. 🎓 Mentorship & Knowledge Multiplication

The highest-leverage thing a senior engineer does — with the lowest moment-to-moment visibility — is making everyone around them more effective. This is not a soft skill. It is an engineering multiplier.

10.1 The mentorship modes

Mode	What it is	Frequency	Cost
Paired coding	Sitting (or screen-sharing) with a junior/mid on their problem	1–2 hours/week	High time, high impact
Review as teaching	Code review comments that explain why, not just what	Every PR you review	Low marginal cost
Written knowledge	Docs, runbooks, decision records, "how I think about X" posts	Monthly	Medium time, compounding impact
Design shadowing	Inviting junior engineers into your design reviews as observers	Every major design	Low cost, high signal modeling
Career 1:1s	Asking about career goals, giving specific feedback on growth areas	Monthly	Medium time

The most impactful form of mentorship is the one that doesn't scale with your calendar: writing. A runbook you write once can onboard 20 engineers. A pairing session scales to one.

10.2 How to give useful feedback

The failure mode in peer mentorship is feedback that is too vague ("you should communicate more"), too late (at the quarterly review), or too personal ("you need to be more confident"). Effective senior feedback is:

Specific: "In last Tuesday's design review, you presented three options without a recommendation. The stakeholders were waiting for you to drive to a conclusion — that's a behavior I'd work on."
Timely: Within 24–48 hours of the observation, not at the retrospective.
Behavioral: What the person did, not who the person is.
Oriented toward the person's goals: "You told me you want to grow toward Staff. This skill — driving design decisions — is specifically how Staff engineers are evaluated here."

10.3 The knowledge bus factor problem

The "bus factor" of a codebase is the number of people who would need to leave before the project is in serious trouble. A bus factor of 1 (only one person understands a system) is a critical organizational risk — and it is a senior engineering failure, not a management failure.

Senior engineers actively increase bus factor:

Pair on the complex systems you own with at least one other engineer.
Write the document you wish existed when you joined.
Present an internal tech talk on the system you understand best.
Code review: leave comments that explain why the system works the way it does, for the future reader.
When you take vacation, designate a point person and make sure they can actually handle on-call.

10.4 Giving feedback to peers (including more senior engineers)

One of the hardest transitions for senior engineers: giving honest technical feedback to peers or to people more senior than you. The instinct is to soften, deflect, or stay silent.

The framing that helps: feedback is a gift to the system, not a judgment of the person. You are saying: "Here is information the system needs to make better decisions."

Practical scripts:

To a peer: "I want to share an observation from the code review — this might just be a personal style thing, but I noticed [X]. My concern is [Y]. How are you thinking about that?"
To someone more senior: "I might be missing context, but I'm worried that [design choice] will cause [specific problem] when we hit [scenario]. Can we talk through whether that's a real risk?"

11. 🤝 Stakeholders: PM, Design, EM, Exec

Senior engineers have more stakeholder surface area than mid-levels. Managing that surface area well is the difference between being seen as a technical expert and being seen as a valuable engineering partner.

11.1 Working with Product Managers

The PM-engineer relationship is the most important cross-functional relationship in product engineering. The best senior engineers treat it as a genuine partnership, not a client-contractor dynamic.

What PMs need from senior engineers:

Honest effort estimates with explicit assumptions (not estimates sized to fit the roadmap).
Early warning on technical constraints that will affect their plans.
Clear explanations of trade-offs in terms of user/business impact, not technical jargon.
Technical input on prioritization: "Here's what the tech debt is costing us in velocity."

What senior engineers need from PMs:

Context on the why behind features, not just the what.
Access to customer feedback and usage data.
Clear priority ordering, not "everything is P0."
Protected time for technical investment that doesn't have a direct feature tie.

The anti-patterns to avoid:

Anti-pattern	Cost
"That's not technically possible" without explanation	PM doesn't trust your assessments
Accepting a vague requirement without pushback	You build the wrong thing; PM blames the engineers
Going to the PM with only "this will take a long time"	PM can't make a prioritization decision without a number
Gold-plating scope beyond what the PM asked for	PM can't rely on your estimates

11.2 Working with Designers

The senior engineer's job in design collaboration is to be a technical partner, not a gatekeeper:

Review designs before they go to dev with a single focused question: "Is there anything here that will be significantly harder than expected, and does the PM know the cost?"
Propose technical alternatives when the implementation is prohibitively expensive: "This animation approach is 3 weeks of work. Here's a CSS-only version that looks 90% as good and takes 2 days."
Never ship an inaccessible design without escalating: WCAG compliance is your code, not the designer's figma.

11.3 Working with Engineering Managers

Your EM's job is to ensure your growth, remove organizational blockers, and represent your team. Your job is to make their job easier:

Surface technical risks early. Your EM will be asked in leadership meetings about your project's health. Don't let them be surprised.
Bring solutions, not just problems. "The deployment pipeline is breaking every other day" is a problem. "The deployment pipeline is breaking every other day because of a flakey integration test. Here are three options to fix it with effort estimates" is a brief your EM can act on.
Give your EM visibility into cross-team blockers. They have leverage you don't have in org escalations. Use it.

11.4 Communicating technical reality to non-technical stakeholders

The most career-defining communication skill of a senior engineer: translating technical complexity into business consequence without dumbing it down.

The template:

"The [technical thing] means [business consequence] because [simplified mechanism].
Our options are: A) [option] which [business trade-off], or B) [option] which [business trade-off].
My recommendation is [X] because [reason in business terms]."

Example:

"Our database is at 75% capacity. If we continue at the current growth rate, we'll hit the limit
in about 6 weeks, which means new user signups could fail. Our options are: A) add more storage
(1 day of work, $200/month ongoing), or B) archive old data to cheaper storage (3 weeks of work,
$50/month ongoing). I recommend option A given the timeline — we can do B in Q3."

12. 🤖 The AI-Augmented Senior Engineer (2026)

In 2026, AI-augmented coding is the baseline expectation, not a differentiator. The senior engineers who are pulling ahead are not those who use AI tools — everyone does — but those who use them at the senior level, applying AI to the high-leverage work, not just the mechanical work.

12.1 The AI leverage pyramid

                    ┌───────────────────────────────┐
                    │  Strategic leverage (senior)   │
                    │  - Architecture exploration    │
                    │  - Risk analysis               │
                    │  - Documentation generation    │
                    ├───────────────────────────────┤
                    │  Tactical leverage (mid)       │
                    │  - Test scaffolding            │
                    │  - Boilerplate generation      │
                    │  - Refactoring support         │
                    ├───────────────────────────────┤
                    │  Mechanical leverage (junior)  │
                    │  - Autocomplete               │
                    │  - Syntax help                │
                    │  - Simple code translation    │
                    └───────────────────────────────┘

Most engineers operate at the bottom two tiers. Senior engineers unlock the top tier.

12.2 How senior engineers should use AI tools

High-leverage uses (senior tier):

Architecture exploration: Use AI to rapidly prototype 2–3 alternative designs before committing. "Here are my requirements; generate three different database schema designs with the trade-offs of each." Then apply your judgment to evaluate them.
Risk and edge case generation: "Here is my proposed implementation. What are the edge cases, failure modes, and security risks I haven't considered?" AI is excellent at generating the adversarial perspective you're too close to see.
Documentation first drafts: A 1-page design doc that would take you 2 hours to write takes 20 minutes with AI: generate the skeleton, then edit heavily. The time is in the editing and judgment, not the generation.
Unknown codebase navigation: "Here is a 2,000-line file. Explain the key data flows, the likely areas of complexity, and what I need to understand before making changes to the auth logic." This compresses days of reading into hours.
Test case generation: Given a function signature and description, AI can generate 80% of the test cases. Your job is to add the 20% that requires domain or business knowledge.

Medium-leverage uses (tactical tier):

Boilerplate code, type definitions, migration scripts, repetitive patterns.
PR descriptions and commit messages from your diff.
SQL query optimization suggestions (with your verification).
Error diagnosis: paste the stack trace and the code context.

Uses that waste senior-level time:

Using AI for simple autocomplete you could type in 5 seconds.
Asking AI to make architectural decisions for you.
Pasting AI output directly without review into security-sensitive code.
Using AI to avoid understanding code you're responsible for owning.

12.3 The AI verification discipline

The single most important habit with AI-generated code: review it as you would review a senior intern's code. The code is often good. It is sometimes subtly wrong in ways that are hard to detect without deep context.

The verification checklist:

Does it actually do what I asked? (Read it, don't skim it.)
Does it handle the failure cases correctly?
Does it follow the codebase's existing patterns and conventions?
Are there any security implications I should check?
Is there any part I don't understand? (If yes: understand it before shipping it.)

12.4 The productivity delta

A 2026 senior engineer operating with full AI integration ships at approximately 1.5–2× the velocity of an equivalent engineer not using AI tools, across most software domains. This is not magic — it is compounded from:

Reduced mechanical drag (autocomplete, boilerplate) — ~20% velocity gain.
Faster onboarding to unfamiliar codebases — ~15% gain.
Faster first-draft production (docs, tests, types) — ~25% gain.
Faster debugging with AI as a second opinion — ~15% gain.

The ceiling is set by judgment, not by AI — the hardest decisions still require human understanding of business context, organizational dynamics, and architectural trade-offs.

13. ⏱️ Deep Work, Focus & Operating Cadence

The senior engineer's most valuable output — design docs, complex systems, architectural decisions — requires deep, uninterrupted focus. Managing your attention as a resource is a core senior engineering skill.

13.1 The attention economy of senior work

Senior engineers face a structural attention problem: they are both producers (need deep work) and consumers (expected to be available for the team). These modes are fundamentally incompatible within the same hour.

The four attention modes:

Mode	Description	Examples	Optimal block size
Deep design	Writing, architecture, complex debugging	Design docs, RFC writing, hard debugging	3–4 hour uninterrupted blocks
Review/feedback	Consuming and responding to others' work	Code review, design review, PR comments	60–90 minute blocks
Collaboration	Real-time work with others	Pairing, 1:1 mentoring, whiteboard sessions	60–90 minute blocks
Admin/async	Processing information, routing, planning	Slack, email, Jira, daily standup	2×20-30 minute slots

Most engineers context-switch between all four modes all day, doing all of them poorly. Senior engineers batch by mode and protect blocks.

13.2 The weekly operating cadence

A healthy senior engineer's week (product engineering team, async-first culture):

Monday
  08:00–09:00   Weekly planning: set 3 outcomes for the week. Review incoming dependencies.
  09:00–12:00   Deep work: design, architecture, or hardest open problem
  13:00–17:00   Deep work continued + code review batch (30 min at end of day)

Tuesday–Wednesday
  Core building days: protect 6-hour blocks of deep work
  30-min code review batch at start and end of day
  Any required meetings: keep to < 90 min total/day

Thursday
  Morning: design and architecture reviews; longer collaboration sessions
  Afternoon: document any decisions made this week; catch-up on accumulated async

Friday
  Morning: wrap up and merge open work; don't start new complex work
  Afternoon: learning, exploration, reading; write any weekly status update
  End of day: close open loops; make a brief note of where you'll pick up Monday

13.3 Protecting deep work

The biggest threats to senior deep work:

Default-open calendar — meetings scheduled in the middle of your best focus hours. Fix: block 3-hour "DND" slots on your calendar proactively. Treat them like a production deployment window.
Slack as a synchronous medium — the expectation that you respond to Slack within minutes. Fix: set your response time norm explicitly. "I check Slack at 10am and 3pm. For anything urgent, use @here or call."
Premature review requests — being asked to review things before you have the context or the block. Fix: batch reviews. "I do code reviews at 9am and 5pm. If you need something reviewed sooner, say so and why."
Meeting overload — attending every meeting because you're "the technical expert." Fix: ask "what's the specific technical input needed?" and, when possible, provide it as a written async comment instead of attending.

13.4 The energy management dimension

Cal Newport's Deep Work thesis: concentration is a skill that degrades without practice. In 2026, with Slack, AI chatbots, and constant notification streams, the average engineer's sustained concentration time is shrinking while the value of deep focus is growing.

Senior engineers who protect their focus build a compound advantage over time. The practical habits:

No phone / social media during deep work blocks — not "phone face down," phone in another room.
Physical environment signals: headphones on = unavailable. Communicate this norm to your team.
End every deep work block with a written "next step" — so you can resume in exactly 60 seconds, not 20 minutes.
Track your deep work hours per week. If it drops below 10 hours (for a senior IC), something structural is wrong.

14. ✍️ Writing: Your Highest-Leverage Skill

The most underrated skill in a senior engineer's toolkit is not algorithms, not distributed systems, not AI — it's writing. In 2026's async, distributed, AI-tool-assisted engineering world, the ability to compress complex technical reasoning into clear, actionable prose is a force multiplier on every other skill you have.

14.1 Why writing is an engineering skill

Your design doc is a force multiplier. One well-written RFC can align 6 engineers, prevent 3 meetings, and create a permanent artifact that onboards the next 4 team members.
Writing reveals thinking errors. Engineers who can't write clearly often can't think clearly about the problem. The act of writing your design forces you to confront the gaps.
Async writing scales indefinitely; meetings don't. A Slack message disappears. A written doc is available to the person who joins 6 months later at 2am in a different timezone.
Good writers get higher-scope work. Execs, PMs, and cross-functional partners trust engineers whose written output is clear. That trust is what gets you the interesting ambiguous projects.

14.2 The senior engineer's writing portfolio

Document type	Purpose	Frequency	Length
Design doc / RFC	Propose and align on a significant technical change	Per major feature/system	1–5 pages
ADR (Architecture Decision Record)	Capture a significant decision with context and rationale	Per key architectural decision	0.5–1 page
Runbook	Step-by-step operational procedure	Per operational workflow	1–3 pages
Postmortem	Analyze an incident; capture learnings	After every significant incident	1–3 pages
Technical brief	Summarize a technical situation for non-technical audience	As needed	0.5–1 page
Weekly status	Async update on work progress	Weekly	3–5 bullets
Onboarding doc	Guide for new team members	Once per major system	2–5 pages

14.3 The design doc structure that works

The format that most engineering teams find effective, adapted from Google's and Stripe's internal conventions:

# [Title]

**Status:** Draft / In Review / Accepted / Superseded by ADR-XXX
**Author(s):** [names]
**Date:** YYYY-MM-DD
**Reviewers:** [names or team]

## Problem

One paragraph. What problem are we solving? Why does it matter?
What is broken, missing, or suboptimal today?

## Goals & Non-goals

Goals:
- [What this change achieves — measurable if possible]

Non-goals:
- [What this change explicitly does NOT address — this section prevents scope creep]

## Background

Context a reviewer needs that isn't assumed. Architecture diagrams here.
Link to relevant ADRs, postmortems, or external references.

## Proposal

The solution. How it works. Be specific — include API shapes, schema changes,
data flows, and error handling. Diagrams strongly encouraged.

## Trade-offs & Alternatives Considered

| Option | Pros | Cons |
|---|---|---|
| Proposed approach | ... | ... |
| Alternative A | ... | ... |
| Alternative B | ... | ... |

Why you chose the proposed approach over the alternatives.

## Open Questions

- [Q1]: How should we handle [edge case]?
- [Q2]: Do we need to migrate existing data or just new data?

## Implementation Plan

1. Phase 1 (Week 1–2): ...
2. Phase 2 (Week 3–4): ...

Estimated effort: X weeks / sprints.

## Success Criteria / Rollout Plan

How we'll know it worked. Feature flags? % rollout? Metrics to monitor.

14.4 The five writing anti-patterns

The wall of text — no headers, no structure. Fixes: add hierarchy, use bullets and tables for multi-item lists.
The jargon document — assumes expert-level context that only 2 people have. Fix: add a "Background" section; link terminology.
The options-only document — presents three options without a recommendation. Fix: engineers own their recommendation; the doc must conclude with one.
The thesis novel — 15-page design doc for a 2-day change. Fix: length should be proportional to irreversibility. A reversible 2-day change needs a Slack message, not a RFC.
The frozen artifact — written once, never updated, becomes wrong within weeks. Fix: ADRs are immutable snapshots; runbooks and docs have an explicit owner responsible for their accuracy.

14.5 Writing velocity with AI (the 2026 approach)

AI tools have transformed the cost of producing first drafts. The senior engineer's writing workflow in 2026:

Sketch in bullets first (10 min): don't open a doc, don't open AI. Sketch the key points in bullet form.
Generate a first draft with AI (5 min): "Here are my bullet points. Generate a design doc in the format [template]. Preserve my reasoning exactly; improve the prose."
Edit heavily (30–60 min): cut what's wrong, add what AI missed (domain knowledge, specific system context, org-specific constraints), sharpen the recommendation.
Get feedback from one person before sharing broadly (24 hours): the first reader finds the gaps AI can't.

The time to a high-quality design doc drops from 4 hours to 60–90 minutes. The quality ceiling stays set by your judgment, not the tool.

15. 🔥 On-Call, Incidents & Production Ownership

Senior engineers don't just participate in on-call — they own it. The way a senior engineer shows up during incidents is one of the clearest signals of production maturity.

15.1 The senior on-call mindset

Incidents are not interruptions. They are the most direct signal your production system sends you. Senior engineers treat them as high-value information:

Every incident is a test of your operational understanding.
The postmortem is a gift: a structured way to improve the system without the same failure re-occurring.
Your composure under pressure is visible to your team. It is one of the ways you model culture.

The wrong mindset: "On-call is the tax I pay for the rest of my job."

The right mindset: "On-call is the feedback loop that makes my systems better and my engineering judgment sharper. I'm the closest person to the system; I have the best chance of seeing the real problem."

15.2 Incident command at the senior level

In a P0/P1 incident, the senior engineer's job (when incident commander) is distinct from the technical investigator's:

Role	Responsibility
Incident Commander	Coordinates the response. Assigns roles. Keeps comms channel clear. Decides when to escalate.
Technical Investigator	Digs into the root cause. Does not get distracted by coordination. Reports findings to IC.
Comms Owner	Writes and sends external status updates. Shields IC and investigator from stakeholder noise.

Senior engineers should be able to play any of these roles. The most senior person in the room defaults to IC unless there is a designated IC function.

IC behavior during a P0:

Open a dedicated incident channel. "P0 - [service] - [brief description] - Started [time]. IC: @[you]. Investigator: @[other]."
Every 15 minutes: post a brief update in the channel. Even "we're investigating, no resolution yet" is better than silence.
Make decisions explicitly: "We're going to roll back to v2.3.1 in 5 minutes. Investigator, confirm impact of rollback on inflight requests."
Protect the investigator from being interrupted. You are the buffer.
When resolved: "Resolved at [time]. Impact: [N users affected, N minutes down]. Follow-up: postmortem in 48 hours. @[PM] notified."

15.3 The postmortem discipline

A postmortem written by a senior engineer should be a learning artifact for the entire org, not a blame assignment:

## Incident Postmortem: [Title]

**Date:** [incident date]
**Severity:** P0 / P1 / P2
**Duration:** [start time] → [end time] ([N minutes])
**Impact:** [N users affected, business impact]
**Author:** [name]

### Timeline
- [HH:MM] - Alert fired
- [HH:MM] - On-call engineer acknowledged
- [HH:MM] - First hypothesis formed
- [HH:MM] - Root cause identified
- [HH:MM] - Fix deployed
- [HH:MM] - Resolved / recovery confirmed

### Root Cause
One paragraph. What actually failed and why.
Resist the urge to identify a person as the root cause.
The root cause is always a system property (missing test, inadequate monitoring, unclear runbook).

### Contributing Factors
- [Factor 1]: ...
- [Factor 2]: ...

### What Went Well
- [The rollback process was clean and took < 5 minutes]
- [The monitoring alert fired within 2 minutes of the issue beginning]

### What Went Poorly
- [The runbook for this scenario was missing]
- [The first responder didn't have DB access and had to wait 20 min for escalation]

### Action Items
| Item | Owner | Priority | ETA |
|---|---|---|---|
| Add runbook for queue saturation | @[name] | P1 | [date] |
| Add alert for DB connection pool saturation | @[name] | P2 | [date] |

The most important rule: Action items without owners and ETAs are decorative. Every postmortem item should be a real ticket in the backlog within 48 hours.

16. 🧹 Technical Debt & System Health

Senior engineers are the primary stewards of long-term system health. This is not the PM's job or the tech lead's job — the senior engineer who owns a system is the one with the context to understand its health and the judgment to prioritize debt reduction.

16.1 The technical debt taxonomy

Not all tech debt is equal. Senior engineers distinguish:

Type	Description	Risk	Priority
Deliberate, prudent	Known shortcut made to hit a deadline, documented	Low if documented	Schedule when cost of carrying > cost of fixing
Inadvertent, prudent	Code that was fine when written, now outdated given new knowledge	Medium	Address when touching the area
Deliberate, reckless	Shortcut taken with no plan and no documentation	High	Urgent — this is the time-bomb debt
Inadvertent, reckless	Code written without standards, copied without understanding	High	Must be isolated and planned for
Complexity debt	Over-engineered systems that are hard to understand or change	Medium-high	Refactor when area becomes a hotspot

16.2 The debt register

Senior engineers maintain a living, prioritized debt register for their systems. Not a jira epic that never gets touched. An honest, up-to-date list:

## System: Payments Service
Last updated: 2026-03-15
Owner: @[you]

### P1 (Active risk, must plan)
1. Stripe webhook handler has no idempotency — duplicate events cause double-charges
   - Estimated fix: 3 days
   - Risk: Occasional customer complaint; not caught until they contact support

### P2 (Known degradation, schedule when possible)
2. Payment retry logic is hard-coded with no configurable backoff
   - Estimated fix: 2 days
   - Risk: Not configurable per payment type; will need to change for enterprise customers

### P3 (Annoying, low risk)
3. Test suite has no integration test for refund flow
   - Estimated fix: 1 day
   - Risk: Regressions go to prod; caught in staging ~50% of the time

The act of maintaining this register does three things: it forces you to actually know your system, it gives you a prioritized conversation with your PM/TL when "should we clean up technical debt?" comes up, and it prevents debt from becoming invisible until it explodes.

16.3 The "technical debt conversation" with PMs

The most common point of friction at the senior level: engineers want to fix tech debt; PMs want to ship features. The mistake is framing debt as an engineering concern. Frame it as a business concern:

Wrong: "We need to refactor the auth service. It's getting really messy."

Right: "The auth service is causing 2–3 hours of engineer debugging time per week due to its complexity. Over the quarter, that's 25–30 hours — roughly a sprint's worth of engineering capacity. Here's a 1-sprint refactor that eliminates the most painful parts. The ROI is positive within 6 weeks."

Numbers, not feelings. Business consequence, not engineering aesthetics.

16.4 The strangler fig refactor

For large systems that need significant rewriting, the "strangler fig" pattern is the senior engineer's default:

Build the new alongside the old — don't delete anything yet.
Route new traffic to the new — while old traffic still runs on the old.
Migrate old traffic incrementally — 1% → 10% → 50% → 100%.
Delete the old only when traffic is at 0 — never sooner.

This pattern lets you refactor production systems without a "big bang" cutover that brings risk. The key habit: never plan a rewrite that requires a feature freeze. If your refactor requires freezing feature development for more than 2 weeks, your migration plan is wrong.

17. 📈 Career Growth: The Senior Plateau & How to Break Through

The senior plateau is real. It is not a sign of ceiling — it is a sign of a missing ingredient. Almost every "stuck senior" is missing one of three things: scope, visibility, or external signal.

17.1 Why engineers get stuck at senior

The three most common causes:

Invisible impact — doing great work that nobody knows about. Code quality is high, system health is good, the team is mentored — but none of this is written down or communicated. The result: at calibration, your manager says "I think they're doing well" but can't give three specific examples.
Too narrow — deep expertise in one system but no influence beyond it. Staff-level engineers affect multiple teams. Senior engineers who only affect their own codebase don't have the scope to be assessed as Staff.
Waiting to be ready — "I'll take on more ambiguous work once I've proven myself in the current work." This is backwards. You prove yourself by taking on ambiguous work. Waiting for a clear mandate to do Staff work means never doing it.

17.2 The three growth levers at senior

Lever 1: Widen your scope.

Ask for the project with the most cross-team dependencies.
Volunteer to own the service nobody else wants to touch.
Write the technical strategy document your tech lead hasn't had time to write.
Offer to represent your team in architecture reviews with other teams.

The signal you're sending: "I can operate beyond the boundaries of my current assignment."

Lever 2: Create your artifacts.
Your impact needs to be legible. For every quarter, you should be able to point to:

One design doc or ADR that was adopted.
One mentorship moment with a measurable outcome ("I paired with [junior] on X; they now own it without help").
One system or process that is measurably better because of something you did.

If you can't point to these, you have an artifact problem, not a work problem.

Lever 3: Build your external signal.
This is the hardest but often most impactful:

Present at an internal tech talk.
Write a technical blog post.
Contribute to an open-source project in your domain.
Speak at a local meetup.

External signal does two things: it forces you to produce high-quality, legible work (blog posts and talks sharpen your thinking), and it creates evidence that is viewable by people outside your team who will make decisions about your career.

17.3 The "Staff scope" preview for ambitious seniors

If you want to reach Staff/Principal, you need to demonstrate Staff-level behaviors before you are promoted. The delta from Senior to Staff:

Dimension	Senior	Staff
Scope	One team's system	Multiple teams' systems or a platform
Influence	My PRs, my team's design reviews	Technical direction across 2–3 teams
Initiative	"Someone should fix X" → "I'll fix X"	"Someone should fix X" → "I'll propose how the org should fix X and why"
Ambiguity	Handles well-defined problems	Defines the right problems from business goals
Investment	Mentors on my team	Grows other seniors across the org

The transition is not about more of the same; it is about a different kind of work.

17.4 The promotion conversation

Promotions at senior+ level almost never happen automatically. They require an explicit conversation:

Make your intent known early: "I'm aiming for Staff within 18 months. What does that path look like here?" Have this conversation 12–18 months before you want the promotion.
Get the criteria in writing. "Can we document what I would need to demonstrate to be considered for Staff? I'd like to use that as a rubric for my growth."
Track your evidence quarterly. "In Q2, I led the [X] architecture redesign across teams Y and Z. Here's the impact."
Calibrate against the bar with your manager. Every 6 months: "Based on what I've done, where am I relative to the Staff bar? What's the gap?"
Treat your manager as a sponsor, not a judge. Your manager is your advocate in calibration; give them the material they need to advocate effectively.

18. 🧑‍🔬 Hiring: How Seniors Contribute to the Loop

At mid-level, you might participate in a few interviews. At senior, you are a primary contributor to the hiring pipeline. The quality of your team over the next two years depends heavily on how well senior engineers interview.

18.1 The senior engineer's role in hiring

Technical interview: you are the closest peer to the candidate. Your job is to assess their technical depth, problem-solving approach, and design judgment.
Culture add interview: you assess how the candidate works in ambiguous situations, gives feedback, and handles conflict.
Debrief: your vote and reasoning carries weight. Write detailed structured feedback, not "good candidate."

18.2 How to run a great technical interview

The wrong approach: "Here is LeetCode problem #453, you have 45 minutes, go."

The right approach: A problem that tests engineering judgment, not memorized algorithms. Good signals at the senior level:

"How would you design a system that [domain-relevant scenario]? Let's start with requirements." (Tests: scoping, systems thinking, communication)
"Here's a real code snippet from our codebase with a bug I've introduced. How would you investigate it?" (Tests: debugging, production thinking, communication under uncertainty)
"Here's a design we shipped. What would you change if we needed to scale to 100× traffic?" (Tests: architecture, trade-offs, humility to critique existing design)

What you're looking for at the senior level:

Do they ask clarifying questions before jumping to an answer?
Do they name trade-offs explicitly?
Can they estimate? Do they reason about scalability?
Do they handle being wrong gracefully?
Do they communicate their thinking while working?

18.3 The debrief discipline

After every interview, write your feedback before the debrief meeting. Post-meeting feedback is contaminated by anchoring to others' opinions. Your structured feedback:

Signal: [Strong No / No / Lean No / Lean Yes / Yes / Strong Yes]

Technical signal: [specific observations about code quality, design judgment, communication]
Example: "Proposed using a distributed lock for idempotency in the write path.
When I asked about lock contention at scale, they thought through it clearly
and recognized the limitation. Good system thinking."

Behavioral signal: [specific observations about communication, collaboration, ambiguity handling]
Example: "Asked two good clarifying questions before starting.
Recovered well when I challenged their initial design. No ego."

Gaps: [specific areas to probe if they advance or that concern you]
Example: "Never mentioned testing or observability unprompted. Worth probing in final round."

Decision rationale: [why your signal is what it is]

Debrief feedback that says "smart person, would hire" contributes nothing to the team's calibration. Debrief feedback with the structure above raises the whole team's hiring quality.

19. 🏢 Navigating Org Politics & Visibility

"Politics" is often treated as a dirty word by engineers. It isn't. Org politics is simply the dynamics of a group of people with different incentives, incomplete information, and limited resources making decisions together. Senior engineers who understand this make better decisions and have better careers.

19.1 Visibility is not bragging

The single most career-limiting behavior at the senior level is doing great work quietly. In a company of > 20 people, nobody except your direct team knows what you built last quarter unless you tell them.

The senior engineer's visibility habits:

Write a brief, weekly update (3–5 bullets) in your team's async channel. This costs 5 minutes and builds a trail of evidence for your annual review.
Present your work. Every major project should have a 10-minute "what we built and why" presentation in a team meeting or an eng all-hands.
Tag stakeholders on milestones. When a major feature ships: "@[PM] @[EM] — [feature] is live. Here's the monitoring dashboard. First 24 hours look good."
Write the internal tech blog post. An interesting engineering problem solved? A 500-word internal post about what you learned is visible to your entire org.

None of this is bragging. It is communicating your work to people who need to understand it in order to make good decisions (promotions, project assignments, team structure).

19.2 Building technical credibility across teams

Senior engineers who only have credibility on their own team are limited in the scope of problems they can influence. Cross-team credibility comes from:

Participating in org-wide architecture reviews — even when your system isn't under discussion.
Responding thoughtfully to public technical questions — in your internal engineering Slack, when someone asks a hard question, be the person who writes the careful, nuanced answer.
Helping outside your team — when another team has a problem you have context on, help. The social capital created vastly exceeds the 2 hours you spent.
Writing docs that the whole org uses — the database performance guide you wrote for your team that everyone in the org now references.

19.3 Navigating disagreement with more senior engineers

The hard situation: you believe a senior/staff/principal engineer is making a wrong technical call, and you have less organizational standing.

The approach:

Understand their position deeply first. "Before I push back, let me make sure I understand: your concern is X, and your reason is Y — is that right?" Misunderstanding is the most common root of technical disagreement.
State your concern specifically. "My worry is that [design choice] will [specific consequence] when we hit [specific scenario]. Am I wrong about that consequence?"
Bring data, not opinions. "I benchmarked both approaches; at 10K RPS, approach A has 40% higher p99 latency. Here's the flamegraph."
Accept the decision if your concern was heard. Being heard is different from being agreed with. You can disagree and commit. "I understand the decision; I still have concerns about [X], but I'm committed to making this design work."
Document your disagreement. An ADR with "alternatives considered" that includes your rejected option, and why it was rejected, is permanent record. If it turns out you were right, the record exists.

19.4 Cross-functional influence

Senior engineers gain influence over product decisions through technical data, not through authority or stubbornness:

Use technical facts to reframe prioritization. "The PM wants to build feature X. The auth service rewrite enables both X and Y and reduces our incident rate by ~50%. Here's the data. Should we reconsider the order?"
Create technical constraints in the design phase, not the build phase. "This feature requires [performance property] that will take an extra sprint to build correctly. I'd rather flag it now than discover it at code review."
Say no precisely and constructively. "We can't build that in 2 sprints safely. We can build [smaller scope] in 2 sprints, or the full thing in 5. Which serves the Q3 goal better?"

20. ⚠️ The Senior Engineer Anti-Pattern Catalog

Every senior engineer falls into at least one of these. The self-aware ones notice it and fix it.

Anti-pattern 1: The Brilliant Jerk

The behavior: Technically excellent; contemptuous of others' code; dismissive in reviews; right most of the time; hard to work with all of the time.

Why it happens: Early career success with technical skills without corresponding investment in communication and empathy. The team tolerates it because the output is high quality. The org tolerates it because the cost is invisible until it becomes an attrition problem.

The cost: Every junior engineer on the team who could have stayed and grown instead leaves. The Brilliant Jerk is a net negative on team throughput when you count the attrition and the culture damage, even if their personal output is exceptional.

The fix: Reframe code review as teaching, not judgment. Assume good intent in the code you read. Ask "why did they do this?" before "this is wrong."

Anti-pattern 2: The Absent Expert

The behavior: Knows the system best; shares knowledge rarely; reviews PRs when they feel like it; doesn't write docs; their expertise is a black box.

Why it happens: Introversion, time pressure, or the belief that "good code speaks for itself." Sometimes a side effect of being the most productive person on the team — they're always in demand, always context-switching.

The cost: Bus factor of 1. The system can't evolve without them. The team can't operate without them. On-call is a disaster when they're on vacation. They become the bottleneck that slows down the whole team.

The fix: Write the runbook. Pair with someone on the scary service. Schedule the tech talk. Not because someone asked — because the team depends on it.

Anti-pattern 3: The Eternal Perfectionist

The behavior: PRs take weeks to land because every detail must be perfect. Code is pristine, but velocity is low. Refactors scope-creep. Ships are rare; quality is unmistakably high.

Why it happens: High standards without an understanding of trade-offs. The engineer conflates "high quality" with "maximum quality" and doesn't distinguish "good enough for now" from "good enough forever."

The cost: Features ship late. Partners miss deadlines. The perfect system is built for a product that has moved on. Organizational trust erodes because commitments aren't met.

The fix: Define "done" explicitly before starting. Ship the 80% version with clear documentation of what was deferred. Internalize that a shipped good-enough system creates more value than an unshipped perfect one.

Anti-pattern 4: The Lone Wolf

The behavior: Works alone. Doesn't ask for help. Submits massive PRs after weeks of silent building. Surprised when the design was wrong and needs significant changes.

Why it happens: IC identity, introversion, or a bad experience with collaborative design being slowed down by committee. Sometimes also the belief that asking for help shows weakness.

The cost: Design errors discovered at PR time are expensive. Massive PRs are hard to review. The engineer is under-leveraging the team's knowledge. Their bus factor is permanent.

The fix: Draft PRs early (after day 1 of work). One-page design doc before starting anything > 3 days. Regular check-ins that aren't status reports — "here's where I am, does anything look wrong to you?"

Anti-pattern 5: The Ticket Monkey

The behavior: Takes tickets, executes them precisely, closes them. Does great work. Asks no questions about the goal. Makes no suggestions about better approaches. Never pushes back. Does exactly what was asked.

Why it happens: Optimization for approval. "Complete tickets" is the measurable output; "raise the right concerns" is invisible and may cause friction.

The cost: The team builds wrong things efficiently. The senior engineer is operating at mid-level scope. They accumulate years of experience without developing engineering judgment.

The fix: Before every ticket: "Is this the right thing to build?" After every sprint: "Is there something we should be building that's not in the backlog?"

Anti-pattern 6: The Architecture Astronaut

The behavior: Every problem is a distributed systems problem. Every service needs Kafka. Every feature needs an abstraction layer. Every data store needs a cache. Code reviews focus on theoretical scalability at 1M users for a system with 100 today.

Why it happens: Sophisticated technical knowledge without business context. Sometimes: the desire to work on interesting systems rather than the systems the business needs.

The cost: Massive complexity increases with no business payoff. Onboarding takes weeks. Systems are fragile in unexpected ways. Future engineers spend months understanding abstractions that never paid off.

The fix: Every architectural decision should have a business-context rationale. "We need Kafka here because [current problem or concrete future scenario]" is acceptable. "We should use Kafka here because it's more scalable" is not.

Anti-pattern 7: The Yes Machine

The behavior: Always says yes to scope, always agrees in planning, always commits to aggressive deadlines. Never pushes back on requirements. Consistently misses deadlines or ships under-tested features.

Why it happens: Fear of disappointing stakeholders. Social pressure in planning meetings. Optimism about one's own velocity.

The cost: Trust erosion. The PM learns to expect 60% of what was promised and multiplies estimates by 2. The engineer burns out on the heroics required to deliver.

The fix: The credible senior engineer says "I don't have enough information to estimate this right now" when that's true. Accurate-but-long estimates build more trust than optimistic-and-wrong ones.

21. 🗺️ The Phased Roadmap (Year 1 → Staff)

A rough guide. Paths vary widely by company, domain, and individual. Use this as a frame, not a schedule.

Year 1 as Senior: Establish

Milestones:

Complete the 90-day orientation (§4).
Own one system end-to-end (operational, quality, roadmap ownership).
Write at least 2 design docs that were adopted.
Onboard one junior/mid engineer on a system you own.
Complete at least 3 months of on-call with clean execution.

Key habits to establish:

Weekly proactive system health communication.
Code review batch discipline (review at scheduled times, not on demand).
Deep work block protection (10+ hours/week).
Debt register maintained.

Risks to watch:

Scope too narrow — only touching one service. Expand now.
Invisible impact — doing good work nobody knows about. Start the weekly update habit.

Year 2 as Senior: Expand

Milestones:

Take on a project with significant cross-team dependencies.
Mentor a junior engineer from "writes code" to "owns tickets independently."
Contribute to your first architecture decision that affected more than your team.
Drive a meaningful tech debt reduction with a measurable outcome.
Have the Staff-level growth conversation with your manager.

Key habits to develop:

External signal: tech talk, blog post, or open-source contribution.
PM partnership: be in the room during product planning, not just sprint planning.
ADR writing: capture every significant design decision.

The inflection test at 18 months: Can you describe 3 things in the past year that made engineers other than yourself significantly more effective? If yes, you are operating at the multiplier level. If no, you're still at the builder level.

Year 3+ (Senior → Staff): Demonstrate

The Staff bar is met by consistently demonstrating Staff behaviors, not by waiting for the title. The three demonstrations:

Own a multi-team technical problem: "I identified that teams A, B, and C had divergent approaches to [authentication/data modeling/error handling]. I proposed a unified standard, got buy-in from all three tech leads, wrote the RFC, and it's now adopted."
Create leverage that survives you: "I wrote the platform library that 4 teams now depend on. I wrote the operational guide that cut on-call incident time from 90 min to 20 min. I trained 3 engineers who now independently own complex systems."
Operate in high ambiguity: "The business goal was 'reduce enterprise churn.' I translated that into a technical root cause analysis, proposed a 3-quarter engineering roadmap, and drove it to delivery without a tech lead telling me what to do."

22. 📋 Cheat Sheet & Resources

The senior engineer's daily checklist

Morning (5 min):
  □ Any production alerts I should know about?
  □ Any PRs awaiting my review that are blocking someone?
  □ Any blockers I should surface today?
  □ What's my one deep-work goal for today?

End of day (5 min):
  □ Is my work visible? Did anything important happen that stakeholders should know?
  □ Did I leave any open threads or blockers unaddressed?
  □ Did I do at least one review?
  □ Did I have at least 3 hours of deep focus?

The senior engineer's weekly checklist

Monday:
  □ Set 3 outcomes for the week
  □ Check system health metrics
  □ Review team standup board for cross-team blockers

Thursday/Friday:
  □ Weekly 3-bullet status update posted
  □ Debt register updated if anything changed
  □ Open PRs ready for merge or clearly unblocked
  □ Any decisions made this week documented as ADR/Slack thread

The career growth checklist (quarterly)

  □ Can I name 3 things I shipped in Q[n] with measurable impact?
  □ Can I name 1 engineer who grew because of something I did?
  □ Can I name 1 cross-team influence I had?
  □ Is my system health better than it was 3 months ago?
  □ Did I create any artifact that will survive me? (doc, runbook, library)
  □ Have I calibrated with my manager on the Staff bar this quarter?

The 10 mental models for senior engineers

Systems thinking: every change has second-order effects. Find them before you ship.
Trade-off thinking: there is no best solution, only the best trade-off for this context.
Reversibility thinking: reversible decisions should be made quickly; irreversible ones should be made carefully.
Bottleneck thinking: the constraint is the only thing worth optimizing. Find the actual bottleneck before writing the fix.
Blast radius thinking: when this fails, what else fails? Minimize coupling.
Bus factor thinking: am I a single point of failure? What happens if I disappear?
Incentive thinking: why is this system built the way it is? Follow the incentives that produced it.
Time horizon thinking: is this the right decision for the next sprint? Quarter? Year? They often conflict.
Legibility thinking: can a future engineer understand why this code was written? Optimize for that engineer.
Compounding thinking: the 30-minute runbook you write today saves 30 minutes every incident for the next 3 years. Do the math.

Canonical resources

Books:

A Philosophy of Software Design — John Ousterhout (the clearest treatment of complexity and abstraction)
Designing Data-Intensive Applications — Martin Kleppmann (essential for backend and distributed systems engineers)
The Pragmatic Programmer — Hunt & Thomas (still the best craft book after 25 years)
An Elegant Puzzle — Will Larson (best book on engineering growth and organizations)
Deep Work — Cal Newport (the operating model for protecting focus)
The Staff Engineer's Path — Tanya Reilly (the definitive guide to the Senior → Staff transition)
Accelerate — Forsgren, Humble, Kim (the data behind engineering team performance)

Articles / Essays:

"The Senior Engineer Checklist" — Charity Majors, charity.wtf
"On Being a Senior Engineer" — John Allspaw (kitchensoap.com)
"Staff Engineer archetypes" — Will Larson (staffeng.com)
"What I Think About When I Edit" — Zinsser (applies to code as much as prose)
"The Grug Brained Developer" — grugbrain.dev (the case against complexity)

In the 2026 context:

GitHub Copilot and Claude Code documentation — the meta-skill is prompting well, not prompting fast
Your own postmortems — the most valuable technical reading you can do is your team's own failure history

The one-page summary

┌────────────────────────────────────────────────────────────────┐
│             SENIOR ENGINEER: THE ONE-PAGE SUMMARY              │
├────────────────────────────────────────────────────────────────┤
│                                                                 │
│  WHAT YOU OWN                                                   │
│  ├── System health (metrics, debt, incidents)                   │
│  ├── Project execution (scoping → delivery → comms)             │
│  ├── Code quality on your team (review, standards, craft)       │
│  └── Team knowledge (docs, mentorship, bus factor)              │
│                                                                 │
│  HOW YOU WORK                                                   │
│  ├── Deep work blocks: 10+ hrs/week, protected                  │
│  ├── Reviews: batched, 24-hr SLA, teaching-oriented             │
│  ├── Comms: proactive, no surprises, written first              │
│  └── AI: strategic tier (design, risk, docs), verified          │
│                                                                 │
│  HOW YOU GROW                                                   │
│  ├── Widen scope: cross-team projects, shared problems          │
│  ├── Create artifacts: design docs, ADRs, runbooks, posts       │
│  ├── Build signal: talks, writing, open source, mentorship      │
│  └── Have the conversation: explicit Staff path with manager    │
│                                                                 │
│  THE ANTI-PATTERNS                                              │
│  ├── Brilliant Jerk: right but toxic                            │
│  ├── Absent Expert: knows everything, shares nothing            │
│  ├── Eternal Perfectionist: ships nothing                       │
│  ├── Lone Wolf: never collaborates                              │
│  ├── Ticket Monkey: executes without thinking                   │
│  ├── Architecture Astronaut: over-designs for current scale     │
│  └── Yes Machine: never pushes back, always misses deadlines    │
│                                                                 │
│  THE NORTH STAR QUESTION                                        │
│  "Did the team ship better, faster, and more sustainably        │
│   because I was here this quarter?"                             │
│                                                                 │
└────────────────────────────────────────────────────────────────┘

Companion documents: 🧑‍💻 The Tech Lead Playbook: From Best IC to Multiplier 🚀 · cto_playbook.md · 🚀 The SaaS Template Playbook 📖 · 🏗️ Building High-Quality AI Agents 🤖 — A Comprehensive, Actionable Field Guide 📚