The constraint was unusual. A platform with no installed base, no precedent for legible 3-D windows, and a hard launch date. The chrome had to feel inevitable on day one and survive third-party apps on day two.
Hold the surface count small. Treat every chrome as a single rendering pipeline.
Every surface we added was a thing we had to maintain, calibrate, and explain to every team that built against the platform. The forcing function was simple: if a new chrome couldn't earn its place against the existing list, it didn't ship.
We grew the org from three engineers to roughly thirty across three calibration cycles. The discipline was hiring against the surfaces, not the headcount. Each new hire owned a piece of the chrome end-to-end — and that ownership is what kept the review bar from drifting as the team grew.
By visionOS 1.1 the chrome had three concurrent ship trains running, six patents granted or filed against the work, and a hiring funnel that ran continuously for eighteen months. The surfaces shipped, the team shipped, and the launch landed.
]]>Five years inside one of the most product-disciplined organizations in software taught me that the bar is not a function of resources. It is a function of taste, constraint, and the willingness to throw work away. The hardest thing about Apple is also the most useful thing for a founder: the quality bar lives somewhere just past where you would have stopped.
The quality bar lives somewhere just past where you would have stopped.
The question I could not let go of was a customer-facing one. I am not yet describing it publicly — partly because the companies are still pre-product, partly because the public version of the question is less interesting than the actual problem we are working on. Once there is something to look at, this page will say more.
This is a credibility surface, not a job-search page. If you are an investor, a partner, a senior operator, or a thoughtful collaborator, the contact page is the right next step. If you want the public version of the current work, that is on its way.
]]>Three calibration cycles over eighteen months. Each cycle pinned the bar to specific writeups from the last cycle, not to a memo. The writeups did two things: they kept the bar legible to a new interviewer, and they made the bar revisable as the work changed.
A team going from three to thirty crosses three seams that all happen between N=10 and N=18: the seam where the lead can't review every change, the seam where the lead can't read every doc, and the seam where the lead can't be in every interview. Each seam needs an explicit answer before the headcount crosses it — not after.
Less optimism about "we'll figure out reviews when we get there." More written-down rules about which decisions the lead retains and which decisions move down. The rules can change. The absence of rules cannot.
]]>The reason is almost embarrassingly simple: one accent forces you to be careful about where you put it. Two accents lets you off the hook. Three accents and you've left the building.
It buys a hierarchy that doesn't need explaining. The accent is the eye's gravity. Anywhere it lands is "this matters." Everything else is "this is context." A reader can navigate the page at one glance.
It costs the ability to color-code. If the accent has to mean "important," then it cannot also mean "warning," "active," or "selected." Those have to be done with weight, position, and motion — which is harder, but better, because those tools survive being printed in black and white.
When you're designing a status surface — health dashboards, monitoring, notifications — color-coding earns its keep. But on a portfolio? On a memo? One accent is enough. One accent is the discipline.
]]>