Chapter 14: Worked Example: Choosing a Process for a New Team

Why this matters

Chapters 12-13 showed two clean, contrasting endpoints. Most real situations — and most interview prompts — land somewhere messier in between, requiring the same reasoning framework applied to a genuinely ambiguous, mixed-signal scenario. This chapter works through exactly that kind of prompt, modeling the live reasoning process rather than presenting a pre-solved answer.

The prompt

"You're joining a 12-person engineering team at a company that's found initial product-market fit and is scaling up. The team has been running with almost no formal process — no sprints, no design docs, deployment is a manual script one senior engineer runs every Friday. They've had two significant production incidents in the last month. How would you evolve their process?"

Step 1: identify the actual signals, not just the team size

A strong candidate's reasoning, out loud: "The team size (12) alone doesn't tell me everything — the more important signals here are: they're past pure product-market-fit exploration (so speed-above-all is less justified than at the 5-person stage), and they've had two recent incidents, which is a concrete, specific signal pointing at deployment and possibly testing practices as an area needing real attention, not a vague 'let's add more process everywhere.'"

Step 2: diagnose before prescribing

"Before recommending specific changes, I'd want to understand the two incidents' actual root causes — per Chapter 10's postmortem discipline, were they caused by insufficient testing, risky manual deployment, insufficient monitoring, or something else entirely? The fix should target the actual cause, not a generic 'add more process' response that might not address what's actually going wrong."

(Interviewer: "Let's say one incident was a bad config change that should have been caught in review, and the other was a deployment that broke a feature no one noticed for six hours because there was no monitoring on it.")

Step 3: propose targeted changes tied to the diagnosed causes

"Given those two specific causes, I'd prioritize:

1. For the config-change incident: require the same review process for config changes as for code changes (directly the fix from Chapter 10's example postmortem) — a targeted process addition, not a broad overhaul.
2. For the undetected six-hour outage: invest in monitoring/alerting for key user-facing functionality (Chapter 10) — this is a gap regardless of what else changes.
3. On deployment more broadly: the manual, single-person Friday deployment process is a real risk on its own, independent of these two specific incidents — it's a single point of failure (what if that engineer is unavailable?) and batches a week's worth of changes into one large, high-risk event (directly Chapter 9's argument against infrequent, large deployments). I'd move toward automated CI/CD with smaller, more frequent deployments."

Step 4: calibrate what NOT to add, explicitly

"I'd deliberately avoid over-correcting into heavy process the team's current size and stage don't yet justify — I wouldn't recommend formal Scrum ceremonies or a dedicated QA team at 12 people without evidence that lack of sprint structure or dedicated QA specifically caused a problem. The two incidents point at deployment safety and monitoring specifically, not at planning process or testing depth broadly — I'd fix what's diagnosed as actually broken, and revisit other areas only if new evidence suggests they need it too."

Step 5: sequence the changes, don't do everything at once

"I'd also think about sequencing: moving to automated CI/CD and adding monitoring for the specific gap identified are the highest-leverage, most directly evidence-justified changes, so I'd prioritize those first. Bigger structural questions (should we adopt Scrum as we keep growing?) are worth revisiting, but I wouldn't bundle them into the same change all at once — introducing too much process change simultaneously makes it hard to tell which specific change actually helped, echoing this book's Chapter 11 point about isolating cause and effect when interpreting delivery metrics."

Why this response works as a model

[SENIOR INSIGHT] Notice what this reasoning demonstrates: it diagnoses before prescribing (asking for the incidents' actual causes rather than assuming), it ties every proposed change to specific, stated evidence (not a generic "more process is always better" instinct), and it explicitly declines to over-correct into heavy process the team's actual situation doesn't yet justify — exactly Chapter 3's framework, applied live, under the kind of ambiguous, information-incomplete conditions a real interview (and a real new job) actually presents.

Common mistakes

1. Proposing a full, generic "mature engineering process" overhaul (Scrum, formal design docs, dedicated QA, canary deployments) without first diagnosing what's actually causing the team's specific, stated problems — treating every context as needing the same heavy-process answer regardless of evidence.
2. Not asking clarifying questions about the incidents' root causes, missing the chance to target the actual proposed fix at what's genuinely broken rather than a generic assumption.
3. Recommending every possible improvement simultaneously, making it impossible to later tell which specific change actually helped, and needlessly disrupting a team with more simultaneous process change than the situation's actual evidence justifies.
4. Ignoring the manual, single-person deployment process as a real risk just because it wasn't the stated cause of either specific incident — some risks are worth addressing proactively even without a specific incident having already exposed them.

Discussion / interview questions

(This chapter's own questions ask you to apply the same reasoning to a new scenario.)

1. "A 20-person team has adopted full Scrum but is still fairly slow to ship, and morale around the ceremonies is low. How would you approach this?" Strong answer: Diagnoses before prescribing — asks what's specifically slow (planning overhead, PR review bottlenecks, deployment friction) and what specifically is causing low morale (ceremonies feeling like theater, per Chapter 1's "process theater" concept) before proposing a fix, rather than assuming either "add more Scrum rigor" or "abandon Scrum entirely" without evidence.

2. "How do you decide when a team has 'outgrown' its current process and needs something heavier?" Strong answer: Looks for concrete, diagnosable evidence — specific coordination failures, specific incidents traceable to a process gap, specific missed dependencies — rather than assuming heavier process is automatically warranted just because the team has grown to a certain headcount.

3. "Why is it important to diagnose an incident's root cause before proposing a process change in response to it?" Strong answer: A process change not targeted at the actual cause may add overhead without addressing the real problem, while the real problem remains unaddressed — diagnosis-first ensures the proposed fix is evidence-justified and proportionate, rather than a generic, unfocused response.

4. "Why might it be a mistake to implement every process improvement you can think of for a struggling team, all at once?" Strong answer: Bundling many simultaneous changes makes it impossible to isolate which specific change actually helped (or didn't), and introduces more disruption than the actual, currently-available evidence justifies — sequencing changes and evaluating each lets the team build a genuine, evidence-based understanding of what's working.

Chapter summary / cheat sheet

• Real (and interview) SDLC-evolution scenarios rarely map cleanly onto Chapters 12-13's clean endpoints — the same reasoning framework (diagnose, then prescribe proportionately) applies regardless of how messy or ambiguous the starting scenario is.
• Diagnose root causes before proposing process changes — a fix should target the actual, stated evidence, not a generic "add more process" instinct.
• Explicitly decline to over-correct into heavy process a team's actual size/stage/evidence doesn't yet justify — this is as important a skill as knowing what to add.
• Sequence changes rather than bundling everything at once, so cause and effect stay isolated and evaluable — directly connecting to Chapter 11's metrics-interpretation discipline.

---