PeoplePractitioner4 min read
How do you get the first 90 days of an observability engineer right?
A three-stage onboarding plan for an observability engineer or an SRE: understand the system, deliver a first visible improvement, take their place in on-call. With checkpoints and warning signs.
For: team managers · engineers and SREsPrerequisites: None.
Illustrative scenario. An SRE starts on a Monday. Her access arrives on Thursday. In the second week, for lack of anything better, she is put on call “to learn”. She spends her first night alone in front of an alert she does not understand, in a system she does not know. She gets through probation, then leaves after a year, explaining that she never felt she belonged.
This page closes the series on hiring, after profiles, the job description and the interview. It proposes a three-stage plan, to adapt to the role.
Before day one
Section titled “Before day one”Four things are prepared before the person arrives.
- Access. Workstation, accounts, read access to observability tools and repositories. Write access to production can wait; read access cannot.
- A buddy. A designated team member who answers questions without the new hire having to wonder whether they are bothering someone.
- A first project. A small, useful and visible improvement, chosen in advance (examples below).
- The 90-day plan. This document, adapted and shared on day one.
Days 1 to 30: understand
Section titled “Days 1 to 30: understand”The goal is to understand the system and the people, not to produce.
- Follow a user request end to end, with a real trace, alongside someone who knows the system.
- Read the last five post-mortems and discuss them with the people who wrote them.
- Meet the product teams that use observability as well as those that do not: the latter often say more.
- Join on-call as an observer: take part in handovers, read the week’s alerts, follow an incident without leading it.
- Write a “what surprised me” page: things that look odd to fresh eyes. That perspective fades within weeks; now is the time to capture it.
30-day checkpoint. A half-hour conversation with the manager, based on the “what surprised me” page: what is clear, what is not, is the first project still the right one.
Days 31 to 60: deliver a first improvement
Section titled “Days 31 to 60: deliver a first improvement”The goal is a first visible delivery, even a modest one. A few examples of first projects that work:
| Profile | Possible first project |
|---|---|
| Observability engineer | instrument a poorly covered service and show its team a trace that explains a known slowdown |
| SRE | remove or fix the three noisiest on-call alerts, measuring the load before and after |
| Platform engineer | remove a painful deployment step that several teams have reported |
| AI observability | set up a quality evaluation on a reference question set for an assistant in production |
| Telemetry FinOps lead | produce the first monthly report of the costliest metrics, with their owner |
During this period, the person moves to second-level on-call: they are called together with the first level and lead part of the diagnosis.
60-day checkpoint. The first project is presented to the team in ten minutes: what was done, what it changes, what remains. The manager gives written feedback.
Days 61 to 90: take their place
Section titled “Days 61 to 90: take their place”The goal is for the person to hold their role like the other team members.
- First week of first-level on-call, with a designated and forewarned second level.
- Coordinating an incident or running a post-mortem, paired with someone experienced.
- Proposing a larger project for the next quarter, based on what they have observed.
- Presenting a topic to another team: a workshop, a demo, documentation.
90-day checkpoint. A structured review, based on the skills grid on the profiles page: where the person stands, what is expected next, what the team must improve in its onboarding. In France this checkpoint often coincides with the end of the probation period; it must not be the first serious conversation.
Warning signs
Section titled “Warning signs”Some signs during these three months call for a quick conversation rather than waiting for the next checkpoint.
| Sign | What it often means | What to do |
|---|---|---|
| the person stops asking questions | they do not dare, or do not know whom to ask | the buddy reaches out, without waiting |
| the first project keeps growing | it was too broad, or poorly defined | cut it down to deliver a part |
| on-call comes before understanding | the team is short-handed | postpone; on-call endured too early wears people out more than it trains them |
| the person mostly works alone | the team is not making room, or the role is isolated | set up pairing on everyday topics |
| the actual work does not match the job description | the description was wrong, or the need changed | say so and adjust one or the other |
Going further
Section titled “Going further”- Sustainable on-call: the rules for on-call that holds, onboarding included.
- The blameless post-mortem: the first post-mortem the person attends says a lot about the team’s culture.
- The job description generator: the first project can be written into the job description.