Cal.com

A 2023 Cal.com handbook page describes mirroring Linear tickets to GitHub issues in both directions via SyncLinear; the page does not verify the current workflow.

How it works

The 2023 guide describes two-way syncing between internal tickets and public issues; current use is unconfirmed.

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.

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.

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.

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.

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.

Cal.com’s pay page, changed 17 July 2026 but still marked “might be outdated / under construction,” describes twice-yearly reviews; current practice is unconfirmed.

How it works

The caveated source describes twice-yearly salary reviews; it is not presented as verified current policy.

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.

In Cal.com’s published engineering ladder, IC5 owns team practices such as AI-development guidance and evaluation guardrails; IC6 sets company-level AI-tool strategy and the 18–24 month technical direction. These descriptions do not establish current staffing.

How it works

Separate role documents define IC5’s cross-team practice ownership and IC6’s long-horizon architecture and tooling choices.

Why it is used

Makes practice and strategy expectations visible in technical leadership.

Trade-off

A role description is normative and does not prove how many people currently hold the role.

Best fit

Engineering teams designing senior individual-contributor ladders.

Cal.com writes its engineering standards down and aims to have each one checked in CI before merge: lint rules for domain boundaries, performance benchmarks that block regressions, and enforced test coverage for new code. Reviewers are expected to request fixes for nits and pattern violations rather than approve to reduce friction, and small refactors belong in the current PR instead of a deferred follow-up.

How it works

Architecture moves to vertical slices (`packages/features`), with repositories behind dependency injection and DTOs validated with Zod. Roughly 80% of boilerplate and non-critical code is meant to be AI-generated, large test suites are built with AI, and AI code reviewers are part of review. The stated target is to cut the share of PR effort spent on fixes from 35% to 20% or lower.

Why it is used

To tie quality to tooling instead of individual attention while output grows, and to share ownership across the whole system.

Trade-off

Initial velocity drops while standards settle in; DTOs, abstractions and tests add code; lint and CI tooling needs ongoing upkeep and stricter review can lengthen cycles. The claim that output doubled and the targets are self-reported, and partly describe planned rather than completed work.

Best fit

Mid-sized engineering teams that have written their standards down and where AI-assisted coding is widespread.