Your New Senior Engineer Wants to Rebuild His Last Company. Should You Let Him?

A founder I talked with this month has two developers and a new senior hire from a large company. Two weeks in, the hire proposed a service per team, a message bus between them, a design review gate, and a separate QE group. He asked me straight out: I cannot tell if this is wisdom or habit.

I have run that machinery. At a company doing about a billion a year, I was the enterprise architect for roughly 40 engineers and 20 QE, 150 microservices on an Azure Service Bus backbone, 3 million events a day. Honestly, at that size every piece of it was necessary. Then I built Mira as the only engineer on the product, and I kept the decision log, the tests, and the module boundaries and skipped the service split.

So we went down his list. Forty engineers cannot share one codebase without colliding, so you split into services. Ten pods on separate release schedules need a way to talk that survives an outage, which is the bus. A review gate exists because one bad decision can take down five product lines, and separate QE exists because forty people produce more change than anyone can verify by hand.

Every item fixes a problem headcount created. He has two developers, so they buy him nothing and cost infrastructure, meetings, and runway.

I told him to keep one deployable split into modules with hard boundaries (the shape I used on Mira), a written decision log, and automated tests on every change, and to decline, for now, the bus, the service split, and the review gate. He will want some of it later, and the module boundaries are what make that split cheap when headcount forces it.

When a new hire proposes the machinery from their last job, ask which problem it was solving there, and whether you have that problem yet.

#FractionalCTO #StartupTech #SoftwareArchitecture #TechLeadership #StartupFounder