Study Notes by Niladri & AI

ch07-role-model

10 min read

Chapter 7: You’re a Role Model Now (Sorry)

tsep role-model competence responsibility leadership behavior culture

Status: Notes complete

Overview

Chapter 7 opens Part III: Leveling Up. The central argument: staff engineers shape their organization’s culture through their behavior, whether they intend to or not. Junior engineers watch what senior engineers do and conclude that’s what a senior engineer does. If you ship poorly tested code, you’re setting a norm. If you rubber-stamp code reviews, others will too. If you ask “obvious” questions in meetings, others learn it’s safe to do the same.

This chapter covers the passive, ambient influence a staff engineer has just by being present and working. Chapter 8 covers the active, deliberate influence. Chapter 7 is about what you can’t opt out of — your behavioral model.

The chapter identifies four aspirational attributes of a senior engineer:

  1. Be Competent
  2. Be Responsible
  3. Remember the Goal
  4. Look Ahead

Core Concepts

Passive influence: The effect your behavior has on organizational norms without any explicit intention to influence. How you work is how others will work.

Radiating intent: The practice of signaling what you’re about to do before doing it. Provides context, creates opportunity for intervention, and keeps responsibility with the actor (vs. seeking permission, which transfers responsibility to the approver).

CYAE (Cover Your Ass Engineering): Avoiding accountability by deflecting blame: “I built it to spec; I can’t be responsible for their mistakes.” The opposite of ownership.

Glue work: The coordination, onboarding, reminder, blocking, and mentoring work that keeps projects running but isn’t on anyone’s job ladder. Tends to fall to whoever can’t look away from the problem — often junior engineers, who need that time for technical growth.

Feigned surprise: The culture-toxic behavior of expressing shock at someone’s ignorance: “You’ve never used X?!” It shuts down learning and signals that not-knowing is shameful.

Institutional memory: The accumulated knowledge about how systems work and why decisions were made. Lives in documentation, code comments, and people — leaves when people leave.

Attribute 1: Be Competent

Know Things

Technical competence is not optional for a technical leader. Without it, credibility and influence evaporate.

Build experience: Technical skills come from time, exposure, and practice — not innate talent. Stephanie Van Dyk’s weaving analogy: no one is born skilled; practice makes competence. Aim to internalize skills so deeply that you can focus on what’s happening around you rather than your own execution.

Build domain knowledge: Software has many sub-domains. Moving into a new one means being a beginner again. When you do:

  • Learn the trade-offs, resource constraints, and common arguments in the domain
  • Know who the “famous people” are and what they advocate
  • Read the core literature
  • Take on projects that build instinct

Stay up to date: A senior engineer who insists on a “best practice” that was debunked a decade ago damages their credibility and the team. Maintain enough engagement with the field to avoid this. Know how to find out what you don’t know.

Be Self-Aware

Admit what you know: Don’t undersell your expertise out of false modesty. When a skill is needed, volunteer that you have it.

Admit what you don’t know: Bluffing has two costs: you don’t learn, and you model that not-knowing is shameful. ELI5 (“Explain it like I’m 5”) is a useful shortcut for “I want you to assume nothing about my prior knowledge.”

Understand your context: Your perspective is not the universal perspective. When talking to other teams or to non-engineers, you know what they might not — bridge that gap explicitly.

Have High Standards

Your work sets the implicit bar. Write clear documentation. Know when your software breaks. Seek constructive criticism — your solutions are not you; criticism of your work is not criticism of you.

Own your mistakes: React well when things go wrong. Admit what happened, fix it, communicate clearly, don’t deflect. Owning mistakes builds more trust than never making them.

Be reliable: The biggest compliment: “Alex will be in that meeting, so I don’t need to go.” Be the kind of person who can be counted on to handle a situation well. Finish what you start.

Attribute 2: Be Responsible

Take Ownership

Ownership means:

  • The problem is yours, not someone else’s to solve
  • You don’t wait for permission to act
  • You use good judgment autonomously
  • You take accountability for the result, including when it goes wrong

Radiate intent (Elizabeth Ayer): Signal what you’re about to do before you do it. This is different from asking permission — you’re informing, not requesting approval. If someone objects, great. If not, you proceed. And if it goes wrong, you keep the responsibility.

Contrast with CYAE: deflecting accountability by pointing to a spec, a requirement, or another person’s decision. This destroys trust.

Make decisions: When a decision is needed, make it. Weigh options, choose decisively, explain your reasoning. Staying on the fence is not safe — it delays the whole project and models indecision for others.

Ask obvious questions: Senior engineers can ask the questions nobody else is willing to ask. “Have you run this by security?” “What happens when users depend on this field you want to deprecate?” These questions establish a norm that explicit consideration of non-obvious concerns is expected.

Don’t delegate through neglect: If vital glue work is being done by junior engineers who need that time for technical growth, take ownership of it and redirect them. Glue work counts as leadership when a staff engineer does it; it stalls careers when junior engineers do too much of it.

Take Charge

Step up in emergencies: When chaos arrives (outage, breach, production incident), step up as coordinator. Coordination only works if everyone knows who is coordinating. Announce it explicitly. Use a structure like the Incident Command System. Take notes; ensure everyone has the same context; ask others to radiate their intent.

Ask when confused: During an emergency, ask the question nobody else is willing to ask: “I don’t know what to do with that information.” Providing psychological safety for not-knowing is especially critical when time pressure creates ego-protection behaviors.

Drive meetings: If a meeting lacks direction, step up. Ensure there’s an agenda. Drag the conversation back when it drifts. Take notes — this is high-status work when a senior person does it; it’s the kind of “framing” that shapes how decisions are understood and recorded.

If you see something, say something: When something disrespectful happens in a group, you have the social capital to address it. Address it publicly (same venue where it happened). You don’t need to say the perfect thing; you need to say something. The adrenaline doesn’t go away; you just accept the discomfort.

Create Calm

Defuse, don’t amplify: Make problems smaller, not bigger. Stay calm. A senior person making a fuss turns a minor thing into a major incident. Ask questions before reacting.

Don’t share anxiety downward: You can share worries with your manager, peers, or sounding board — not with junior team members who can’t do anything about them and will just be stressed.

Avoid blame: Blame creates environments where people hide mistakes. Curiosity creates environments where mistakes become learning. Ask “what happened?” and “what factors led to this?” instead of “who’s fault was this?”

Be consistent: Don’t be the wild-card leader who can’t be predicted. Consistency lets your team trust you, especially during change. This requires self-care — you can’t be consistent when you’re overextended.

Attribute 3: Remember the Goal

There’s a Business

You work for an organization with goals. The software is a means to those ends.

Adapt to the situation: Sometimes quick and dirty is the right choice. A hackathon is not the place for comprehensive tests. An outage is not the place for a clean rolling restart. Use judgment about when best-practice trade-offs apply.

Budget exists: Engineering standards are in tension with what the organization can afford. Know whether you’re in good times or lean times. Factor this into what you propose.

Spend resources mindfully: Headcount is finite and has opportunity cost. “Innovation tokens” (Dan McKinley) are limited. Build what the business needs, not what would be most fun to build.

There’s a User

Know who uses your software and how they actually use it. Don’t build for a fictional perfect user. Get requirements reviewed before coding; show mockups before building. “Nobody wants to use software — they want to catch a Pokémon.”

There’s a Team

You’re not doing this alone, even if you’re the most capable person in the room. Don’t become a single point of failure. Consider your impact to be what wouldn’t have happened without you, not just what you personally did.

Attribute 4: Look Ahead

Anticipate

Telegraph what’s coming: Announce intentions even before plans are fully formed. “We intend to deprecate X in 18 months” — this alone changes how new work is planned and can accelerate voluntary migrations.

Tidy up: Leave environments, codebases, and documentation better than you found them. No hidden traps. Working examples. Code that it’s safe to copy.

Keep tools sharp: Invest in build speed, deploy pipelines, flaky test elimination. Every minute shaved from the detect-and-deploy cycle is a minute off every future outage.

Create institutional memory: Write things down — decision records, system diagrams, code comments with context. Use searchable keywords. Think about what future engineers will need to know that “everyone knows today.”

Expect Failure

Build failure into your model from the start:

  • Test error paths as thoroughly as success paths
  • Know when your systems aren’t behaving (monitoring, alerting)
  • Have response plans before you need them (incident command, playbooks)
  • Simulate disasters before they happen (chaos engineering, game days, tabletop exercises)
  • If you haven’t tested restoring backups, assume you don’t have backups

Optimize for Maintenance, Not Creation

Software is created once; it’s maintained for years. Every compliance change (Y2K, GDPR, IPv6, HIPAA) forces everyone to care about old code they’d rather not touch.

Make it understandable: A system is most understood on the day it’s created; that knowledge decays daily. Write documentation with a future reader in mind. Make the system observable (easy to inspect, trace, and debug).

Keep it simple: “Any fool can write code a computer understands. Good programmers write code humans can understand.” Complexity is a cost, not a feature. Spend time finding the simpler solution.

Build to decommission: Someday this system will be turned off. How hard will that be? Use clean interfaces. Keep systems decoupled enough that they can be replaced. If you wouldn’t want to decommission it yourself, you’ve probably not built it well.

Create Future Leaders

Give junior engineers room to grow. Hand off projects that you could do faster yourself. Future senior engineers need hands-on experience solving progressively harder problems. Your value is multiplied, not reduced, when you develop the people around you.

Final quote (John Allspaw): “The degree to which other people want to work with you is a direct indication of how successful you’ll be in your career as an engineer. Be the engineer that everyone wants to work with.”

Key Takeaways

  1. Staff engineers set culture through behavior, whether they intend to or not.
  2. Competence requires building experience, self-awareness, and high standards — and owning mistakes.
  3. Responsibility means taking ownership (not CYAE), taking charge when needed, and creating calm.
  4. Radiate intent: signal what you’re about to do; keep accountability with yourself.
  5. Remember: there’s a business with budget constraints, a user with real needs, a team you’re not alone in.
  6. Look ahead: telegraph changes, tidy up, create institutional memory, expect failure, build for maintenance.
  7. “The degree to which other people want to work with you” is the success metric.

Graph View

Backlinks