What Big Tech process actually buys you — and why a 12-person company should steal only some of it

I have worked on both sides of the fantasy. I spent years inside a FAANG-shaped org where every deploy had a checklist, every incident had a postmortem template, and every hire sat through a calibrated interview loop that took six weeks. Later I joined a twelve-person company where the “process” was a shared Notion page, a Slack channel named #ship, and the trust that whoever broke production would fix it before lunch.

People who leave big companies often talk about process like it is pure theater. People who have only ever worked small talk about big-company process like it is free insurance. Both views are incomplete. Big Tech process buys you something real. It also costs something real. A twelve-person company that copies the whole stack usually buys the cost and misses the return.

This is the version I would defend to a founder who just hired their tenth engineer and is already asking for “more process.” Steal the pieces that protect judgment under growth. Leave the pieces that exist to coordinate thousands of strangers.

What process is actually buying

At scale, process is not morality. It is a coordination tax you accept because the alternative is worse. When two hundred engineers can touch the billing path, you cannot rely on tribal knowledge that “Alex knows that service.” You need written ownership, review norms, and a release path that does not depend on one person being awake.

The useful buys I saw again and again:

• Shared language for risk. Severity levels, blast-radius questions, and “what happens if this is wrong” are boring until something is on fire. Then they save an hour of status theater.
• A default way to disagree. Design docs, RFCs, and decision records force the argument onto paper before it becomes a hallway fight. The document is not sacred. The forced clarity is.
• Repeatable hiring signal. A structured loop is imperfect, but it beats “have coffee with the founder and see if you vibe.” Vibes do not scale, and they hide bias.
• Incident memory that outlives the on-call rotation. Postmortems that name causes and owners beat Slack archaeology six months later.

None of that is free. Each buy also purchases meetings, templates, and a culture that can start optimizing for looking careful instead of being careful. The trick is knowing which buy you need at your size.

What a twelve-person company should steal

If I walked into a twelve-person eng org tomorrow, I would steal four habits from Big Tech and leave most of the ceremony behind.

1. A written decision when the choice is expensive to reverse

You do not need an RFC culture for renaming a button. You do need one page when you pick a database, a multi-region story, or a pricing model that hard-codes assumptions into every service. Keep it short: context, options, recommendation, open questions, and who decides by when. Store it where people already look. The point is not bureaucracy. The point is that the person who joins next quarter can see why you rejected the clever option.

At twelve people, this can be a Google Doc with a date in the title. At twelve hundred, it becomes a review forum. Do not import the forum early.

2. A severity language for production

Small teams often skip severity because “everyone knows when it is bad.” That works until the founder, the on-call, and the customer-success lead disagree about whether to wake people at 2 a.m. Write three severity definitions in plain language. Tie them to customer impact and to who gets paged. Practice once with a tabletop so the definitions are not theoretical.

You are not copying Big Tech’s SEV-0 pageantry. You are buying a shared answer to “how bad is this?”

3. A hiring loop with the same questions for the same role

I have watched twelve-person companies hire like a friend group expanding. It feels warm. It also creates a team that cannot explain why the last three hires succeeded or failed. Steal a small structured loop: one practical screen, one deeper technical session, one collaboration session, and a short debrief that uses the same scorecard. Keep the loop under a week if you can. Speed is a small-company advantage you should not throw away.

Calibrated rubrics matter more than the brand of the interview. If two interviewers cannot explain what “strong hire” means for this role, the process is still vibes with extra steps.

4. A lightweight postmortem habit

After a real incident, write what happened, what you thought was happening, what you changed, and what you will not change. Keep blame out of the document and owners inside it. Thirty minutes of writing beats a week of “we should somehow be more careful.”

If nobody reads the postmortems, stop writing novels. Write half a page and link the tickets that closed the gaps.

What you should refuse to copy yet

This is the part founders hate hearing, because the Big Tech checklist looks like professionalism.

Multi-week change advisory boards. At twelve people, a CAB is usually fear wearing a calendar invite. Prefer pair review, feature flags, and a rollback path you have actually tested.

Mandatory design reviews for every pull request shape. Review norms are good. A standing architecture committee that meets twice a week is how a small team learns to wait for permission. Teach people when to escalate, not how to fill a queue.

Ladder documents longer than your product roadmap. Levels help when promotions become political. Before that, write a one-page expectation for “senior” and spend the rest of the time shipping with people and watching how they behave under ambiguity.

Tooling that assumes dozens of services. Service catalogs, ownership graphs, and elaborate SLO dashboards are wonderful when you have dozens of services and rotating on-calls. With three services and five engineers, a status page and a shared on-call calendar may be enough. Buy complexity when the pain is present, not when a blog post made you anxious.

Process that exists to impress investors. I have seen early teams install sprint theater because a board member asked how they “do Agile.” If your cadence is weekly priorities and a demo, say that. Do not add story-point fiction to look adult.

The missing buy: judgment about when process is the product

Big Tech process often succeeds for a reason small teams overlook: the company is optimizing for many teams that do not know each other. Process becomes the product surface between strangers. Your twelve-person company is still mostly a group of people who can turn their chairs and talk. Your coordination problem is different.

That means the highest-leverage “process” at your size is often not a template. It is a norm:

• We write down reversible vs irreversible decisions.
• We page for customer-visible breakage, not for aesthetic alarms.
• We hire with the same bar twice in a row.
• We tell the truth in postmortems and then change one concrete thing.

Those norms scale later into documents and tools. Starting with the tools is how you get empty templates and full calendars.

A practical steal list for the next ninety days

If you want a concrete plan instead of a philosophy rant, here is what I would do in the first ninety days after a company hits roughly ten to fifteen people in engineering:

1. Create one shared “decision log” and require an entry for irreversible choices only.
2. Define three incident severities and run one forty-minute tabletop.
3. Standardize the interview loop for your most common role and kill one-off coffee screens for that role.
4. After the next production incident, write a half-page postmortem within forty-eight hours.
5. Delete any recurring meeting that cannot name the decision it exists to make.

Notice what is not on the list: story points, a program management office, a platform council, or a promotion committee. Those can arrive when the org chart has layers and the people on those layers no longer share a lunch table.

How to tell you copied too much

Watch for these symptoms. I have seen all of them in companies that “professionalized” too early:

• Engineers wait for a review forum before writing a prototype that would take a day.
• Incident channels fill with process compliance before mitigation.
• Hiring takes longer than your runway comfortably allows, and nobody can explain what the extra weeks bought.
• People spend more energy updating the status of work than reducing uncertainty in the work.

If those show up, you did not become Big Tech. You became a small company wearing Big Tech’s coat in July.

What I would steal from the small side, too

The exchange is not one-way. When I left the large org, I missed the incident language and the decision docs. I did not miss the six-week interview loops or the sense that shipping required a passport through three committees. Small companies still own a scarce asset: short feedback loops and social trust.

Protect that asset. Use Big Tech process to keep trust from rotting as you grow — not to replace trust with paperwork before you need to.

So yes: steal. Steal severity language, short decision records, a repeatable hiring bar, and postmortems that create memory. Refuse the theater that exists to coordinate strangers you do not have yet. The adult move is not “more process.” It is the right process for the number of people who still know each other’s names.