Published khoảng 2 giờ trước 25 min read

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

MayFest2026

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

Section 1 -> 12 : Read Part 1 here https://viblo.asia/p/the-senior-software-engineer-playbook-from-good-coder-to-high-impact-engineer-part-1-1QLxnpRd4Aw

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. Today, 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 today'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 today:

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