Keep 10 people aligned without a 48-person org

You have ten people and no org chart to hide behind. Keep them pointed the same way with an operating decision log: context shared by default, handoffs designed before work starts, and short measured feedback loops.

Harper is an AI-native insurance brokerage that handles underwriting and placement in-house instead of selling software to brokers. About 11 engineers built its entire company. The average Series B company now has 48 people. That small group also built startup-scale tools: an AI-native CRM, a support layer, a transactional platform, voice and call-center agents, a matching engine covering 2,000 carriers, and long-range coding agents. Its operating model shares context and data by default, keeps humans on the roughly 10% of work that needs judgment, and uses in-house labelers to validate every agent.

AI-native companies put 11 percentage points more of headcount into engineering than the wider tech market, with smaller structural shares for sales, support, and finance. Treat that benchmark as a sanity check, not a target. A lean engineering team can outbuild a larger one when the operating layer is tight.

Make context the default, not the exception

Write the decision log before the work starts. Capture the problem, the constraint, the owner, and the exit criteria in a single short document. A new teammate should be able to read it in one pass and know why the work exists, what is out of scope, and who decides the next step.

Put it where the work happens, not in a folder only the founder checks. When the decision changes, update the log in the same meeting. A stale log is worse than none: it creates a false sense of shared understanding.

For a small team, shared context is the cheapest leverage you have. Do not add meetings. Keep the log short enough to finish in one. Put assumptions in the log before anyone spends time on them.

Design handoffs before work starts

Name the handoff before the next person touches it. State the input, the output, the quality bar, and the person accountable for the next step. It is done when the ticket says what changed, what evidence supports it, and what the receiver should do next.

Most handoffs fail when they are treated as status updates. A status update tells people what happened; a handoff tells them what to do. If the receiver has to ask follow-up questions, the handoff failed. The owner of the handoff is the person who can answer the first question, not the person who wrote the ticket.

A good handoff is reversible. It should say what was tested, what failed, and which assumptions remain. That lets the next person improve the work without re-deriving the whole problem from memory.

Run short measured feedback loops

Measure the loop on every output. Pick a small sample, score it against a fixed rubric or quality check, and record the failure mode. The step is complete when a regular review says what improved, what regressed, and which owner will test the fix at the next review.

A measured loop needs a named owner, a sample, and a consequence. If the review produces no decision, it is a meeting. Decide: keep, change, or stop.

Keep the rubric stable long enough to compare. If you change it every review, you are measuring your mood, not the work.

Make the operating layer self-improving

Review the operating layer itself. Ask what context was missing, which handoff broke, and which loop failed to produce a decision. A review earns its time when it produces a short list of operating fixes, each with an owner and a date to check.

A small team starts to behave like a self-improving company when it improves the system that ships the work. Put those fixes in the same decision log, and check them at the next review.