Chapter 7 Flashcards — You’re a Role Model Now (Sorry)
flashcards tsep role-model competence responsibility culture
What are the four aspirational attributes of a senior engineer described in Chapter 7?
?
- Be Competent — build knowledge and skills; be self-aware about what you know and don’t; have high standards
- Be Responsible — take ownership; take charge; create calm
- Remember the Goal — know there’s a business, a user, and a team you’re not alone in
- Look Ahead — anticipate consequences; expect failure; optimize for maintenance; create future leaders
What is “radiating intent” and how does it differ from seeking permission?
?
Radiating intent (Elizabeth Ayer) is the practice of signaling what you’re about to do before you do it. You’re informing, not requesting approval. If someone objects, great — you can adjust. If not, you proceed. The key difference: seeking permission transfers responsibility to the approver. Radiating intent keeps responsibility with you, the person taking the action. It’s transparent without being deferential.
What is CYAE and why is it the opposite of ownership?
?
CYAE (Cover Your Ass Engineering) is deflecting accountability by pointing to a spec, a requirement, or another person’s decision: “I built it to spec; I can’t be responsible for their mistakes or improper specification.” It’s the opposite of ownership because it treats your role as executing instructions rather than owning outcomes. Senior engineers take accountability for results, including when requirements were underspecified or when something you reviewed turned out to be wrong.
What is “glue work” and why does it matter who does it?
?
Glue work is the coordination, onboarding, reminder, documentation, blocking, and mentoring work that keeps projects running but isn’t on anyone’s job ladder. It tends to fall to whoever can’t look away from the problem — often junior engineers. The problem: when junior engineers do too much glue work, they spend their prime technical learning years in ways that don’t build technical skills, which can stunt their careers. Senior engineers should own glue work themselves and redirect junior colleagues to technical growth opportunities.
What is “feigned surprise” and why is it harmful to team culture?
?
Feigned surprise is expressing shock at someone’s ignorance: “You’ve seriously never used X?” It shuts down learning by signaling that not-knowing is shameful. People who are afraid of being caught not-knowing make poker faces, avoid asking questions, and learn much more slowly. The antidote: when someone apologizes for asking a basic question and there’s a chorus of “actually that’s a great question,” culture is built.
What does “be consistent” mean for a staff engineer and why does it require self-care?
?
Being consistent means your colleagues can predict how you’ll behave. They know what level of detail you’ll care about, what principles you’ll hold, and how you’ll respond under pressure. This creates psychological safety — especially during change. Consistency requires self-care because it’s impossible to be consistent when overextended or burned out. You model sustainable work for others; their interpretation of “what’s normal” is based on what you do.
What is the key principle for avoiding blame during incidents and why does it help?
?
Replace blame with curiosity: ask “What happened?” and “What factors led to this?” instead of “Whose fault was it?” A blame-free environment makes people willing to surface mistakes and near-misses quickly, which leads to faster resolution and better learning. A big outage is “an expensive training course” — you’d better get the learning if you’re paying the cost. Leaders who own their own mistakes model this most effectively.
What are the two ways to make a system understandable for future maintainers?
?
- Education and hands-on experience — continual training so everyone who might work on the system is fully competent. Hard to scale.
- Documentation and observability — make the system as easy as possible to understand when someone needs it: clear introduction, a simple diagram with data-flow arrows, links to relevant resources, and full observability (tracing, status messages, easy-to-inspect internals). This is the more scalable approach.
Why does “build to decommission” lead to better architecture generally?
?
Imagining that you personally will need to decommission this component in 10 years forces you to think about: clean interfaces, visibility into who uses the system, modularity, and keeping distance between integrated systems. These constraints happen to be the same constraints that make a system easy to maintain, replace, and reason about. Building for clean decommission is a forcing function for good architecture.