We're six engineers running infrastructure and product for a growing company. The question I get asked most often by other engineering leaders: how do you keep it small?
The honest answer is that small is a choice you make repeatedly, not once.
The hiring bar
I only hire people who have already solved a version of the problem we're working on. Not adjacent versions. The actual problem: CV pipelines, cloud infrastructure at scale, Python data services. The learning curve for domain fundamentals at a small team isn't something you can subsidize.
This makes hiring slow. We've passed on candidates who would have been fine. The alternative is hiring fast and spending the next six months managing the gap between "fine" and "the level this team operates at."
Brian Chesky's framework - would you be embarrassed to have them represent the company - is more practical than it sounds. It's a forcing function against hiring someone you're already rationalizing.
No AI team
There is no separate AI team. There is no ML platform team. Every engineer on this team integrates AI tooling into their domain. The backend engineer owns the LLM-in-the-loop parts of the backend services. The CV engineer owns the model serving infrastructure.
When you create a separate AI team, you create a dependency. You also create a team that tends to optimize for model performance in isolation rather than system performance in production. We can't afford either.
What AI actually multiplies
The first draft. Every design doc, runbook, postmortem, and internal spec now starts with an AI-generated first draft that a human refines. The quality of the first draft varies. The value is that starting from something is faster than starting from nothing, and the gap between a 70% draft and a finished document is smaller than the gap between a blank page and a finished document.
Code review coverage. We run automated AI review on every PR before human review. It catches a class of issues - type inconsistencies, missing null checks, obvious logic errors - that humans miss when moving fast. It has never replaced human review. It has made human review faster.
What AI doesn't multiply
Architecture decisions. The model's answers are coherent and often wrong in ways that aren't obvious. I've stopped asking for architectural opinions and started using it as a rubber duck: I explain the problem, I explain the constraints, I ask it to identify the assumptions I'm making. That's useful. The unsolicited recommendation for a standard pattern that doesn't fit our constraints is not.
Judgment. What to build next, how to scope a feature, when to stop. Those remain fully human decisions and I haven't seen anything that changes that.
On culture
The single thing that matters most at a small team is that everyone tells the truth in status updates. Bad news early is recoverable. Bad news late is a crisis. This sounds obvious and it is, but creating the conditions where people feel safe reporting bad news early is not obvious and takes real work.
We do weekly written status updates, async, before the Monday standup. The format forces specificity: what shipped, what's blocked, what needs a decision. You can't hide in vague language for a week if you're writing it down every week.
The actual constraint
The constraint on staying small is not the workload. It's the quality of the decisions you make under pressure. When something breaks at scale and you need to make a call about whether to roll back or push through, you need people who have made that call before. That's the thing you can't hire or automate your way around.
With gusto, Fatih.