Section 04 Flashcards — Managing Technical Quality
flashcards selt technical-quality
What is the core principle behind the “staircase of interventions” for technical quality?
?
Start with the cheapest, most targeted intervention first. Escalate to more expensive org-wide programs only when lighter approaches have been exhausted. A premature quality program is bureaucracy; a hot spot fix is often sufficient.
What is the first and cheapest intervention in the quality staircase?
?
Fix hot spots. Profile the codebase to find where most bugs, incidents, and failures actually occur, then fix those specific locations first. Example: delete the one test file causing 98% of failures.
What is the “performance engineer’s mindset” and when should you apply it?
?
Find the actual bottleneck rather than optimizing everything. Don’t spread effort evenly — identify the one place where 90% of the pain lives and fix that. Apply it first, before considering broader systemic changes.
What is the “systems thinking mindset” and when does it complement hot spot fixing?
?
Understanding root causes: why does the hot spot keep regrowing? What upstream force keeps generating low-quality work? Apply it when the same hot spots recur after fixing, indicating a systemic cause rather than a local one.
What book does Larson cite as the evidence base for technical best practices, and who wrote it?
?
“Accelerate” by Nicole Forsgren, Jez Humble, and Gene Kim. It provides evidence-based research showing which engineering practices improve both velocity and stability.
Name the five key practices from Accelerate that Larson highlights for technical quality.
?
- Version control (all code, config, and infrastructure)
- Trunk-based development (short-lived branches, frequent integration)
- CI/CD (automated build and deployment pipelines)
- Production observability (logging, metrics, tracing)
- Small atomic changes (smaller PRs, smaller deploys)
What is trunk-based development and why does it improve quality?
?
Development where branches are short-lived and integrated frequently into the main trunk. It avoids merge hell, reduces integration risk, and forces small changes that are easier to review and roll back.
Why does mandating best practices often fail, and what does Larson’s Scrum anecdote illustrate?
?
Mandating without demonstrating value produces compliance theater. In the anecdote, a company adopted Scrum rituals (standups, sprints, retrospectives) but the actual engineering work didn’t change. Ceremonies were adopted; practices weren’t. Real adoption requires demonstrating value and letting teams adapt.
What are the three “leverage points” for technical quality investment and why do they warrant extra attention?
?
- Interfaces — durable contracts between systems; bad design affects every consumer
- Stateful systems — hardest to change; data shape, schema migrations, backward compatibility
- Data models — choices constrain every layer above them; a bad model forces workarounds everywhere
Why do stateful systems deserve disproportionate investment?
?
State is the hardest thing to change. Once production data exists in a shape, altering that shape is expensive, risky, and slow. Bugs in stateless code are annoying; bugs in stateful code can corrupt data permanently.
Why do interfaces deserve disproportionate investment?
?
Interfaces are contracts between systems. A well-designed interface hides accidental complexity and allows implementation to evolve without breaking consumers. A poorly designed interface locks in bad decisions for years, and every caller inherits the pain.
Why do data models deserve disproportionate investment?
?
Data model choices constrain everything downstream — API shape, business logic, UI. A poor data model forces workarounds in every layer above it. Data models also tend to outlast the engineers who designed them.
What are “technical vectors” and what problem do they solve?
?
Technical vectors are the directions teams are moving in their technical decisions. When teams move in contradictory directions, integration costs, onboarding friction, and operational complexity increase. Aligning vectors means teams can work independently but their work integrates coherently.
Name four ways a Staff engineer can align technical vectors across teams.
?
- Document intended direction — make implicit norms explicit in writing
- Make the right thing easy — templates, shared libraries, scaffolding, approved patterns
- Nudge through code/design review — redirect outliers gently, don’t block
- Model the behavior — write code that follows the patterns you’re advocating for
What is the difference between technical vector alignment and technical uniformity?
?
Alignment means teams can work independently and their work integrates coherently — not that everyone uses identical tools. Uniformity is rigid and stifles appropriate local variation. Alignment preserves autonomy while ensuring coherence at integration points.
What are examples of metrics that proxy for technical quality?
?
- Defect rates (bugs per release, incidents per quarter)
- Test coverage (with skepticism)
- Build and deploy reliability (pipeline pass rates)
- Change failure rate (deploys causing incidents)
- Mean time to restore (MTTR)
- Tech debt age (how long known issues go unaddressed)
Why should you track trends in quality metrics rather than absolute numbers?
?
Metrics can be gamed. Teams can improve a metric without improving actual quality (e.g., writing tests just for coverage without testing meaningful behavior). Trends over time, combined with qualitative signals, reveal genuine improvement or deterioration.
What is a “change failure rate” and where does this metric come from?
?
The percentage of production deployments that cause incidents or require rollback. It is one of the four key metrics from the Accelerate research (alongside deployment frequency, lead time for changes, and mean time to restore). A lower change failure rate indicates higher deployment quality.
When does a dedicated technical quality team make sense, and when does it become a problem?
?
It makes sense at sufficient org scale — when many product teams exist and investing in shared tooling, libraries, and infrastructure pays off across them. It becomes a problem when the org is small: the quality team becomes a bottleneck, creating dependency rather than leverage.
What does a technical quality team typically own and build?
?
- Shared linters, static analysis tooling, and formatters
- Shared libraries and frameworks
- Internal platforms (build systems, CI infrastructure, deploy tooling)
- Architecture and design review processes at scale
When is launching an org-wide quality program appropriate, and what does it require?
?
Appropriate at large scale when voluntary adoption has stalled and lighter interventions have been exhausted. Requires executive sponsorship, clear metrics tied to real outcomes, defined quality standards, and explicit ownership. Risk: becomes compliance theater if not grounded in real outcomes.
What is the failure mode of jumping directly to a quality program?
?
Creating overhead that slows teams without delivering proportional value. An org-wide program is the most expensive intervention in the staircase. If lighter approaches (hot spot fixes, practice adoption, leverage point investment) haven’t been tried, the program adds bureaucracy without addressing root causes.
Under what three conditions does mandating process actually work?
?
- Strong leadership alignment and enforcement
- Costs of non-compliance are clear and immediate
- The practice is simple enough to follow prescriptively
Most technical quality practices don’t meet these conditions, making persuasion and demonstration more effective.
What is the difference between a quality intervention that addresses a hot spot versus one that addresses a leverage point?
?
Hot spot intervention: targeted fix where the most pain currently exists — fast, cheap, directly reduces immediate harm.
Leverage point intervention: investment in interfaces, stateful systems, or data models — slower, more expensive, but prevents future pain by improving the areas hardest to change later.
What anti-pattern does the performance engineer’s mindset guard against?
?
Spreading effort evenly — refactoring the whole codebase instead of fixing the three files that matter. Uniform investment ignores that quality problems are typically concentrated in a small fraction of the codebase.
If the same hot spots keep regrowing after being fixed, what should a Staff engineer do differently?
?
Shift from the performance engineer’s mindset to the systems thinking mindset. Ask what upstream force keeps generating the problem. The recurring hot spot is a symptom; identify and address the root cause (bad hiring, no code review, excessive pressure, missing practice adoption).
Why is “making the right thing easy” a more effective quality lever than code review enforcement?
?
People follow the path of least resistance. If templates, scaffolding, and shared libraries make the correct approach the default path, teams naturally write higher-quality code without requiring enforcement. Review enforcement adds friction without changing the underlying ease of doing the wrong thing.
Total Cards: 27
Review Time: ~20 minutes
Priority: HIGH
Last Updated: 2026-05-30