← All speakers

Bio, Work & Ideas

Gergely Orosz

Conference affiliation: The Pragmatic Engineer · 2026

Gergely Orosz is the founder and author of The Pragmatic Engineer, an independent software-industry publication with more than one million readers, and the author of The Software Engineer’s Guidebook. A former Uber engineering manager, he investigates how technology companies build software, organize teams, measure performance, and adapt to AI-assisted development.

Orosz built trading software at J.P. Morgan, worked on Skype products at Skype and Microsoft, and joined Skyscanner before moving to Uber in Amsterdam. At Uber, he led mobile, web, and backend teams and worked on payments infrastructure. His engineering career gave him firsthand experience with distributed systems, hiring, promotions, and the organizational constraints shaping large engineering teams.

After pandemic-era layoffs disrupted his Uber team, Orosz left the company in October 2020. He had expected to finish a book and potentially start or join a platform-engineering company. Instead, he launched the paid edition of The Pragmatic Engineer in 2021, reporting on engineering organizations, compensation, infrastructure, management, and the software job market. The publication expanded into The Pulse, a research team, and a podcast, eventually reaching more than one million readers. It does not accept sponsorships.

Published in 2023, The Software Engineer’s Guidebook distills his approach to engineering careers: technical ability matters alongside communication, influence, production ownership, and understanding how organizations make decisions. Orosz self-published the book after more than four years of work.

  • Productivity is not token consumption. Orosz challenges token-spending leaderboards and AI-usage targets that encourage engineers to generate visible activity instead of useful results. His reporting on AI developer-tool evaluation examines why mandates and adoption metrics cannot establish whether teams deliver better software.
  • AI changes the whole engineering system. Faster code generation does not automatically remove review bottlenecks, unclear requirements, or coordination costs. His 2026 survey of software engineers, coauthored with Elin Nilsson, explores uneven benefits and rising costs; his AI Engineer Europe conversation also highlights the internal coding agents, service-discovery integrations, and developer platforms companies build around existing codebases.
  • Product judgment becomes more valuable when code becomes cheaper. In his conversation with Linear cofounder Tuomas Artman, Orosz probes the consequences of accelerating feature production without understanding customer needs. Linear’s quality rituals and automated bug-fixing systems are Artman’s company initiatives; Orosz focuses on what they reveal about restraint, craft, and incentives.
  • Agent orchestration is not people management. Coordinating coding agents resembles technical leadership more than managing employees: software does not require career coaching, conflict resolution, or the long feedback cycles involved in leading people. Orosz expects engineers to take broader responsibility for planning, product decisions, and operations.

His interview with database founder Simon Eskildsen applies the same scrutiny to infrastructure economics, caching, cloud capacity, and startup financing. The database architecture and company-building decisions belong to Eskildsen; Orosz draws out how technical simplicity, customer needs, and organizational choices determine whether ambitious engineering actually works.

Read the topics behind these talks

3 conference talks

Key ideas

Scroll to read ↓

Simon Eskildsen traces the engineering habits behind Turbopuffer: testing real failures, checking benchmarks against hardware limits, and making search economics work before scaling the company.

  • A clickable shape becomes a program
    0:30 ↗
  • A broken phone and an unexpected apprenticeship
    4:03 ↗
  • Scaling means deciding what happens when dependencies fail
    9:12 ↗
  • Test the connection, including the driver
    11:27 ↗
  • What should this operation cost?
    14:56 ↗
  • When the estimate is wrong: MySQL and fsync
    19:09 ↗
  • A useful feature that could not afford to ship
    21:05 ↗
  • Cheap storage changes the shape of search
    24:05 ↗
  • Cursor becomes the first customer
    28:40 ↗
  • The CPU advantage meets the capacity limit
    35:17 ↗
  • Run where the machines are
    41:19 ↗
  • Price the efficient implementation, then build it
    43:06 ↗
  • Be explicit about why you are raising
    49:18 ↗
  • A distributed company can still gather around a campfire
    51:45 ↗

Key ideas

Scroll to read ↓

Token counts can reward busywork even as coding agents change who can build software, what engineers own, and where companies invest in infrastructure.

  • When AI usage becomes a performance proxy
    0:28 ↗
  • Why leaders pushed adoption
    4:48 ↗
  • Compliance versus useful output
    8:01 ↗
  • Choose the right unit of productivity
    9:26 ↗
  • Learning through changing workflows
    10:42 ↗
  • Broader responsibilities, smaller teams
    12:41 ↗
  • Orchestrating agents is not people management
    14:42 ↗
  • The infrastructure hidden behind product output
    17:25 ↗
  • Shopify’s deliberate cost of being early
    20:39 ↗
  • An unexpected publishing business
    22:51 ↗
  • Protecting the work without burning out
    24:51 ↗

Key ideas

Scroll to read ↓

Linear’s Tuomas Artman and Gergely Orosz explore how faster implementation changes product judgment, bug repair, and the engineering habits that make software feel good.

  • When every request can become a feature
    0:42 ↗
  • Finding the problem behind the request
    3:52 ↗
  • Accelerating work with a clear target
    5:38 ↗
  • The visible cost of shipping pressure
    6:36 ↗
  • What Uber’s metrics could not settle
    7:49 ↗
  • From a misplaced ETA marker to gradual user loss
    9:36 ↗
  • Making small imperfections visible
    11:56 ↗
  • The improvement must be yours to find
    15:02 ↗
  • Zero bugs means immediate ownership
    16:22 ↗
  • Correct behavior can still feel wrong
    19:43 ↗
  • Testing product ownership through work
    22:21 ↗
  • Giving engineers access to customer reality
    25:00 ↗
  • The conditional shift toward product engineering
    26:23 ↗
  • Learning from the first outside user
    27:54 ↗

References