"Yes, you can and should measure engineering productivity — at scale, the only way to know where to invest is a continuous combination of internal surveys and system telemetry"
"Wait as long as possible -- build product-minded engineers first"
Evidence from the Archive
Stripe
Stripe waited approximately until its 200th employee (Singleton says slightly earlier) and five years in to hire its...
Stripe waited approximately until its 200th employee (Singleton says slightly earlier) and five years in to hire its first PM
David Singleton spent over a decade as VP of Engineering at Google before becoming CTO of Stripe, where he has led engineering and design for over five years -- overseeing a team that famously delayed its first PM hire while building one of the most product-oriented engineering cultures in tech. Their core argument: Wait as long as possible -- build product-minded engineers first. Stripe delayed PM hiring not by accident but because its engineering team was already doing the PM job.
The evidence is specific: Stripe waited approximately until its 200th employee (Singleton says slightly earlier) and five years in to hire its first PM. Furthermore, early Stripe engineers would 'dogfood' the product relentlessly and only ship to broader audiences when the internal Alpha group was 'super, super happy'. Today Stripe PMs orchestrate across engineering, partnerships, legal, risk, and compliance -- functions that engineering alone could not navigate.
In David Singleton's own words: "It is true that our original team, and I think we hire our first PM a little bit earlier than you said, but our original team was really an engineering team. However, they were extremely product minded. And I would honestly say that of all of the very early team that I've worked closely with and know well over time, every single one of them could also have been and essentially also was acting as a PM." (Explaining why Stripe could wait -- the engineers were already acting as PMs.)
Stripe
Stripe runs a monthly rolling developer experience survey — every engineer responds once every six months — triangulated against system telemetry to set the internal dev-tools roadmap
David Singleton treats developer productivity as a product team problem: engineers are the users, surveys are qualitative discovery, instrumentation is quantitative
Singleton runs engineering for a company that deploys its core API 16 times a day on average and maintains five-nines uptime at planetary scale. His answer to the measurement question is entirely operational. Stripe runs a monthly developer experience survey on a rolling sample — every engineer responds roughly once every six months, which at Stripe's scale is enough to get statistically significant signal on the whole organization without survey fatigue.
The qualitative answers are cross-referenced against quantitative instrumentation of the dev tools. The two datasets together set the roadmap for Stripe's developer productivity team, which operates as an internal product team with internal users. Measurement is instrumentation for investment decisions, not judgment of individuals.
In David's own words: "We do a monthly survey. We operate in enough scale where we can ping enough people once a month that we get a statistically significant sample of the entire organization without having to get everyone to respond. Every individual respond once every six months. And we ask very directly, what's the experience you're having? And then we use that to prioritize the roadmap of our developer productivity team." (The specific mechanics of Stripe's internal developer experience survey.)