Onboarding Vocabulary for Developers: Bus Factor, Runbooks, and Knowledge Transfer Language

Starting at a new company as a developer is overwhelming in any language. You are simultaneously learning a new codebase, a new team culture, a new set of tools, and — if English is not your first language — navigating professional communication in a second language. This article covers the specific vocabulary you will encounter during onboarding, whether you are the new joiner, the experienced engineer mentoring them, or the manager overseeing the process.

The 30-60-90 Day Plan

The 30-60-90 day plan is a structured approach to the first three months at a new job. It divides the onboarding period into three phases with different goals and different language to match.

Days 1–30: Observe and absorb. The expectation in this phase is that you are learning, not yet delivering. The vocabulary reflects humility and curiosity:

“Getting up to speed”: becoming familiar with the codebase, processes, and team dynamics
“Ramping up”: the gradual increase in productivity and contribution
“Learning the codebase”: reading existing code, running the application locally, understanding the architecture

“I’m still ramping up, but here’s my initial read on the system architecture.” “I’m getting up to speed with the deployment pipeline — is there a runbook I should start with?”

Days 31–60: Contribute. You are expected to begin producing work, usually on well-scoped tasks.

“Owning my first feature”: taking end-to-end responsibility for a small piece of work
“Making an impact”: producing something measurable — a merged PR, a fixed bug, a shipped improvement

“I’d like to own my first feature this sprint. Can we find something that’s well-scoped and not blocking anyone?”

Days 61–90: Lead. You begin to act as a full team member, driving your own work and contributing to others’.

“Driving initiatives”: taking ownership of a goal or project, not just a task
“Sharing what I’ve learned”: actively contributing knowledge back — writing documentation, running demo sessions, mentoring the next new joiner

Phrases for 30-60-90 check-ins:

“I’d like to take on more ownership in the next 30 days — what would be a good area to focus on?” “I’m still building context, but here’s my initial read on the tech debt situation.” “I feel like I’ve hit my stride — I’d like to be considered for the next feature lead opportunity.”

Buddy System and Onboarding Roles

Many engineering teams assign a buddy to new joiners — a peer who provides day-to-day practical guidance for the first few weeks. The buddy is different from the new joiner’s manager: the buddy has no evaluative power and offers a psychologically safe space for questions.

The buddy’s role in plain language:

Answer “where do I find X?” questions without judgment
Be available for informal check-ins
Help decode team culture and unwritten norms

Phrases for asking for help without feeling vulnerable:

“Can I sanity-check my understanding of the authentication flow with you?” “Before I go down a rabbit hole — is this the right approach, or am I missing something obvious?” “I don’t want to bother the whole team with this — can I ask you a quick question?”

The phrase “go down a rabbit hole” — meaning to spend a disproportionate amount of time on a side investigation — is extremely common in engineering teams. Learn it early.

“There are no stupid questions” culture: Many high-performing teams explicitly verbalise this norm. As a new joiner, take it at face value. Asking a question that surfaces a documentation gap is valuable. Not asking and spending three hours on a solved problem is not.

Knowledge Transfer and Documentation

When someone leaves a team, or when ownership of a system changes hands, teams perform a knowledge transfer — a structured process of moving institutional knowledge from one person or group to another.

Brain dump vs. structured handover:

A brain dump is an informal, unstructured outpouring of everything someone knows — useful as a starting point, but not usable as documentation. A structured handover imposes organisation: what are the systems involved, what are the common failure modes, who are the stakeholders, what decisions were made and why?

Core documentation types:

Runbook: a step-by-step operational guide for a specific process or system. Think of it as the “how to keep this running” document. Example: “This is the runbook for the payment pipeline failover procedure.”
Playbook: a higher-level guide covering a broader scenario, often including decision trees. Where a runbook says “do these steps in order”, a playbook says “in situation X, consider options A, B, or C”.
ADR (Architecture Decision Record): a document that records a significant architectural decision — what was decided, why, what alternatives were considered, and what the consequences are. Example: “The ADR in the repo explains the rationale behind our decision to use event sourcing for the order service.”

“I’ll write a runbook for the cache invalidation process before I hand this over.” “There’s an ADR from 2024 that explains why we chose this message broker — read that before suggesting we switch.”

The distinction matters: a runbook tells you what to do; an ADR tells you why something was built the way it was.

Bus Factor and Tribal Knowledge

The bus factor is a risk measurement: how many people would need to be unexpectedly removed from a project — whether by leaving, illness, or being hit by a bus — before the project would fail? A bus factor of one means a single person holds critical, undocumented knowledge. That is a serious organisational risk.

“Our bus factor on the billing system is one. Priya is the only person who knows how the reconciliation script works.”

Tribal knowledge (also called tacit knowledge) is the accumulated understanding that exists in people’s heads but is never written down. It includes: why a particular workaround exists, what the legacy system’s edge cases are, which stakeholder to call when the approval process is blocked. The problem with tribal knowledge is not that it exists — it is that it only transfers through proximity and time.

Mitigation strategies and their vocabulary:

Pair rotation: intentionally pairing different team members on different systems to distribute knowledge
Documentation sprints: scheduled, focused time for the team to write down what they know
Knowledge-sharing sessions: informal presentations or walkthroughs where one person teaches the rest of the team something they know well
Single point of failure: in a people context, a team member whose absence would break a critical process — the human equivalent of a non-redundant system

“We need to run a documentation sprint before the Q4 release freeze — there’s too much tribal knowledge on the new pipeline.” “She’s a single point of failure on the infrastructure side. We need to get at least one more person up to speed.”

Say-Back and Teach-Back Techniques

The most reliable way to confirm you have understood something is to say it back in your own words, not to nod and hope. This is especially important when learning a complex system where one misunderstanding compounds into ten.

Say-back phrases:

“So if I understand correctly, the flow is: the API receives the request, validates the token, then publishes an event to the queue — and the worker picks it up asynchronously. Is that right?” “Let me just confirm: when you say ‘the old system’, you mean the monolith, not the new microservice?”

Teach-back technique:

The teach-back goes further: after learning something, you explain it back to the person who taught you. This surfaces gaps your own brain smoothed over.

“Let me explain it back to you to check my understanding — tell me where I go wrong.” “I’d like to give a short walkthrough of what I learned about the deployment process. It would help me consolidate it, and you can correct anything I got wrong.”

Documenting while you learn:

“I’ll add a note to the wiki as I figure this out — that way the next person doesn’t have to go through the same discovery.” “I’m going to write up what I learned about the staging environment setup while it’s fresh.”

Phrasing uncertainty professionally:

“I’m about 80% confident in this — let me verify the edge case before we proceed.” “I think this is right, but I haven’t seen this code path in production. Can someone who has take a look?”

The ability to distinguish between what you know, what you think you know, and what you need to verify is one of the most valuable professional communication skills in engineering — and it is a skill that requires specific language to express well.

Continue Building Your Onboarding Vocabulary

Practice these concepts with exercises designed for real developer workplace scenarios:

Whether you are navigating your first week at a new company or helping a colleague onboard effectively, the right language makes the process faster, clearer, and less stressful for everyone involved.