How They Do ItBETA
TREN

COMPANY PLAYBOOK

Cal.com

Cal.com describes an outward-visible workflow for contributors, engineering release discipline and a mutual-fit hiring trial in the same public handbook.
Operating system
  1. Linear ticket ↔ GitHub issue
  2. reviewed PR
  3. main/staging
  4. production; 30-day mutual trial in hiring
  5. full-time decision.

System principles

  • Connect open-source contributors to the internal workflow.
  • Separate release environments through branches.
  • Create mutual work experience before a hiring decision.

Tensions and trade-offs

  • An open workflow eases contribution but can increase the cost of public discussion and synchronization.
  • A trial reduces fit risk but can create income and security uncertainty for the candidate.

PRACTICES

How Cal.com builds its operating system

01
Open-source coordination

Mirror Linear tickets bi-directionally to GitHub

Cal.com mirrors internal Linear tickets to public GitHub issues through its SyncLinear tool; comments and statuses sync in both directions.

How it works
By default a Linear ticket goes to GitHub; an external contributor can open an issue in GitHub and the team can label it to sync it back to Linear.
Why it is used
External contributors can converse with the team without access to the internal Linear workspace.
Trade-off
Synchronization and public-context maintenance are required across two surfaces.
Best fit
Open-source product teams that use an internal planning tool.
Open original source ↗
02
Release management

Gate releases with branches and environments

Reviewed and approved PRs merge to main and then to the production branch, which starts automated deployment.

How it works
A PR maps to preview, main to staging and production to the live environment.
Why it is used
It separates a change into a distinct environment before it reaches production.
Trade-off
Additional branch and environment transitions lengthen the release process.
Best fit
Web product teams with preview and staging infrastructure.
Open original source ↗
03
Hiring

30-day contract-to-hire trial

Cal.com uses a 30-day contract-to-hire trial before most full-time hires, then makes a full-time decision at its end.

How it works
Candidate and company assess mutual fit and red flags while doing real team work.
Why it is used
It lets both sides see the work, team and working style before a long commitment.
Trade-off
A short contract can increase candidate risk and uncertainty.
Best fit
Teams able to run the trial safely in contractual and ethical terms.
Open original source ↗
04
Quality

Author self-review before PR review

The code author reviews their own change before sending the PR to someone else.

How it works
The self-review guide asks the author to read the diff and address errors, unnecessary changes, and clarity first.
Why it is used
Reserves reviewer attention for higher-value judgment rather than first-pass defects.
Trade-off
Authors can miss their own blind spots; it does not replace independent review.
Best fit
Pull-request-based engineering workflows.
Open original source ↗
05
Production flow

Manage review queue with drafts and auto-update

Incomplete work is visible as a draft PR; ready PRs are kept current through auto-update/auto-merge mechanisms.

How it works
The PR-review guide distinguishes drafts from ready changes and defines auto-update/auto-merge separately.
Why it is used
Signals readiness to reviewers and reduces integration waiting.
Trade-off
Automation can accelerate a risky change if tests or protections are weak.
Best fit
Teams with CI protections and clear review ownership.
Open original source ↗
06
Compensation

Biannual salary review

Every employee’s pay, performance, and future contribution are assessed twice yearly, while salary structures are also periodically market-reviewed.

How it works
Pay increases are performance-led, with twice-yearly review and market comparison specified.
Why it is used
Links pay decisions to recurring performance and market signals.
Trade-off
Frequent review adds management load and can create short-term performance pressure.
Best fit
Growing teams that generate regular performance evidence.
Open original source ↗

Primary sources

How we work on ticketsCompany-owned GitHub handbook: engineering workflow
Source details
Company publication: YesAccessed: 2026-09-05Visible update: 2023-11-13 (visible page history)Licence: No LICENSE file surfaced in the handbook root; prose is unlicensed/all rights reserved.Archive: Public GitHub page; commit permalinks, raw files, and repository archives are capturable (no snapshot is claimed).
Contract-to-hire trialsCompany-owned GitHub handbook: hiring policy
Source details
Company publication: YesAccessed: 2026-09-05Visible update: 2025-05-28 (visible page history)Licence: No LICENSE file surfaced in the handbook root; prose is unlicensed/all rights reserved.Archive: Public GitHub page; commit permalinks, raw files, and repository archives are capturable (no snapshot is claimed).
PR ReviewsCompany-owned GitHub handbook: engineering workflow
Source details
Company publication: YesAccessed: 2026-09-05Visible update: Not displayedLicence: No licence stated in the reviewed source.Archive: Public GitHub page; commit permalinks, raw files, and repository archives are capturable (no snapshot is claimed).