Start New Things, Don't Change the Company

Processes are designed not to change

Pedro Franceschi states the doctrine directly: "I don't think you change the company. I think you have to start new things."¹ His premise is that established processes are designed not to change. They are engineered to be incremental, reliably a small step from where things were, which is a virtue for day-to-day operations and, on his account, a fatal flaw when confronting a discontinuity like AI. A second force compounds it. Customers pull a scaled, multi-product company toward their present-day demands, more features, more integrations, more of what they need today, so the company drifts incrementally by construction rather than by any failure of will.

Franceschi's conclusion is that the resolution is structural rather than motivational. Instead of running a transformation program through existing teams, a company should stand up separate new units that rethink a process end-to-end with today's technology.

The container: a startup inside the company

For Brex this took the form of a "Brex 3.0" bet built by a deliberately small unit. Franceschi describes keeping it to roughly fifteen to twenty people, enabled by heavy investment in an agent-assisted codebase, and running it "like a 10 to 20 person startup, not an 1,100 person company." The unit works 996 and in person, which he frames as recreating "the conditions that would be true if we were starting a company from scratch today."¹ The organizing prompt is a zero-basing exercise: if Brex were founded in 2025 rather than 2017, how would it be built? The discipline is to ask not how to add AI to an existing process but how agents would make the whole process happen, and then to build that version before an outside newcomer does.

Franceschi extends the same instinct to Brex's KYC onboarding, where he describes putting the old process aside and designing onboarding from scratch. In that telling he distinguishes a turnaround from a transformation, arguing that a company facing a discontinuity must refound its identity rather than retrofit it.²

Why the structure, not the effort, is the point

Franceschi's claim is that a transformation bolted onto existing teams will be blunted by the very incremental-by-design nature of those teams and their processes. A protected zero-to-one environment inside the company escapes that gravity, then launches into the existing base, an approach adjacent to selling new products to a company's installed customers first. The unit depends on operators who can run in founder mode while staying tied to company strategy, the same capacity described in operate at all levels. In effect the doctrine turns software-driven disruption inward: rather than wait to be disrupted, a scaled company disrupts itself in a unit built to escape its own weight.

What the doctrine leaves open

Franceschi's own framing surfaces the unresolved parts. Reintegration is the largest: a separate 996 unit ships a new product, and how that zero-based product folds back into the roadmap, sales, and support of the eleven-hundred-person organization, the very incremental machine it was built to escape, is where such units most often die. The explicit 996 and in-person self-selection also creates a two-culture split inside one company, and while Franceschi treats self-selection as a feature, the morale and retention cost to the non-996 majority is unexamined. Finally, "disrupt yourself before a newcomer does" is sound in principle, but how aggressively to let the new unit undercut the existing business's model and margin remains a judgment call the doctrine does not resolve.