What a Small Team Should Require Before Merge
A merge button is a promise. On a team of four or five engineers, it is the promise that whatever sits on the main branch will not cost someone else their Saturday. Small teams have no review committee, no release manager, no QA department standing between a pull request and production. The people who write the code are the people who ship it and the people who get paged at 2 a.m. when it breaks. That changes what a merge gate should look like.
The instinct, borrowed from larger organizations, is to require more: more approvals, more checkboxes, more ceremony. Small teams that copy this discover the obvious failure mode within a month. The two senior engineers who can approve anything become a bottleneck, the checklist grows stale, and people start rubber-stamping because the process has stopped meaning anything. A merge requirement earns its place only if it catches a real class of mistake that the team actually makes.
The bar should fit in a short list
Four things are worth blocking a merge over on a small team. The code has been read by someone other than its author. The tests that exist actually run and pass. The change can be explained in plain language to a person who was not in the room. And there is a way back out if it goes wrong. Everything else, from commit message style to branch naming, belongs in a convention document that nobody has to enforce with a red X.
The reason to keep the list short is not laziness. It is that a gate people respect is one they will not route around. The moment a team starts adding exceptions ("just this once, it's a hotfix"), the gate is finished as a real constraint. A short list that holds under pressure is worth more than a long list that gets waived every other Friday.
A second pair of eyes, and what that actually means
Requiring an approval is the easy part. The harder question is what the approver is obligated to do. On a team of five, "LGTM" after ninety seconds is the default outcome of a process that only counts approvals. The reviewer needs a defined job: read the diff, understand what problem it solves, and say so in a sentence. If the reviewer cannot state the purpose of the change in their own words, the review has not happened, regardless of what the green checkmark says.
Small teams can afford a rule that larger ones cannot: the reviewer must be able to name one thing they checked. It might be the error path, the database migration, the way the new function handles an empty list. One specific thing, written down. This turns review from a social ritual into a small act of attention. It also gives the author a signal about whether the change was actually read.
There is a limit worth naming. On a team of three, requiring two approvals means the entire team must convene for every merge. That is a recipe for either deadlock or fake approvals. One reviewer, genuinely engaged, beats two who glanced. The rule should scale to the team's actual size, and it should change when the team does.
Tests that run, not tests that exist
Every team claims to require passing tests. Far fewer teams can honestly say the test suite runs in under ten minutes, fails for real reasons, and is trusted when it goes red. A slow suite gets skipped. A flaky suite gets ignored. A suite that nobody trusts is worse than no suite at all, because it trains people to merge past red.
The requirement worth enforcing is narrower than "all tests pass." It is that the merge is blocked when the suite fails, and the suite finishes fast enough that nobody is tempted to disable it. If the suite takes forty minutes, the team has a different problem to solve before it has a merge policy. Fixing that problem is the actual prerequisite.
New behavior needs a test that would fail without the change. This is the one test-related rule that catches the most real defects. A test written after the fact, against the code as it now exists, proves almost nothing. A test written to fail first, then pass, proves the change does what the author claims. Small teams feel this acutely because there is no separate QA layer to catch what slips through.
The plain-language explanation test
A pull request description that says "fix bug" is a small act of disrespect toward everyone who will read the commit history in six months. The requirement should be that the description states what changed, why, and what could break. Three sentences is enough. The point is not documentation for its own sake. The point is that writing the three sentences forces the author to notice when they cannot actually explain the change.
This test catches a specific failure: the change that grew. A developer starts with a one-line fix, notices an adjacent problem, refactors a module, and opens a pull request touching nine files. Asked to explain it in plain language, the author discovers the change is really three changes wearing a trench coat. Splitting it is easier before the merge than after.
There is a version of this rule that works without any tooling. The author writes the explanation in the pull request body, and the reviewer reads it before reading the diff. If the explanation and the diff disagree, that is the review. It costs almost nothing and catches a surprising amount.
A way back out
Every merge should be reversible, and the team should know how. For most changes this means the deploy is a single command and the rollback is another. For database migrations, it means the schema change ships separately from the code that depends on it, so a rollback does not strand the data. For feature flags, it means the flag exists before the code that reads it.
The requirement is not that every change be trivially reversible. It is that the author has thought about the exit before walking through the door. A merge that cannot be undone, on a team with no on-call rotation and no incident process, is a bet the whole team is making without knowing it. Naming the bet is the minimum.
Small teams get this wrong in a specific way. They treat reversibility as a production concern, something the deploy pipeline handles. But the merge is where the decision gets made. A migration that drops a column is reversible only if someone thought about it before the merge, not after. The exit plan belongs in the pull request, not in a runbook nobody opens.
What to leave out of the gate
Style, formatting, commit message conventions, branch naming, ticket linkage, and the precise number of approvals all belong somewhere, and that somewhere is not the merge button. These are conventions, and conventions work through habit and tooling, not through blocking. A linter that runs on save does more for formatting than a reviewer who comments on indentation. A commit template does more for message quality than a rejected merge.
The test for whether something belongs in the gate is simple. Does it catch a mistake that would otherwise reach production and cost someone real time? If yes, it belongs. If it catches a mistake that costs a reviewer thirty seconds of mild annoyance, it does not. Small teams cannot afford to spend their enforcement budget on annoyances, because the budget is the team's patience, and it is finite.
Who enforces the gate when the team is the gate
The uncomfortable truth about small-team process is that the same people who write the rules are the ones who break them. There is no manager to escalate to, no process owner to appeal. This means the gate holds only if the team has agreed, out loud, that it holds, and only if the senior people go first. A tech lead who merges their own hotfix without review has just told the team the rule is optional.
The counterweight is a standing agreement about what happens when the gate is bypassed. Not punishment, which small teams cannot administer anyway, but visibility. A merge that skipped review gets noted in the channel. A test disabled to unblock a release gets a ticket to re-enable it. The point is that the exception is seen, not that it is forbidden. Seen exceptions stay rare. Invisible ones become the norm.
This is the part that larger organizations solve with structure and small teams solve with culture, and culture is the harder material. It is also the only material available. Five engineers who have agreed on four merge requirements and hold each other to them will outperform a team of twenty with a twelve-point checklist and a waiver process. The gate is small because the team is small, and it works because everyone standing at it knows everyone else's name.
