New Job Onboarding Phrases — IT Phrasebook

The onboarding mindset, in English

Asking questions early reads as diligent, not incompetent — silence reads worse than a "dumb question".
Use "I'm still getting my bearings" freely — it's a normal, expected phrase in week one.
Frame requests around the task, not the person: "I don't have access to X" beats "nobody gave me access".
A 30-day check-in is a two-way conversation — asking for feedback is expected, not a sign of weakness.

First Day & Introductions

Hi everyone, I'm [name] — I just joined as a [role]. Looking forward to working with you all.

Standard self-intro for a team channel or standup
I'll be shadowing [name] for the first week to get up to speed.

"Shadow" = observe someone doing their job to learn it
Could someone point me to the onboarding doc / runbook?

Common first-day request
I'm still getting my bearings — please bear with me.

"Get your bearings" = orient yourself in a new place/situation
Who should I go to if I have questions about [area]?

Asking for a point of contact, politely
What's the best way to reach the team — Slack, email, or a stand-up mention?

Learning team communication norms

I don't seem to have access to [repo/tool] yet — could you grant it?

Neutral, non-blaming request for permissions
I'm following the setup guide but I'm stuck at [step] — has anyone hit this before?

Common in #onboarding or #dev-help channels
My local environment is set up and I can run the tests — what should I pick up first?

Signals readiness for real work
Is there a staging environment I should be testing against?

Clarifying which environment is safe to break
I've requested access to [system] — who approves that?

Following up on a pending request

Is there existing documentation on [system], or is this tribal knowledge?

"Tribal knowledge" = undocumented, known only by the team
Before I dive in, can you give me a quick overview of how [system] fits into the bigger picture?

Asking for architecture context before touching code
I want to make sure I understand the "why" here, not just the "how".

Signals genuine understanding, not just task completion
Is this the current best practice, or is it something the team is moving away from?

Avoids copying deprecated patterns from old code
Who's the go-to person for questions about [module]?

Identifying a subject-matter expert
Feel free to correct me if I've misunderstood — I'm still new to this codebase.

Softens a possibly-wrong statement while asking for feedback

This is my first PR here, so please flag anything that's off with our conventions.

Invites style/convention feedback explicitly
I picked a small ticket to start with, to get familiar with the review process.

Explains scope choice proactively
Let me know if I should be tagging a specific reviewer for this area.

Learning code-owner conventions
I wasn't sure about the naming convention here — happy to change it if there's a standard.

Non-defensive framing for a review comment
Thanks for the thorough review — this is really helpful for learning the codebase.

Genuine, common response to a detailed first-PR review

In my first month, I've focused on [area] and shipped [X].

Standard structure for a 30-day check-in
I'd like feedback on how I'm ramping up so far — is there anything I should prioritise differently?

Proactively asking for manager feedback
I feel comfortable with [X], but I'm still building confidence with [Y].

Honest self-assessment without undermining yourself
By day 90 I'd like to be able to [goal] — does that timeline seem realistic to you?

Setting expectations collaboratively
Is there a mentor or buddy assigned for the ramp-up period?

Asking about formal onboarding support