That collision forced me to reckon with a word I’d spent most of my career treating as an epithet: governance. In enterprise environments, governance meant six-week approval cycles, change advisory boards that met monthly regardless of urgency, and architecture review committees whose primary output was slide decks. In startups, the reaction to that world was predictable and often correct: skip all of it, ship fast, fix things when they break. The problem is that “fix things when they break” stops working somewhere around the 30-person mark, and by the time you notice, the infections have already spread through multiple codebases.
The Immune System Calibration Problem
Governance is the immune system of a technology organization. This metaphor captures both failure modes with precision. An overactive immune system attacks the body’s own cells: autoimmune conditions where healthy tissue gets destroyed because the detection system can’t distinguish friend from threat. An underactive immune system lets infections proliferate unchecked, and by the time symptoms surface, the pathogen is systemic.
I’ve lived on both sides. At JP Morgan and Mastercard, I watched governance processes entirely appropriate for organizations handling billions in daily transactions, albeit those same processes would have strangled a 40-person startup building developer tools. A three-week architecture review cycle at a bank is a reasonable trade-off when the blast radius of a bad decision includes settlement systems that move real money across borders. That same three-week cycle at a startup means your competitor shipped the feature, got customer feedback, and iterated twice before your design doc cleared its second round of review.
The goal of governance is calibrating the immune response to the organizational stage, keeping the body healthy without killing it in the process.
The instinct to reject governance entirely comes from a reasonable place. Most engineers who’ve worked in enterprises carry scar tissue from processes that existed to serve the process itself rather than to prevent actual harm. Rejecting all governance, though, is like removing your immune system because you once had an allergic reaction.
Minimum Viable Governance
What works at the 20-to-100 person stage looks different from both extremes. The structures that have earned their place in my organization share three properties: they’re lightweight enough that people use them voluntarily, they produce artifacts that compound in value over time, and they have clear sunset criteria so they don’t calcify into the bureaucracy everyone originally fled.
Architecture Decision Records (ADRs) are the single highest-leverage governance mechanism I’ve adopted. An ADR is a short document capturing what decision was made, why, what alternatives were considered, and what the consequences are. The format matters less than the habit. We use a simple template in our repo: title, status, context, decision, consequences. Writing one takes fifteen to thirty minutes, and six months later, when someone asks why we chose Postgres over DynamoDB for a particular service, the answer isn’t locked in a Slack thread that scrolled into oblivion three months ago.
ADRs document decisions after they’re made, sometimes during, but they don’t gate the decision itself. There’s no approval committee, no sign-off chain. A senior engineer makes a call, writes the ADR, and the team has a record. If someone disagrees, the ADR creates a surface for that disagreement to happen productively rather than six months later when the consequences are already baked in. I’ve written before about the importance of documenting decisions and rationale as institutional memory, and ADRs are the mechanism that makes that happen.
Lightweight RFCs fill a different gap. Whilst ADRs capture decisions, RFCs capture proposals that need input before a decision is made. The difference is scope: if a decision affects only one team, an ADR after the fact is fine. If it affects multiple teams, a three-to-five page RFC with a clear timeline for feedback prevents the kind of collision that opened this post.
Our RFC process has three rules. First, the author sets a feedback deadline, usually five business days, and silence after the deadline counts as consent. This prevents the process from becoming an indefinite holding pattern. Second, the RFC must name who has decision rights if feedback conflicts, typically a staff engineer or the relevant engineering lead. Third, the format is async-first, because a distributed team can’t wait for a meeting to align on a cross-cutting proposal.
A tech radar rounds out the triad. Ours is a simple document with four rings: Adopt (our defaults, use these), Trial (approved for experimentation in non-critical paths), Assess (interesting, someone is evaluating), and Hold (do not use for new work, migrate away over time). The tech radar prevents the most common form of governance debt in startups: the gradual accumulation of six different state management libraries, four different testing frameworks, and three incompatible approaches to API versioning, all chosen by well-intentioned engineers making locally reasonable decisions without visibility into the rest of the organization.
When to Add Each Mechanism
Timing matters more than format. Add governance too early and you’re building bureaucracy for a team that fits in one room; add it too late and you’re retroactively untangling decisions that should never have conflicted.
ADRs earn their keep the moment your team crosses the threshold where a single person can no longer hold the full architectural picture in their head. For most organizations, that’s somewhere between 15 and 25 engineers, roughly the point where three or more teams are making independent technical decisions. Before that point, decisions live in shared context; after it, they live in documentation or they live nowhere.
RFCs become necessary when multiple teams’ work intersects. If Team A’s API changes can break Team B’s integration, and the first time anyone discovers this is during code review or, worse, in production, you need a proposal mechanism. That’s usually the 30-to-50 person range, albeit the exact threshold depends on how coupled your services are.
The tech radar matters once you’ve hired enough engineers that tool and library choices start diverging without coordination. A 10-person team has full visibility into what everyone else is using. A 50-person team faces proliferation as the default state unless someone actively manages it.
Governance Debt
Startup-minded CTOs tend to underestimate this: governance has a debt model that mirrors technical debt, and it compounds with the same quiet persistence.
Governance debt compounds in the dark. Each skipped decision record, each undocumented architectural choice, each tool adopted without team visibility makes the next decision slightly more expensive.
Every decision made without documentation makes the next related decision harder, because the team has to reverse-engineer the reasoning behind the prior choice, or worse, they don’t bother and make a contradictory decision. Every tool adopted without visibility on the tech radar means another library that someone will have to understand, maintain, and eventually migrate away from. Every cross-cutting change made without an RFC means another integration surprise waiting in the next sprint.
The cost of governance debt doesn’t appear as a line item. It surfaces as slower onboarding, as repeated arguments about decisions that were already made, as architecture that drifts because each team is making locally optimal choices without global visibility. Unlike technical debt, which at least manifests in slower feature velocity you can roughly measure, governance debt manifests as organizational friction easy to mistake for other problems.
Sunsetting Governance
Every governance mechanism should have a kill switch. If a process no longer prevents real harm, it should die, and dying should be the default outcome unless someone actively argues for its continuation.
We review our governance structures quarterly, during the same sessions where we review our technical strategy. The question for each process is direct: what specific harm did this prevent in the last quarter? If the answer is “well, it probably prevented something,” that’s a signal to sunset it or simplify it. Governance that persists on hypothetical value is governance trending toward autoimmune disease.
The RFC process, for instance, has a scope threshold. If every minor decision starts flowing through RFCs, the process has grown too sensitive: the immune system is flagging healthy cells. When that happens, we raise the threshold for what counts as an RFC-worthy change, usually by explicitly listing the categories that require one and defaulting everything else to team-level ADRs.
Calibrating the Response
The startup that rejects all governance and the enterprise that governs everything are both optimizing for the wrong failure mode. Startups accept infection to avoid paralysis, whilst enterprises accept paralysis to avoid infection. The 20-to-100 person organization occupies the uncomfortable middle where both failure modes are equally dangerous, and the CTO’s job is to calibrate the immune response with precision.
Three lightweight structures, ADRs for decisions, RFCs for proposals, a tech radar for tool proliferation, cover an enormous surface area of governance need without introducing the overhead that makes engineers route around the process. The discipline is knowing when to add each one, when to strengthen it, and when to kill it, because governance that can’t be removed is governance that will eventually turn on the organization it was built to protect.