Linear: move fast with little process (with first Engineering Manager Sabin Roman)

• Linear is a small, profitable, full-remote startup (60+ people, 25 engineers) that has built a popular project and issue-tracking tool used by 10,000+ companies, including 66% of Forbes Top 50 AI companies. Founded in 2019 and having raised $52M, Linear is known for its design quality, speed, and unusual engineering culture. Sabin Roman, the company’s first engineering manager, previously spent seven years at Uber and now leads engineering at Linear. This conversation explores how Linear moves fast with surprisingly little process, how its engineering culture differs from large companies like Uber, and the specific tactics that make a 25-person engineering team punch far above its weight.

Linear’s engineering culture and communication

• Linear almost never uses email internally. Sabin estimates he has sent around 20–30 emails in three months at Linear, mostly to external contacts. Internal communication happens through Slack and Linear itself.

  • If a question is urgent, engineers ask in a group chat and get fast responses. If it can wait, they post a comment or project update in Linear, which serves as the structured, searchable long-term record.
  • The absence of email forces people to either figure things out themselves or be intentional about asking for help, reducing noise and unnecessary back-and-forth.

• Engineers are directly close to customers, which is a deliberate cultural choice.

  • Every week, two engineers rotate into a “goalie” role (like a goalkeeper in sports). They triage all incoming customer reports—bugs, quality issues, confusion—reproduce them, and either fix them directly or assign them to the right person.
  • Goalies are also active on customer support Slack channels, so they interact with customers in real time. Sabin describes cases where a customer reported a bug and an engineer had it fixed and deployed within an hour or two.
  • This contrasts sharply with Uber’s support engineer model, where tickets were often escalated across teams and lost in handoffs. At Linear, the engineer who sees the bug can usually fix it themselves.

• Linear runs a zero-bug policy with an unofficial one-day SLA.

  • The official SLA is one week (to account for days off), but the team actually aims to fix every bug within a day.
  • Every morning, engineers fix their open issues before moving to product work. The team reviews bug SLAs weekly, and the goal is that each engineer has at most two open issues at any time.
  • When Sabin joined, there were hundreds of open bugs, so the team dedicated time to clearing the backlog before the policy became sustainable. It has been running successfully for months.
  • Engineers use judgment: if a bug was reported by one customer, can’t be reproduced, and the customer hasn’t followed up, it may be deprioritized rather than added to a backlog.

• Quality is prioritized over feature velocity, which Sabin sees as a strategic choice in a crowded market.

  • At Uber, Sabin and the host shipped features that brought tens of millions in incremental revenue, and the company deliberately chose growth over bug fixes. Linear takes the opposite approach: fixing what customers use and rely on takes priority over building things they haven’t seen yet.
  • Sabin argues that in a market with many well-funded issue trackers, competing on features alone is a losing strategy. Quality and craft are Linear’s differentiation.

Hiring and team composition

• Linear’s hiring process includes a paid work trial week.

  • After a recruiter screen, a hiring manager call, and two technical exercises (coding and architecture, based on real simplified Linear code), candidates join the team for a full work trial.
  • The trial is remote, and candidates work on a greenfield project—something new and interesting that they can own autonomously. In at least one case, a candidate shipped their trial project as their first contribution after joining.
  • The technical exercises are not abstract algorithm problems; they are based on actual code that someone at Linear previously wrote.

• Hiring focuses heavily on product judgment, not just technical skill.

  • In the hiring manager call, Sabin evaluates three things: the candidate’s motivations and what excites them, their product sense and taste, and their technical experience and challenges they’ve tackled.
  • Linear looks for engineers who have demonstrated they can build great products, not just write elegant code or design scalable architecture. This “product-minded engineer” bar is what makes hiring difficult—it’s a very specific profile.
  • All 25 engineers are expected to contribute to product decisions, not just execute specifications.

• Linear has no engineering levels or titles. Everyone is just “engineer.”

  • There are no level-based promotion rubrics. This keeps focus on building a great product rather than optimizing for promotion criteria.
  • Sabin observes that at Uber, the promotion rubric eventually became the goal itself—engineers optimized for what the rubric rewarded (RFCs, cross-functional projects) rather than what was best for the business.
  • Growth at Linear is tied to the product’s increasing complexity: as customers 10–20x Linear’s size start using the tool, engineers must grow to keep the product simple while scaling it up.

Remote work and management

• Linear is fully remote (all 60+ people) and has been since founding.

  • Sabin finds that remote work enables deep focus—people are truly present when they’re online, and response times on Slack are very fast.
  • Remote work selects for and cultivates autonomy: engineers tend to unblock themselves, build proofs of concepts, and show rather than theorize.
  • The main challenge is building a sense of belonging and personal connection. Linear addresses this through weekly demo meetings (where everyone shares work-in-progress, even rough ideas), 2–3 offsites per year, and encouraging engineers to visit each other for 2–3 day working sessions when collaborating on a project.

• Managing remotely is harder, but worth it.

  • Sabin is honest that remote management requires more effort to build trust, read how people are feeling, and maintain connection. At Uber, his first months of remote management were exhausting—up to 16 Zoom meetings a day.
  • Linear has adapted by using Slack huddles (just click to start a call, no scheduling needed) and keeping meetings async where possible. The culture is “show, don’t tell”—demos and prototypes over slide decks and theoretical discussions.

• Sabin’s role as an engineering manager is radically different from Uber.

  • About 40% of what he did at Uber (promotion processes, cross-team alignment, budgeting, reporting, justifying headcount) simply doesn’t exist at Linear.
  • His manager Thomas (co-founder and CTO) evaluates him by asking: “What have you done to make Linear a better product?” This has led Sabin to be deeply involved in product—writing data queries, conducting customer interviews, even manually emailing 100 customers for feedback.
  • He still does traditional management work (one-on-ones, understanding what people want to work on, giving feedback), but the feedback is specific and infrequent because the engineers he hires are already very strong.

How a project gets built at Linear: the project page overhaul

• A concrete example: redesigning Linear’s project page to support product managers, not just engineers.

  • The project was part of a broader company focus on planning features. The team was two engineers, one product person, one designer, and one customer support representative.
  • Customer support was included because they know best what customers are asking for and where they struggle.

• The process was iterative and exploratory, with no formal PRD.

  • The team held a kickoff where product shared customer interviews and a high-level direction, but no specification. Engineers, design, and product all contributed ideas in an open discussion.
  • The first meeting didn’t reach a conclusion. People went away, thought more, and design and engineering started hacking on prototypes and proofs of concept together.
  • They iterated two or three times on the UX, especially because introducing a “product manager” persona into a tool designed for engineers required careful thought to keep existing flows streamlined.
  • The process felt like it wasn’t moving forward until suddenly it “clicked”—the team converged on a direction that felt right.

• Prototypes were built incrementally on the main codebase behind feature flags.

  • Engineers didn’t fork the codebase; they built behind feature flags and merged into master, making the work-in-progress available internally via a developer console.
  • Weekly demos showed work-in-progress to the team, including rough designs and half-built features.

• Once the team converged, they descoped aggressively and shipped in stages.

  • The focus shifted to finding the simplest version of the value proposition. They released first to internal employees, then to beta customers who had been part of the research process.
  • Beta customers were generous with feedback. Linear iterated on that bugs were fixed (consistent with the zero-bug policy) and changes were made based on feedback.
  • There was no A/B testing. When the team felt confident, they released to general availability directly.
  • The project wasn’t considered “done” until the team felt comfortable leaving it untouched for a year or two. Follow-up projects often emerged from feedback.

• The project took roughly four months from kickoff to general availability.

Why Linear’s low-process approach works

• The approach works because of small size and the specific people hired.

  • Being a 60-person company removes the coordination challenges of a 10,000+ person organization. There are no cross-team dependencies, no stakeholder alignment problems, no need for RFC firehoses.
  • Everyone at Linear is deeply passionate about building great product. When people are driven and have good judgment, you can rely on principles rather than process.
  • Sabin tried to introduce a formal project phase document when he joined. Thomas (who also came from Uber) rejected it—he didn’t want rigid phase gates and status bubbles.

• Process exists where it truly matters: reliability and incidents.

  • For things like production incidents, Linear has clear, bullet-pointed processes that must be followed. There’s no room for creativity when the site is down.
  • The philosophy is: use process where the cost of failure is high and the correct response is known; use creativity and judgment where the goal is to discover what customers need.

• The goal is not speed—it’s building something that feels right.

  • Linear doesn’t talk about “how fast can we ship this.” The focus is on building something that makes sense and feels good. Creativity and iteration are seen as the path to that goal.

Contrast with Uber: the Helix project

• The Helix project at Uber—rewriting the entire rider app on both iOS and Android from scratch—illustrates how differently a large company operates.

  • Sabin and the host worked on this together in 2016. The project involved new architecture, a new programming language (on iOS), and a new payments framework, all for an app generating roughly $1 billion in monthly revenue.
  • The timeline was extraordinarily aggressive: about 2.5 months from start to internal beta, with a final release on November 2nd. It was all-hands-on-deck, with hundreds of engineers pulled in—including backend engineers reassigned to mobile work.
  • The project was a pressure cooker with long hours, but it built lasting friendships and proved that motivated teams can achieve seemingly impossible goals.
  • Two years later, a similar rewrite of the driver app took 18 months with formal deadlines and process—reflecting how Uber had changed as it scaled.

• Key differences in how senior engineers operate at Linear vs. Uber.

  • At Linear, senior engineers are deeply involved in product decisions, talk to customers directly (including video calls), and are measured by the quality of what they build.
  • At Uber, senior engineers spent significant time on cross-team alignment, writing RFCs, and navigating a promotion process that rewarded visible, cross-functional work—sometimes at the expense of customer impact.
  • The motivation at Linear is direct customer feedback. At Uber, the motivation gradually shifted toward what helped with promotion.

Lessons from Uber that Sabin carries to Linear

• Working with many different personalities and motivations at Uber gave Sabin a solid foundation for managing people. At Linear, very few people-related situations surprise him because he’s seen so many variations at Uber.
• Uber taught him to think big and take bold bets. The Helix project proved that ambitious goals are achievable with the right team and motivation, even if the pace isn’t sustainable long-term.

Rapid fire

• Favorite sport: Scuba diving—a cheap way to experience zero gravity. Sabin sometimes combines remote work with diving trips, working for two weeks and taking one off (though he doesn’t work after diving due to nitrogen in the bloodstream).
• Best thing about being an engineering manager: Being proud of what the team achieves. Best thing about being an engineer: Just building things. Sabin misses it and builds robots at home for fun.
• Movie recommendation: Interstellar—Sabin is passionate about astronomy and does astrophotography.