Time to first page is a measurable onboarding metric with two distinct failure modes. How to define it, what to gate on, and the four numbers worth reporting.

Time to First Page: The Onboarding Number Engineering Leaders Do Not Report

TL;DR: Time to first page measures the calendar days from an engineer's start date to their first primary on-call shift. Establishing this as a reported metric allows engineering leaders to identify two distinct failure modes: rushing unprepared hires into rotations (increasing escalation rates) or delaying entry unnecessarily (accelerating senior engineer burnout).

The question, as it was actually asked

On August 4, 2026, a question surfaced on X that many engineering leaders recognized instantly: How did a newly joined staff engineer build enough context in just two weeks to not only ship code but to meaningfully improve the on-call rotation?

The responses were typical of the industry: a collection of anecdotes about "gritting it out," "reading all the Slack history," or "having a great mentor." This is a measurement problem dressed as a mentoring problem. We treat on call onboarding as a vibes-based transition rather than a measurable engineering milestone. Because we don't measure the ramp, we cannot optimize it, and we certainly cannot explain why one engineer takes two weeks while another takes six months.

Define the number: Time to First Page

To fix the onboarding gap, we need a precise definition. Time to first page is the number of calendar days from an engineer’s first day of employment to the start of their first shift as the "Primary" on-call responder.

"Primary" is a strict requirement. In this definition, the page must route to the new hire first. No one else is expected to answer it; no one else is "watching the screen just in case." If you count "shadowing" or "secondary" shifts in this metric, you are gaming your own data. The goal of measuring time to first page is to identify the moment of total operational autonomy.

Currently, there are no verified industry benchmarks for this number. A distributed systems team at a fintech giant might target 90 days, while a product team at a seed-stage startup might target 10. The value is not in comparing yourself to Google; the value is in comparing your team against its own historical baseline and identifying why specific joiners deviate from the mean.

Key Takeaway: On-call readiness should be treated as a measurable gate based on demonstrated capability rather than a subjective waiting period based on tenure.

Failure mode one: too short

When a team prioritizes "getting people into the rotation" above all else, they often fall into the first failure mode: the ramp is too short. This rarely looks like a catastrophic outage in the high-level metrics because the safety nets of a healthy engineering organization usually catch the fall.

Instead, the cost of a premature on call onboarding shows up in the "Escalation Rate." If the newest on-caller's shifts show a significantly higher rate of escalation to a secondary or a manager compared to the team median, the onboarding failed. You haven't added a responder; you've added a human router who delays the time to first correct hypothesis.

The visible artifact is often a slightly longer Mean Time to Resolution (MTTR) that gets blamed on the "complexity of the incident" rather than the fact that the primary responder didn't know where the logs for that specific subsystem lived. According to the Google SRE Book, training strictly through operator procedures and playbooks—without deep architectural understanding—is an anti-pattern that leads to this exact kind of fragile readiness.

Failure mode two: too long

The second failure mode is more common in mature organizations: the "Forever Shadow." This happens when there is no formal gate for on-call entry, so entry is deferred until the new hire "feels ready."

Consider the arithmetic of a team of eight engineers where only three are deemed "ready" for the rotation. Those three engineers are effectively on call every three weeks. They cannot detach, they cannot focus on deep work, and they cannot take a true vacation without checking their phone.

According to Chapter 28 of the SRE Book, bringing people into the rotation as quickly as safely possible is the primary mechanism for avoiding team burnout. When onboarding is too long, the senior half of the team absorbs the load. This doesn't show up as an incident; it shows up as senior engineer attrition eighteen months later. If your Staff engineers are leaving because of "on-call fatigue," the root cause might actually be a broken onboarding funnel for your Junior and Mid-level hires.

The gate, built from documented practice

We do not need to invent a new way to onboard engineers. The blueprint has existed since 2016. In the SRE Book, Andrew Widdowson describes a concrete gate for on call onboarding that moves away from "trial by fire" and toward verified competency.

1. The On-Call Learning Checklist

Instead of a vague "read the docs" task, create a checklist of subsystems. Each subsystem must have a named Subject Matter Expert (SME), required reading (design docs, not just code), and—crucially—comprehension questions. These aren't trivia; they are questions like "If the cache layer in this service latency-spikes, which upstream service will fail first?"

2. Tiered Access

Don't give a new hire "write" access to production on day one. Create a path where completing specific sections of the learning checklist earns progressively deeper permissions. Read-only access to monitoring comes first; the ability to trigger a failover comes last.

3. Disaster Role Playing (The Wheel of Misfortune)

Run weekly sessions where a "Game Master" takes a real historical incident and walks the new hire through it in real-time. "You just got a page that the checkout service is 500-ing. What's the first thing you look at?" This builds the muscle memory of an on call runbook without the stress of an active outage.

4. Breaking the Stack

Before a new hire goes on call, they should see the system fail. Use a staging environment to deliberately break a real stack under synthetic load. Reading an sre runbook about a database deadlock is nothing compared to seeing the specific, cryptic error message it produces in your own logging stack.

5. Shadow and Reverse Shadow

The final step is a two-phase transition. First, the student shadows an experienced on-caller during business hours. Then, they "reverse shadow," where the student performs the diagnosis and mitigation while the experienced engineer watches silently, intervening only if a mistake would cause a permanent data loss or an extended outage.

The part that has aged

While the Google blueprint is foundational, two of its assumptions have aged poorly for the modern, non-Google engineer.

First, the Google model assumes a level of instrumentation—clear RPC boundaries between well-defined binaries—that most microservices or monolith-to-microservice transitions lack. A new engineer today cannot always "reverse-engineer the stack" by looking at a dashboard.

Second, the blueprint assumes the original authors are still present to answer questions. In 2026, the "SME" for a system might have left the company three years ago. To adapt, make the onboarding exercise produce a living artifact. Have the new hire draw the system architecture as they understand it. A senior engineer corrects the diagram, and that corrected diagram becomes the new source of truth for the next hire. This turns a training exercise into a documentation recovery project.

The maintenance trick worth stealing

One of the most brilliant tactics from the Search SRE team is how they handle documentation decay. They sort their learning checklist by the date of the last edit. The most "rotten" or out-of-date sections are assigned to the newest joiner.

The new hire’s job is to overhaul that section of the checklist and the associated sre runbook, which is then peer-reviewed by a senior expert. This solves the documentation problem for free: the person with the most incentive to fix the docs is the person currently struggling to learn from them.

What to report

If you are an engineering leader, stop reporting "onboarding progress" as a percentage of tasks completed in Jira. Start reporting these four numbers in your monthly or quarterly reviews:

Time to First Page: The calendar days from start to primary shift per joiner.
Escalation Rate (New Joiner): The percentage of pages escalated by a new hire during their first three shifts compared to the team median.
Rotation Eligibility Fraction: The percentage of the total engineering team currently eligible for the primary on-call rotation.
Documentation Age: The median age of the last edit for the sections of your on-call learning checklist.

The reason time to first page remains high for many teams is that operational context lives primarily in people’s heads or in documents that rot the moment they are written. A new joiner is forced to rebuild the entire mental map of the system from scratch.

Self-hosted AI SRE platforms like Operate can shorten this ramp by automatically assembling standing context—ownership, recent deploys, schema changes, and related past incidents—providing the evidence a new hire needs to understand why an alert is firing. While technology cannot replace the mentorship and "Wheel of Misfortune" exercises required for true readiness, it can significantly lower the barrier to entry, making the senior engineer’s correction of a newbie’s mental model faster and more data-driven.

Sources & further reading

According to the Google SRE Book, Chapter 28, training should avoid "trial by fire" and focus on reverse-shadowing and role-playing.
As discussed on X by @chaish29, the speed at which a new hire builds context is a primary driver of engineering velocity.
Research on runbooks that run themselves suggests that encoding operational logic into tools is the next step after human onboarding.
The concept of moving rules from documents to commit hooks was highlighted by Darion Kim on LinkedIn, emphasizing that automation must support, not replace, human context.