Chapter 24 Flashcards — Making Teams Effective
flashcards fsa teams architect-soft-skills
Collaboration Spectrum
Q1: What are the two failure modes at the extremes of the architect collaboration spectrum?
A1: (1) Control-Freak extreme — architect controls every decision, becomes a bottleneck, demotivates developers. (2) Armchair extreme — architect is disconnected, teams diverge, reinvent decisions, and produce inconsistent implementations. The effective zone is engaged but not controlling.
Q2: Why does pure team autonomy (no architectural guidance) fail?
A2: Teams reinvent decisions already made by other teams, diverge from each other on shared concerns, and make locally optimal decisions that are globally sub-optimal (e.g., each team picks its own persistence technology, creating an operational nightmare).
Q3: Why does pure architectural control fail?
A3: The architect becomes a single-threaded bottleneck slowing delivery; developers are demotivated and stop exercising engineering judgment; the architect loses touch with implementation reality; developers never develop architectural reasoning skills.
Constraints vs Boundaries
Q4: What is the difference between an architectural constraint and an architectural boundary?
A4: Constraints define what must be true — non-negotiable requirements all implementations must satisfy (e.g., “all services must use the standard message broker”). Boundaries define what must not be done — guardrails preventing architectural drift (e.g., “do not add synchronous dependencies from Order to Inventory”). Constraints are positive requirements; boundaries are negative prohibitions.
Q5: What type of space exists between architectural constraints and boundaries, and who owns it?
A5: The creative space — the zone where developers have full autonomy to make implementation decisions. Architects who issue opinions on naming conventions, library choices within approved categories, or code style within this space are issuing implementation preferences, not architectural guidance.
Q6: How do you test whether something is an architectural concern or an implementation preference?
A6: If violating the rule only affects one team’s internal implementation and has no cross-team or system-wide impact, it is not an architectural concern — it belongs to team coding standards. Architectural concerns affect system-wide properties: security, interoperability, observability, operational consistency.
Three Architect Personalities
Q7: Describe the Control-Freak Architect and the primary driver behind this behavior.
A7: Reviews and approves every technical decision (library choices, naming, method signatures). Creates exhaustive standards documents covering sub-architectural concerns. Developers ask the architect before any technical choice. Often driven by insecurity — a fear that developer autonomy will reveal problems the architect cannot control. Outcome: delivery bottleneck, demotivated developers, reduced architectural robustness.
Q8: Describe the Armchair Architect and why their designs are often impractical.
A8: Produces architecture designs from a distance without consulting the implementing team. Makes technology decisions based on conference talks rather than team experience. Unavailable when teams hit implementation problems. Impractical because the architect makes wrong assumptions about implementation ease — they lack current knowledge of team capabilities and operational constraints. Developers eventually route around the architect.
Q9: What are the key observable behaviors of an Effective Architect?
A9: (1) Participates in code reviews to observe patterns and detect drift — not to police style. (2) Does occasional pair programming to maintain technical credibility. (3) Sets constraints and boundaries with rationale — explains why. (4) Runs architecture office hours. (5) Corrects drift without blame — “here’s the pattern we should follow” not “you did this wrong”. (6) Explicitly delegates implementation decisions.
Q10: What is the key distinguishing behavior of an Effective Architect vs. a Control-Freak?
A10: The Effective Architect explicitly categorizes decisions — distinguishing those that must be consistent system-wide (architectural) from those best made by the team closest to the problem (implementation) — and delegates the latter completely. The Control-Freak treats all technical decisions as architectural.
Elastic Leadership
Q11: What is “elastic leadership” in the context of architecture?
A11: The principle that the right level of architect involvement varies with context and should flex accordingly — more intensive during foundational decisions and high-risk phases, lighter during stable build phases. Architects should make their level of involvement explicit to the team to prevent confusion about when to involve the architect.
Q12: What three contextual factors determine how involved an architect should be?
A12: (1) Team maturity — new or unfamiliar teams need more scaffolding. (2) Project phase — foundational phases require intensive involvement; stable phases require less. (3) Architectural risk — high-risk decisions (new technology, cross-cutting security changes) justify more involvement; low-risk incremental features justify less.
Q13: What mechanism allows architects to reduce manual oversight without losing visibility into architectural compliance?
A13: Architecture fitness functions — automated tests that verify architectural constraints (e.g., no circular dependencies, no direct cross-domain database access, all services responding to health checks). These replace manual policing and run continuously in CI/CD pipelines.
Process Loss
Q14: Define Process Loss and give three causes.
A14: Process Loss is when team output is less than the sum of individual performances — the team produces less than its members would working independently. Causes: (1) too many meetings interrupting deep work without producing decisions, (2) unclear ownership — nobody knows who decides, so nothing gets decided, (3) analysis paralysis — endless evaluation without convergence.
Q15: What signals should an architect recognize as evidence of Process Loss on a team?
A15: (1) The same discussion recurs in every retrospective without resolution. (2) Work items sit “in review” for days without feedback. (3) Developers cannot make progress while waiting for an architectural decision that is not forthcoming. (4) Sprint velocity is consistently below team capacity estimates.
Q16: What should an architect do when they detect Process Loss?
A16: Identify the coordination mechanism that is failing and fix it — clarify decision ownership, unblock pending architectural decisions, establish lightweight decision protocols such as Architecture Decision Records (ADRs), and ensure every discussion produces a recorded outcome.
Pluralistic Ignorance
Q17: Define Pluralistic Ignorance and provide a concrete architecture example.
A17: Pluralistic Ignorance is a social phenomenon where everyone privately disagrees with a direction but publicly goes along because each person assumes they are the only dissenter. Architecture example: an architect proposes adopting a new technology; every developer has private concerns about timeline and team expertise, but each sees apparent agreement around them and says nothing — silent consensus forms on a decision nobody believes in.
Q18: Why is Pluralistic Ignorance considered dangerous for architecture decisions?
A18: The team executes a plan with no internal confidence it will work, producing half-hearted effort and quick abandonment at the first obstacle. It creates silent failure — the architecture fails and nobody is surprised, but the concerns were never raised. It is self-reinforcing: each occurrence teaches developers that dissent is not safe.
Q19: What are four concrete techniques to break Pluralistic Ignorance?
A19: (1) Create psychological safety — explicitly state and demonstrate that dissent is expected and valued. (2) Invite explicit dissent — “Before we finalize, I want to hear specifically what concerns people have” instead of “does everyone agree?” (3) Anonymous input mechanisms — pre-meeting surveys, written concerns before verbal discussion. (4) Normalize “I was wrong” — architect admitting previous decisions were mistaken signals that dissent is safe.
Q20: What is the key question that distinguishes the start of Pluralistic Ignorance from genuine consensus?
A20: Whether silence means agreement or means private disagreement combined with an assumption that everyone else agrees. Genuine consensus survives direct questioning — “what are your specific concerns?” Pluralistic Ignorance collapses under it: private concerns surface when people are explicitly invited to share them.
Three Checklist Types
Q21: What is the purpose of a Developer Code-Completion Checklist, and when is it used?
A21: Used by developers before marking a user story as done — it is a self-certification checklist that catches common omissions creating technical debt. Typical items: unit tests written, no new compiler warnings, security considerations reviewed, documentation updated, no hardcoded credentials, feature flags in place for partial releases.
Q22: What is the purpose of a Unit and Functional Testing Checklist, and what testing types does it cover?
A22: Ensures the test portfolio is complete rather than accidental — that all required test types exist for the codebase. Covers: unit tests (logic in isolation), integration tests (component interactions), contract tests (API compatibility), end-to-end tests (critical user journeys), performance tests (SLA-critical paths), security tests (input validation, authorization), and chaos/resilience tests (failure scenarios).
Q23: What is the purpose of a Software Release Checklist, and what category of failure does it prevent?
A23: Pre-release verification before deploying to production — prevents the class of failures that cause immediate post-deployment incidents. Critical items: all test suites pass in staging, rollback plan documented and tested, monitoring configured for new behaviors, database migrations are backward-compatible, on-call team notified.
Q24: Why is “rollback plan documented and tested” a critical item on the Release Checklist?
A24: If a deployment fails in production, the team needs to revert quickly and confidently. An untested rollback plan fails when needed most — the database migration may not be reversible, the old binary may not be compatible with the new schema, or the rollback procedure may be undocumented. Testing the rollback in staging verifies the escape route before it is needed.
Q25: What is the failure mode when checklists are used as “theater” rather than genuinely?
A25: Items are checked without being verified — boxes ticked without performing the underlying action. This provides false assurance: stakeholders believe quality gates have been applied; they have not. The failure mode produces incidents that the checklist was designed to prevent, while consuming the credibility of the checklist process. Lightweight automated verification is more reliable than manual attestation.
Providing Guidance
Q26: Why are code examples more effective than verbal instructions for establishing architectural patterns?
A26: Verbal instructions produce multiple interpretations — a team of five developers told “use the repository pattern” will implement five variations. A reference implementation is unambiguous, runnable, and testable. Architectural scaffolding (seeded service templates with cross-cutting concerns pre-implemented) goes further — developers inherit the correct architecture by default.
Q27: How should an architect distinguish architectural concerns from style preferences in pull request reviews?
A27: Architectural concerns should be raised as required changes with rationale and references to the relevant ADR (e.g., “This creates a synchronous dependency that violates ADR-007 — here is the async alternative”). Style preferences should be explicitly marked as optional (“nit: optional”) so developers can distinguish what matters architecturally from what is the reviewer’s personal preference.
Q28: What is an Architecture Guild or Chapter, and why does it matter in scaled organizations?
A28: A recurring cross-team forum where architectural representatives from each team coordinate on shared decisions and patterns. It distributes architectural knowledge rather than concentrating it in one architect, enabling consistent architectural decision-making at scale without creating a centralized bottleneck. Teams share decisions they’ve made; the guild identifies patterns worth promoting system-wide.
Q29: What is “Architecture Office Hours” and what problem does it solve?
A29: A recurring open time slot (e.g., Tuesday 3-4pm) where developers can bring architectural questions without scheduling formal meetings. Solves the problem of developers making uninformed decisions simply because they could not get on the architect’s calendar — lowers the friction of accessing architectural expertise.
Q30: Complete this principle: “Architects who explain only ___ produce inconsistent results; architects who explain ___ produce consistent ones.”
A30: Architects who explain only what to do produce inconsistent results; architects who explain why — the rationale, the trade-off, the architectural concern being protected — produce consistent ones. When developers understand the reason behind a constraint, they apply the spirit of the constraint correctly even in cases the architect never anticipated.
Total Cards: 30
Estimated Review Time: 35-40 minutes
Priority: HIGH
Last Updated: 2026-05-29