Single-Threaded Teams

Small vertical teams that own a problem end-to-end

Eric Glyman describes Ramp's structural answer to the tension between autonomy and consistency as building most of the company out of small vertical teams that own a problem from beginning to production.¹ He frames the underlying choice, which he says was debated at around forty to fifty people, as Amazon versus Google: an Amazon-style "rainforest" of redundant, competing tools where teams win and lose, against a Google-style "cathedral" of centralized decisions and consolidation toward one or two super-products. His stated reasoning for choosing the former is that a startup is "wrong a lot all the time," so high-velocity learning beats multi-year bets, and the cost of accepting "many different ways of solving problems" is paid down by internal quality mechanisms he calls "antibodies" that "sweep the streets" without stopping creation.

The teams are deliberately small. Glyman describes a single-threaded team as "a PM, three to seven engineers, maybe a designer" that owns customer research, interviews, alphas, betas, and shipping, with people added as the product matures rather than up front. He notes that the spend-management team was around a dozen people inside an 800-person company. These vertical teams are supported by horizontal orgs for infrastructure and devops, whose job is to make it easy for any developer to build and for whom, in his words, "SLAs are incredibly important." Glyman stresses that the two types are reviewed differently: for product teams you ask customers and look at velocity, while for horizontal teams he "cares very little what the manager thinks" and weights cross-functional-partner assessments of the speed they give others. He identifies reviewing everyone the same way, on manager opinion and downward reports, as a common and, for vertical teams, "horrible" mistake.

Incubation in isolation, then rejoining the org

New products, in Glyman's account, are grown in deliberate isolation. He describes Ramp's travel product, whose bookings grew from roughly 10 to 20 percent of all Ramp card transactions, being handled not by the spend team but by a small group "functionally locked in a room for like a year" doing customer research to find the form factor, and models this on Steve Jobs putting teams "in a different building."¹ His stated rationale is that dropping a new-product team into the large matrix immediately makes it "very hard to get resources" and causes new things to die or get burst.

Once product-market-fit metrics hold, which Glyman phrases as "the bucket holds water," the product "goes off to school," joining the broader org as its goals shift from finding product-market fit to operational reliability and SLAs. His shorthand for the accompanying change on the people side is "pirates to navy": some builders evolve into running larger orgs while others prefer to keep building new things. This incubation discipline connects to start new things, don't change the company, which applies the same isolate-then-reintegrate logic to building inside a scaled organization.

Where the model strains

Glyman is explicit that the rainforest tolerates redundancy and clutter and that the antibodies doing quality control are the only check, so how well that scales against Google-style consolidation is the open bet. He also frames the boundary itself as judgment: isolation protects a new team but delays integration, and while "off to school" is described as metric-gated, who calls the moment and when is not a formula. In related accounts the model is refined with a stated failure mode, that saddling a small successful team with many additional people who must agree is "one of the worst things you can do," and with a counterweight that data is a deliberate exception to decentralization because disparate models otherwise proliferate.

The framework sits on the same order-versus-chaos axis as process vs bureaucracy and functions as one concrete way to raise the coordination ceiling described in Coase's theory of the firm, alongside the broader team-of-teams design.