Building Engineering Culture and Onboarding for a Growing Team

What Engineering Culture Actually Means

This guide connects to our guide on hiring a first in-house engineer, which covers the moment a founder stops managing every technical decision alone; this guide picks up from there, covering what actually needs to be written down and taught once there is more than one engineer for that culture to apply to.

It is worth being precise about the two failure modes this guide is trying to help a team avoid, since they pull in opposite directions and both are real. The first is assuming culture will simply take care of itself — that a small, close-knit founding team's informal norms will naturally transfer to every new hire without anyone deliberately writing them down or checking whether they actually did. The second, subtler failure is assuming that copying a famous company's published culture materials wholesale substitutes for doing that same deliberate work — treating Netflix's deck or Spotify's videos as a finished blueprint to adopt rather than as one company's own, time-stamped account of what worked for them, at their scale, at that specific moment. Both failure modes produce the same practical symptom: a new engineer who can't tell you, with any real confidence, how decisions actually get made on their own team.

Netflix's Real 2009 Culture Deck

The original 2009 deck (SlideShare, “Culture,” August 2009) is real and directly attributable to Hastings and McCord. Its content, consistently described across secondary retrospectives, organizes itself around a small number of named concepts: “Freedom & Responsibility,” “Context, Not Control,” “Highly Aligned, Loosely Coupled,” and a stated list of nine values (judgment, communication, curiosity, courage, passion, honesty, selflessness, innovation, and impact). The core, real claim worth taking seriously is “context, not control”: rather than approval chains, Netflix's stated philosophy is that a manager's job is to give an engineer enough context to make the right call independently, then let them make it.

It's worth flagging directly what this guide could not verify about the deck's reception: Sheryl Sandberg is very widely quoted as having called it “the most important document ever to come out of the Valley,” but this research could not trace that quote to one specific, dated, primary appearance — a named talk, interview, or article — despite it circulating constantly in secondary coverage. It is presented here as a widely reported attribution, not a confirmed, dated quotation. Netflix later rewrote the document as a public page titled “Netflix Culture — Seeking Excellence,” hosted directly on its own jobs site (jobs.netflix.com/culture), with the rewrite dated to 2017 across secondary coverage (this guide could not confirm the exact day) and a further update reported by Variety in 2022 (Variety, “Netflix Culture Memo Update: New Anti-Censorship, Spending Sections,” 2022).

Spotify's Model, and Its Own Walked-Back Claims

Agile coach Henrik Kniberg narrated “Spotify Engineering Culture (part 1)” and “part 2,” published on Crisp's own blog on March 27, 2014 and September 24, 2014 respectively (Crisp's Blog, “Spotify Engineering Culture (part 1),” March 27, 2014; “part 2,” September 24, 2014), also cross-posted on Spotify's own engineering blog. The model describes “squads” (small, autonomous, cross-functional teams operating like mini-startups), grouped into “tribes” (collections of related squads), “chapters” (people with the same specialty across different squads, for skill-sharing), and “guilds” (informal, company-wide communities of interest).

The important, real nuance most secondhand summaries of this model omit: Kniberg and co-author Anders Ivarsson's own written paper describing the model stated directly that it was “only a snapshot of our current way of working — a journey in progress, not a journey completed,” not a finished, stable methodology to copy wholesale. Multiple former-Spotify-employee retrospectives, most notably an essay by former Spotify engineer Jeremiah Lee titled “Spotify's Failed #SquadGoals,” report that the squad/tribe structure was substantially aspirational in practice and was never durably implemented the way it was popularized across the industry as “the Spotify model.” This guide could not locate one single, dated, primary Kniberg statement making this exact walkback explicit, but the underlying 2014 paper's own “journey in progress” framing, combined with consistent former-employee reporting, is enough to state directly: treat the Spotify model as a real, historically interesting description of one company's stated intent at one point in time, not as a proven, portable blueprint any other company can adopt and expect the same outcome from.

GitLab: Handbook-First From Ten People

GitLab's own handbook describes its origin directly (GitLab Handbook, “History of GitLab”): the practice of writing everything down publicly began while the company was still around ten people, well before it had a dedicated People or HR function of any real size. This guide could not confirm an exact month or day the handbook first became publicly readable rather than internal-only, but GitLab's own materials consistently place the practice's origin at that very early, roughly-ten-person stage (GitLab Handbook, “About the Handbook”). The practical logic, stated directly in GitLab's own “handbook direction” page, is that writing a policy down publicly once is cheaper than answering the same question in Slack repeatedly, and that public-by-default documentation is itself a culture statement — it signals that the company has nothing it needs to hide from its own new hires, or from the public.

What a Real Structured Onboarding Program Looks Like

GitLab's public handbook includes several real, currently-live onboarding runbooks — a “Developer Experience Onboarding” guide, an “Engineering Development Onboarding” guide, and a general “complete guide to remote onboarding for new-hires” ( GitLab Handbook, “The complete guide to remote onboarding for new-hires”). GitLab's own documented structure is concrete and citable directly: onboarding is expected to take at least two full weeks before a new hire is expected to contribute significantly, with a third week reserved for team-specific onboarding and training, and every onboarding task is tracked through a standardized issue template rather than left to an individual manager's memory. GitLab's handbook separately publishes what it calls “TaNewKi Tips” — general onboarding advice for new team members that exists independently of any one team's specific technical runbook (GitLab Handbook, “TaNewKi Tips”), a real, structural example of separating “how to do your specific job” documentation from “how this company actually works” documentation, rather than bundling both into a single onboarding document that tries to do everything at once.

Google's own public people-operations research site, re:Work, documents a data-driven onboarding methodology built around a structured survey sent to new hires at 30, 90, and 365 days, covering three named areas — technology and tools, productivity and skills, and culture and connection — used to iteratively improve the onboarding program itself (Google re:Work, “A data-driven approach to optimizing employee onboarding”). Separately, Laszlo Bock, Google's former SVP of People Operations, describes a specific internal experiment in his book “Work Rules!” (Twelve, 2015): sending a new hire's manager a simple five-item checklist email the Sunday night before the hire's first day — discuss role and responsibilities, match the hire with a peer buddy, help them build a social network, schedule monthly check-ins for six months, and encourage open dialogue. Bock reports this simple checklist made new hires reach full effectiveness roughly 25% faster. It is worth being precise about what kind of source this is: it is Google's own self-reported internal result, published through a book by the executive who ran the program, not an independently audited or peer-reviewed study — a real and credible source, but not the same standard of evidence as a third-party controlled study.

Buffer offers a real, dated, small-company counterpoint to Google's scale. Buffer's own published blog posts describe assigning each new hire three distinct buddies — a Leader Buddy, a Role Buddy, and a Culture Buddy (Buffer, “How We Find the Perfect Fit With Our New Hires: Buffer Bootcamp,” May 2014), a structure Buffer has continued describing in later posts under a simplified two-buddy (role buddy plus culture buddy) model built around an explicit 30/60/90-day roadmap (Buffer, “The Evolution of Onboarding at Buffer”). The 30/60/90-day framing itself is worth being precise about: it is not an engineering-native invention, and traces most directly to general management and sales onboarding practice, popularized broadly by Michael Watkins' 2003 book “The First 90 Days” before being adopted widely across functions, engineering included. A team using a 30/60/90-day plan for a new engineer is borrowing a general management tool, not applying something originally designed for software teams — which doesn't make it wrong, but is worth knowing rather than assuming it was purpose-built for engineering.

Time-to-Productivity: What the Data Actually Supports

Two genuinely primary, dated academic sources exist on developer onboarding specifically, and are worth citing directly rather than the more commonly repeated, harder-to-trace industry statistics. A 2021 academic case study, “A Case Study of Onboarding in Software Teams: Tasks and Strategies” (arXiv:2103.05055), examines the actual tasks and strategies real software teams use to onboard new engineers. A more recent preprint, “Assessing New Hires' Programming Productivity Through UMETRIX — An Industry Case Study” (arXiv:2305.03332, submitted May 5, 2023), reports an 89% rise in quality code contributions from new hires during their probation period at organizations using a specific measurement tool, compared to traditional onboarding — a real, dated, citable figure, with the caveat that it describes one specific tool's vendor-reported case-study context rather than a general industry-wide benchmark.

By contrast, several extremely commonly repeated figures in onboarding content could not be traced to one identifiable, dated, primary source in this research. Turnover-cost figures widely attributed to SHRM (the Society for Human Resource Management), commonly cited as “50% to 200% of an employee's annual salary,” and a commonly repeated Gallup claim that a new employee takes roughly 12 months to reach full productivity, both appear constantly across secondary business content — but every instance this research traced back cited SHRM or Gallup only generically, without linking to one specific, named, dated original report. Similarly, “time to first commit” is used as a real, currently-circulating engineering-management metric in blog content, sometimes with specific benchmark claims (a few days for top-performing teams, two to three weeks for a median team) — but this guide could not find one clear, original, dated source that coined the metric or rigorously measured those specific benchmark numbers. A team can still find “time to first commit” a genuinely useful internal metric to track for its own purposes; the caution here is narrower — don't cite an externally sourced benchmark number for it as if it were an independently established industry standard, because this research could not verify one exists.

The 2021 academic case study on software-team onboarding (arXiv:2103.05055) is worth citing for its actual methodology, not just its existence: it examines real onboarding tasks and strategies used across multiple software teams, categorizing the kinds of work a new engineer typically does during ramp-up (reading existing code, running the test suite, fixing small, well-scoped bugs, pairing with an existing team member) and the kinds of support strategies teams use to structure that work (assigned mentors, curated “good first issue” task lists, and staged access to more complex parts of the codebase). This is a genuinely useful, academically grounded checklist for a team designing its own onboarding process for the first time, distinct from the more marketing-flavored culture documents covered elsewhere in this guide — it describes what onboarding tasks actually look like in practice across real teams, rather than what a single company says its onboarding philosophy is.

Onboarding Without a Dedicated People Function

The practical pattern both companies demonstrate, worth taking directly rather than needing to invent from scratch: write down the things a new engineer would otherwise have to ask a colleague repeatedly, assign one or two specific people (not the founder alone) as the new hire's point of contact for culture-and-process questions separate from their day-to-day manager, and treat the first two to three weeks as explicitly lower-output by design rather than an unstated expectation that quietly disappoints both the new hire and the team when it isn't met. None of this requires hiring a dedicated People or HR function first — both GitLab and Buffer built these practices while genuinely small, and the practices themselves (a written handbook, a named buddy, an explicit reduced-output ramp period) are organizational habits, not headcount.

Brooks's Law and Communication Overhead

Brooks's own book, based directly on his experience managing IBM's OS/360 project, describes the arithmetic plainly: a team of three people has three possible pairwise communication channels; a team of five has ten; a team of eight has twenty-eight; a team of fifteen has one hundred and five. Every additional person doesn't just add their own individual output — they add a new potential communication link with every existing team member, which is exactly why doubling a team's size does not double its communication burden, it roughly quadruples the number of pairwise channels that can carry a miscommunication, a duplicated effort, or a decision nobody actually owns. This is the real, underlying mechanism behind Amazon's two-pizza framing and the broader industry instinct that small teams coordinate more easily than large ones — not a vague feeling, but a specific, checkable piece of arithmetic a founder can apply directly to their own team's current size.

The practical implication for culture and onboarding specifically: a five-person engineering team can genuinely run on shared context absorbed informally — overhearing conversations, sitting near each other, a handful of Slack channels everyone reads. An eighteen-person engineering team run the same way will reliably produce the exact failure mode Brooks described: information that only some of the relevant eighteen possible channels actually carry, leaving other team members working from stale or incomplete context. This is precisely why GitLab's handbook-first practice and Google's structured onboarding survey cadence both exist — not as bureaucracy for its own sake, but as a direct, deliberate substitute for the informal channels that stop reliably reaching everyone once a team crosses roughly the size where n(n−1)/2 starts producing more channels than any one person can realistically track.

How Culture Changes as a Team Scales

Amazon's own AWS-published executive-insights materials describe the two-pizza team concept directly — the idea that a team should be small enough to be fed by two pizzas, kept intentionally small so it can move and communicate without the coordination overhead a larger team requires (AWS, “Powering Innovation and Speed with Amazon's Two-Pizza Teams” ). It is worth being precise that the memorable framing itself — small enough for two pizzas — is the actual documented articulation, rather than one specific numeric cap; this guide could not locate a single primary Bezos statement or shareholder letter passage spelling out one exact headcount, and secondary sources describing the practice vary between roughly five and ten people depending on the account. The principle worth taking directly, independent of the exact number: a team's natural communication overhead grows non-linearly with headcount, and Amazon's stated practice is to deliberately cap team size rather than let it grow until this becomes a real problem.

Robin Dunbar's number — the proposition that humans can maintain roughly 150 stable social relationships — is a real, dated academic concept, introduced in a 1992 paper and popularized further in his book “Grooming, Gossip, and the Evolution of Language.” The application of this number specifically to engineering-org design (the idea that an engineering department can function with mostly informal coordination up to roughly 150 people, and needs more formal structure past that point) is not part of Dunbar's own research — it is a later extrapolation made by organizational commentators applying his number to a context he did not originally study. This guide presents it here explicitly as industry commentary building on Dunbar's real academic work, not as a finding Dunbar himself published about engineering teams specifically.

A Real Criticism Worth Naming: The “Keeper Test”

The “keeper test” is described directly in Netflix's own culture materials, both the original 2009 deck and the later “Seeking Excellence” rewrite: a manager is instructed to regularly ask whether they would fight hard to keep a given employee if that employee said they had a comparable offer elsewhere, and if the honest answer is no, Netflix's stated practice is a generous, immediate severance rather than a formal improvement plan or a wait for the situation to resolve itself. This is a genuinely different stance from most companies' documented HR practices, and Netflix presents it as a direct consequence of “freedom and responsibility”: the freedom only makes sense, in Netflix's own stated logic, if the company is equally direct about removing people who aren't performing at the level that freedom assumes.

It is worth naming directly, in the same spirit as the rest of this guide's sourcing discipline, that this is a real point of public criticism, not a universally celebrated practice. Reporting on Netflix's culture over the years — including retrospective pieces published well after the original 2009 deck — has described the keeper test and the broader “adequate performance gets a generous severance” policy as producing real, reported anxiety among some Netflix employees, a culture some described as high-pressure rather than simply high-autonomy. This guide is not attempting to adjudicate whether Netflix's specific policy is net positive or negative for a given company — that depends heavily on context this guide can't generalize about — but it is worth stating plainly that adopting language like “freedom and responsibility” from a famous culture deck without also grappling with what Netflix itself says is the enforcement mechanism behind it (the keeper test, and the willingness to let people go quickly) is adopting only the appealing half of a documented, real policy.

Written Culture Is Not the Same as Lived Culture

This is the single throughline connecting every real example in this guide. Netflix's 2009 deck stayed largely credible as a description of the company for years, but Netflix itself judged it needed a formal rewrite by 2017 and a further update in 2022 — even Netflix, by its own actions, treats its culture document as something that goes stale and needs revisiting, not a document written once and left alone. Spotify's squad model is the sharper cautionary case: a real, well-produced, widely admired description of an organizational intent that former employees and industry retrospectives report drifted significantly from actual practice, without Spotify ever formally retracting or updating the original videos to reflect that drift. The gap between what a company's culture document says and what a new hire actually experiences in their first month is exactly the gap a real onboarding program is supposed to surface and correct — which is precisely what Google's 30/90/365-day survey cadence and GitLab's living, editable handbook are both structurally built to catch, and what a company that writes a culture document once and never revisits it cannot.

The practical takeaway for a team writing its first culture document or onboarding guide: treat the act of writing it down as the start of a maintenance obligation, not a one-time deliverable. A stale onboarding doc that describes a process the team stopped following eighteen months ago is arguably worse than having no written onboarding doc at all, since it actively misleads a new hire trying to follow it in good faith. The real, concrete practices in this guide worth adopting — GitLab's public, continuously edited handbook; Google's recurring survey cadence; Buffer's named buddy system, revisited and simplified over the years in its own public posts — share exactly this trait: none of them are static documents written once at founding and never touched again.

Architecture Decision Records: A Concrete Onboarding Tool

Nygard's original 2011 post, “Documenting Architecture Decisions,” proposed a simple, consistent template: a short, numbered document per significant decision, stating the decision made, the context and forces that led to it, and the consequences — including tradeoffs the team accepted knowingly rather than by accident. The practice has since been adopted widely enough that dedicated open-source tooling exists to generate and manage them, but the core idea remains exactly as simple as Nygard originally described it: a short, dated file per real decision, committed alongside the code it concerns, rather than a decision explained once in a meeting and never written down anywhere a new engineer could later find it.

The direct connection to onboarding is concrete rather than abstract: a new engineer joining a codebase with a real history of ADRs can read, in a few minutes, why the team chose a particular database, why a particular service boundary was drawn where it was, or why an earlier approach was abandoned — context that otherwise exists only as tribal knowledge held by whichever engineers happen to still be at the company. This is a small, concrete, genuinely low-cost practice a team of any size can adopt immediately, and it complements every other practice in this guide directly: GitLab's handbook captures how the company operates broadly, while ADRs capture why a specific piece of the actual codebase looks the way it does — two different, real gaps a new hire otherwise has to fill by asking around.

What This Guide Could Not Verify

Consistent with the standing rule across this series, it's worth naming directly the specific claims this guide's research could not confirm to a standard it's comfortable presenting as settled fact:

1. 1

   Sheryl Sandberg's exact quote about Netflix's culture deck

   Widely reported as calling it "the most important document ever to come out of the Valley," but this guide could not trace the quote to one specific, dated, primary appearance.

2. 2

   The exact SlideShare view count for Netflix's 2009 deck

   Reported in secondary press as "21 million+" views, but this guide could not confirm this against a live, current SlideShare count.

3. 3

   SHRM turnover-cost percentages (commonly cited as 50-200% of salary)

   Widely attributed to SHRM across secondary sources, but this guide could not trace the figure to one specific, named, dated SHRM report.

4. 4

   Gallup's commonly cited "12 months to full productivity" and "12% strong onboarding" figures

   Frequently repeated in onboarding content but not traced to one specific, dated, primary Gallup report in this research pass.

5. 5

   "Time to first commit" specific benchmark numbers

   The metric is in real current use in engineering-management content, but specific benchmarks (e.g., "3-5 days for top teams") could not be traced to one original, dated source.

6. 6

   Amazon's exact numeric definition of a "two-pizza team"

   The principle itself is real and AWS-documented, but the exact headcount varies (roughly 5-10) across secondary sources, with no single primary Bezos text specifying one number found.

A Practical Framework

Bringing the research above together into an actual sequence for a small team building its first real onboarding practice:

It is worth being direct about sequencing here, since a team excited by Netflix's or Spotify's famous materials often wants to start by writing an inspiring culture deck of its own. The four steps above run in a more useful order for a team that doesn't yet have one: get the concrete mechanics of onboarding right first — a written doc, a named buddy, a protected ramp period, a real feedback loop — before investing in an aspirational culture document that describes values no one has yet tested against the daily reality of working there. Netflix's and GitLab's culture materials both came from companies that had already been operating long enough to know, from lived experience, what was actually true about how they worked; a culture document written before that experience exists risks becoming exactly the kind of aspirational-but-unenforced document Spotify's own history warns against.

None of this requires a dedicated People or HR function, a large budget, or copying Spotify's org chart wholesale. What it requires is treating culture and onboarding as something to write down and measure deliberately, the same way the rest of this series treats every other early operational decision, rather than assuming culture will simply emerge on its own as the team grows — which is closer to what Spotify's own retrospective history suggests happens by default: an aspirational model that drifts from its documented description unless someone actively maintains it.

Frequently Asked Questions

Every real culture document and onboarding program in this guide traces to a company's own published material, a named academic source, or a specifically dated blog post — and every place secondary content commonly repeats a figure this guide could not independently confirm, that gap is named directly rather than presented as settled fact. Building a real engineering culture starts with the same discipline this guide is built on: know precisely what is actually documented, and say so plainly when something widely repeated isn't.