Raise on cusp, not at capacity

Outcome: Time each round to a specific inflection — the moment you can credibly describe what you will do next that you cannot do now.

Context: Linear's pattern: A funded becoming a "real company" with bigger customers; B funded enterprise adoption; C funded AI-tools integration positioning. Each round had a one-line "next move" story.

“I always like more like raised at a time where some kind of more like we were on a cusp of something. So like there is some kind of like you race around and then you could go do the things you were planning to do”

Cap layers at one — engineering manager reports to founder

Outcome: Cap the org at one layer for most functions; the IC's manager reports directly to a founder.

Context: Linear has no directors, no VPs, one COO and "head of X" titles. Sales is starting to get a second layer at scale. The default is flat; layers are added only when forced.

“basically like most functions, like there's just like one layer, like there's one manager, there's no like directors... most teams are just one layer One. So it's like I see layer You to Yeah. Or one of your founders or to a founder”

Block-out-and-rebuild design exploration from a screenshot

Outcome: Designers should screenshot the existing UI, block everything out, and rebuild — duplicating the canvas to try the opposite of the obvious solution.

Context: Karri's personal design loop. Critically: he argues designers should not go straight to code, because code-first removes the cheap exploration step. Even when you have an obvious idea, try the inversion first.

“I'll just screenshot the app and then I can like put it there. Then I like block everything out and then I start like rebuilding the interface and while doing that I'm start to like kind of like get a feel like what is the structure of it? And then I have another idea. It is like, okay, this structure doesn't make sense, I'll just duplicate and like start over with a new, new thing”

Default-No-Meeting VC posture with five-person shortlist at fundraise

Outcome: Reject most VC meetings by default; build five relationships in slow time so you can fundraise from a shortlist when ready.

Context: Karri's anti-numbers-game approach. The lesson is that fundraise outcomes are determined long before the process: by the relationships you built when not raising.

“by default it is like a no, I, I won't take the meeting and that is like my response... I usually have like a short list of like, it is only maybe like five people or something. So I, I do not go around to like pitch to like 20, comp 20 firms or something”

Defer non-burning compliance until a specific customer loss forces it

Outcome: Defer SOC 2 and similar compliance until a specific real customer is lost over it — most prospect objections are reflexive, not load-bearing.

Context: Linear deferred SOC 2 for ~2 years. Some customers asked for it but didn't actually need it. Triage rule: ask what happens if we don't do it now, not whether we'll need it eventually.

“we knew that SOC two is something we'll need one day, but we didn't get it for like the first two years or something because we just like, yeah, like we lost some customers because we didn't have it, but sometimes the customers didn't even need it, but they just asked for it”

Hire designers only when projects start breaking; engineers continuously

Outcome: Use lagging-indicator design hiring: only add a designer when current designers are over-allocated and projects start to break.

Context: Linear runs ~8 designers to ~58 engineers (about 1:7). The trigger to hire is operational pain, not aspirational org-charts. Exception: front-load designers when imagining new directions is itself the work.

“we often like to kind of like determine that, like when should we hire more? Is that when things start breaking? Or like designers are basically doing too many projects at once or we feel like we are not getting enough kind of like design support. So we, we usually kind of just keep hiring engineers and then at some point we realized like now we need to hire more designers”

Pull Salesforce customer notes into Linear so product sees raw voice

Outcome: Surface raw Salesforce customer notes inside the product team's daily tool so product sees customer language directly, not salesperson translation.

Context: Linear's customer request feature plus Salesforce integration. The premise: salespeople inevitably reshape requests into deliverables ("they wanted this"). Product loses the actual problem signal.

“we have also like a Salesforce integration now to, to help with this. Like those, those notes can be like captured from Salesforce and then like you can pull them into Linear and then you can, anyone who is in Linear can look at like, what is this particular customer or this particular segment saying”

Run two product orgs by timezone with separate managers

Outcome: Run separate product teams by timezone (US and EU), each with its own manager, and route whole projects to one team.

Context: Linear's structure: 120 people remote, two product teams (one US, one EU), each with engineering manager who reports to the founder in that timezone. Whole-project assignment avoids cross-timezone handoffs.

“we are a remote company and we have people in US and Europe. So we, we kind of run those teams a little bit separately because the time zones are like hard. So, so we have a US product team and Europe product team. So they have their own managers and, and designers and engineers. We, and then we just decide like, does this project go to US or, or Europe”