1. Pair programming: lots of pairing between senior and junior devs.
2. Improve the onboarding docs: It helps when you have a set of onboarding work and the new hire does a good job improving and clarifying them as they learn
3. Easier tasks: we almost always have a set of tasks we need to do that’s easier, and we can get someone started on these
4. Hiring self starters: I think it’s important for people to “own their one development”. It’s incumbent on them to own their onboarding as much as it is on the team
5. Find a place to apply unique skills: it usually doesn’t take too long before the new hire sees an area where they have past experience that can help solve a pain point. This is important to encourage.
6. Lots of positive encouragement: obviously it’s important for the whole team, especially managers, to create at atmosphere of trust and safety where the new hire can give and receive frequent feedback.
While at a previous job, and being responsible for onboard new co-workers, having easy tasks ready at day one help create a sense of purpose and being part of the team.
We would alway try have a new co-worker deploy something to production on day one. Ideally something they could point to on the website a say "I did that". Combined with your point 6, letting them know that they did something that mattered created a sense of being part of the company on day one.
It just depend of the company whether or not pairing up with someone makes sense. If you don't really work that way day to day, then you shouldn't give new employees that impression. There is however a point to not having people feel like they are just picking off a list of never ending tasks, which could just as a easily have been solved by someone else.
1. A week before their joining, we ship the laptop
2. I'd have a calendar ready for them, which gives an overview of what they will be doing for the next three months
3. First week goes into setting up the tooling on the machine. Someone from the product team gives an overview and entire product walkthrough. Next, they spend some to play with the product as a user. This week also involves the initial orientation session.
4. We use Golang heavily, however, the people joining might not know it. The second week goes into doing the tour of go.
5. Third week they spend on onboarding tutorial that shows how to write a small service, generate APIs, build, and deploy it in our infra.
6. Fourth week they will spend shipping a really small feature to the production.
7. Since day one, they'd have assigned a buddy who becomes their go-to person. Buddy also explains them about the culture, how things typical done here etc.
8. First three months, they'd spend working on a feature along with someone which also involves some good amount of pair programming.
(I am not a manager or a team lead, but trying to fix the issues which I have seen in the onboarding)
1) They need to be integrated into the culture and feel like they're part of the team from day one - this may not be their first literal impression (because of interviews, previous interactions potentially) but it's a really big one.
2) Make sure they have what they need and that others in the org prioritize them! Too many times I've seen a new hire come and folks from other teams who we interact with don't want to take time out of their schedules but this is absolutely critical... they're joining a whole org, not just your team. I've also seen lots of places drop the ball on basic things like making them sit around and wait for access to specific systems even though there was weeks of lead time that this person would need it at 9am Monday. Total unforced error and makes the company look unserious.
We are but a small (10-15) team in a very large company - so the first day starts with reading the general company docs, supplemented with an funny personalized introduction to our team and what we do. Otherwise you are overwhelmed by getting to know your laptop, team and introduction banter.
Each day of the introduction week we try to have a lunch with one collegue or the entire team (now with working remotely, it is trying to be in the office for the occasion), and also at the end of each working day a personal conversation with another colleague of the team.
During the two weeks of onboarding the new member will be introduced to the devops, the tools we use, the projects we do, etc etc etc. There is also plenty time to get to know the techniques we work with using Pluralsight courses (because we have a old .NET Framework stack and a new .NET 6 stack).
Besides that, there is also a series of practices to do. Via a prepared project, the employee will, together with the courses mentioned, build a small application. Each assignment is discussed and code reviewed.
At the end of the two weeks the new member knows the entire team and is ready to collaborate in a client project.
Interesting that you have a prepared project, rather than have them work on contributing to a something "real". Is this a function of your company doing client work? I'm at a product company, so can see more benefit with having a contribution to the product, but I would like to understand this aspect more.
- It's OK to not know the answer*
- Always tell the truth*
- Show people you care
- Do the best you can
- Show up on time
- Finish what you start
- Do what you say you will do
When you start a new role, you come in with no technical debt & are fresh. I want people to maintain that as long as possible and question why it is we do what we do. Often having the freedom to say "I don't know" exposes the kinds of things that happen because they've always been done that way and makes the team explain what we're doing, and why we're doing it, at least once.
*It's ok not to know, but take action to find out the answer / get the truth. Don't make crap up if you're unsure, and don't smile and nod if you aren't understanding what's going on. This doesn't help anyone. It's ok to pause and get the right data.
**If you knowingly lie, you can get off my team. But most lies are driven by the fact that people feel scared to follow rule 1.
*** three of these are Lou Holtz' 3 rules.
- A developer becomes productive within a week.
- We don't stop at onboarding — new joiners are well supported until they feel completely comfortable in all aspects of the role (and beyond).
- The onboarding is self-driven — the time spent with colleagues is always spent on valuable discussions rather than providing information or training that could be done offline. As a manager, I often spend < 3 hours with a new joiner in their first week.
- Developers (and everyone else in the company) rave about it :)
We're now working a new business focused on helping companies document their processes and onboarding, and we're having a lot of success with our early adopters. We offer free consulting to help team's prioritize, plan and implement role onboarding (— with no requirement to pay for the tool / become a customer). If you're interested, drop me a message on LinkedIn and we'll get a call in the diary :)
1. We created a onboarding page via Google Sites where new employees get all the information in their onboarding process: Like all the details about their first onboarding week, informations about their future co-workers, tutorials about tools that person will use daily in our company and informations about the tech of our product
2. We have a Buddy program where our existing employees (department doesn't matter) will be always available for questions and go fur lunch/drink coffee in the first week
3. I also can't imagine a great onboarding experience without HR software support. We are based in Germany and use Personio as our all in one HR-tool
4. Perhaps it goes without saying, but the employee should get used to the team as quickly as possible in the first week
Use onboarding tools to make the transition from candidate >> ATS >> Payroll >> Benefits >> Devices >> System Access >> Orientation Wikis
truly simple, and hard to break.
We use a combination of Rippling and Clickup to achieve this. But these are by no means the only 2 solutions out there.
No software setup will suceed, unless you have all functions connected to the setup of the process.
Do you have a similar process for this "into team" stage of onboarding? Are the tools you mentioned useful?
A few things that I've observed helping:
- the aforementioned tech helps pointing the out "bridges" the can cross. Onboarding should capture team (team= DEV, or team=OPS or team=QA, etc) which gives the employee (via password manager), inmediate access to all the virtual "water coolers" that the team uses. Think slack channels, JIRA Projects or Clickup spaces. From that point its up to the candidate's curiosity, and helps the new addition feel included. Employees can't be a part of the team if they aren't part of the conversation. That conversation is the bridge they need to cross, of course.
- The military uses the buddy system for good reason. Its generally a very good idea to pair up hires during orientation if your pipeline allows for this, even if they are not the same function.
- Some extracurriculars are also helpful. Book clubs sponsored during company lunch time, periodic hackatons, etc.
- One thing that can help is a flex budget for late night dinner or drinks. A lot of socialization happens in the latter part of the day, particularly of the team is working late on a regular basis. The seamless credit, or that company tab in the bar across the street can go a long way. This just needs to be done responsibly.
I was once asked by a founder to help setup mongodb and react on their laptop to get started with a hello-world application while we were sitting in a cafe. Little did I knew it was a job interview. Interesting way to identify if a person is self starter or not.
Can you describe further the context of you sitting at a cafe with a founder?
did you know you were meeting a founder?
Were you there as a friend ?
What was your primary motivation for being there with the person?
It’s informal and you discuss topics such as feedback, communication, likes/dislikes.
It’s helped a lot to learn everyone’s similarities and differences in an hour vs several months.
I look forward to reading the doc. Perhaps you could post a link when it is published?
Every member of the team a new hire is on should be part of the onboarding, especially if people are remote. This means taking initiative to check in with a "how are you settling in? is anything blocking you at the moment?" sentiment over the next several days/up to 1 week, being available and prioritizing questions from the new hire, offering things the new hire may not even know they don't know (eg. "do you want a demo of our product? do you want a brief who's who? do you want a 101 on $some-internal-tool?")
And of course, if the new hire says nah, to fully accept that and once its communicated that they can reach out to anyone for assistance on the team with zero judgement, to fuck off and let a (gender-neutral) guy work.
- OSS best practices: readme/development.md, docker, GitHub actions for CI/CD, GitHub wiki/issues/projects, conventional commits + PRs, etc: folks know most of the software lifecycle norms, how to navigate, quality expectations. OSS evolved for remote + async collab, so even better as we've gone int'l-friendly.
- One click / command to get a full instance of a service or server. Whether 'docker compose up some_service' or labeling a PR with 'staging' (ephemeral instance per PR) or 'release', that's it.
- Boring code: We focus our innovation points in a few areas (GPUs, graphs, UI, ...) and as much as possible try to mold the crazy stuff into proven stuff . Likewise, avoid NIH for as much as we can (ticketing, ...). Ex: Our core product python GPU services app is built with asyncio , rapids.ai , arrow, etc, but packaged as REST for internal service consumers. Likewise, most of the cloud/CRUD tier is 'just' a Django app + node, so having / thinking about GPUs is not required when developing that stuff. So teammates can building wild things where it matters, but for the standard things, have proven , predictable, and well-maintained OSS.
- Easy service onboarding. Almost all HR via modern services (gusto, Carta,..), + dedicated person (we are small so share our book keeper with other startups). Same for dev, limited consolidated services with prebuilt roles, though we can do better there (SSO, ..).
- Team member / project match. We ensure a match for the new hire: tech, type of work style, initial project scope, etc, so they have a strong sense of what to do initially. Likewise, longer-term, we hire for them to own/push a general direction, so we try to have a sense of natural succession of projects. Eg, currently hiring to help with cloud tier full stack UI, BI tool integrations, and potentially starting our GPU graph data science / infoviz R&D unit: all with clear first and successive projects.
- hiring constraint: no hires for an area until it is sane. We do have some legacy cowboy code areas with hard dev envs, and want to hire folks for them.. but unless the job is explicitly tearing that stuff out, nope, that'd be a waste of good people.
This stuff is important for increasing individual leverage/scale, enabling crazier tech, and opening the hiring pool. If I was going to start another co, would do again.