During their first days on the job, every new hire will develop relationships, establish norms, observe workplace values, and lay the technical foundation upon which future work will be built. As a result, employee onboarding plays a central role in the long term success of every team member.
To provide a few reference points for your own engineering organization, we've asked senior technical leaders from across the GTA to share their hard-won learnings on effective onboarding for software developers.
I’m going to talk about my experience as VP Engineering at Top Hat where we onboarded over 40 developers in 40 weeks during a period of rapid growth. We were hiring full-stack engineers to build out our education platform.
I will highlight four key points that contributed to our success:
Onboarding is often overlooked when choosing technology platforms. The problem is it could end up having the biggest impact on your organization’s velocity during the scaleup phase. When we evaluated potential front-end platforms, onboarding ease and timeline was one of the most heavily weighted items in our selection criteria. It was absolutely essential in our success onboarding over 40 developers in 40 weeks while still delivering on our deadlines.
We always paired new hires with an existing developer and had them do some real work on the first day. The most typical first-day onboarding project was to fix a bug, create a unit test, deploy it to a test environment, test it, and have it ready for the next deployment to production. If getting that done is a tall order for new hires, you should look carefully at your systems and tools to see if you should be investing there.
Make sure you put onboarding in your project and capacity plans! Onboarding a new hire will subtract capacity from your team for some period of time. I can't tell you how many times the project plan assumes the team capacity will increase the first day a new person starts. That never has a happy ending.
I always suggest checking in with new hires early and often. I still like a suggestion I got from another CTO to use a Fibonacci-like timeline (day 1, day 2, day 3, day 5, day 8, etc.) until they are fully onboarded. Check-ins include talking to the new hire and the pairing partner or lead. This is so important because every person is different and there are often struggles on one or both sides that can be easily addressed before they become big things.
It is so easy to just hire someone smart, leave them on their own, and let them figure things out, especially if they don’t say anything. Don’t do it! A check-in doesn't have to take a lot of time. In addition to detecting early problems, it sends a message to your new hire the team cares about their success. It also sends a message to your team that high standards and onboarding are really important."
A great onboarding process starts before the employee does, and is far more than merely enabling an employee to do their function. It's an opportunity to set an employee up to thrive in their role. We supplement a checklist of activities with a multi-week curriculum. On top of this, we work with the developer to set tangible goals for their first day, week, month and quarter to give a sense of progress and achievement. Successful onboarding is a slingshot that propels productivity.
As soon as a candidate signs their offer, we create a new checklist from our template. This puts in motion the basic things like ordering hardware, setting up accounts, and assigning a buddy. A week before the person starts, we try and share a PDF of our last monthly meeting and a peek at the curriculum to ensure familiarity. On their first day, we have them set up their app, and in their first week, ship their first changes to production. The curriculum begins with development best practices and processes, expanding to collaboration among other stakeholders inside and outside the product teams. We also highlight our business model and build on this foundation by introducting layers of internal systems, up to the external services with which our applications interact. The goal being a broad understanding of how to be productive. We also provide ample opportunities for feedback on how to improve the onboarding program, with each iteration getting better.
Adding a new team member can be a risk, as the dynamic of the team will change. As a team lead, it is important to ensure the new hire has the tools they need to succeed and to scale the learning curve efficiently. The most important part of onboarding is to clearly lay out the expectations of what it means to belong to the team; both personally and professionally.
Beyond that, all team members should be involved in the on-boarding process. As an agile team, we ensure that there is ongoing knowledge transfer between members. Introducing a new team member brings a fresh perspective to technical challenges and is a fantastic opportunity to improve the design of your software. Providing new hires with refactoring tasks or design enhancements allows them to become familiar with the code base, all the while improving the quality of your software. Onboarding is not just ensuring a new hire learns the ropes quickly, but also an opportunity to expand the skillset of the team and ensuring that the knowledge they have from previous experiences translates to positive impact within the company.
The most critical part of our onboarding process is defining an individual Vision, Values, Methods, Obstacles, Measurements (V2MOM) document as a method to orient and align all employees as early as possible. It's fantastic for clearly defining expectations and a path to success. Measurement can be tricky for engineering but ignoring the need to track progress everywhere is not an option, so we share V2MOM documents through the whole company. This allows those joining to have a solid reference point for their own goals.
New hires take have two weeks to read the V2MOMs of peers and leadership before sharing their own path. This naturally fosters alignment with across the team, and largely prevents early performance issues. V2MOM, combined with pairing and early contributions to production apps are the key components of our process for empowering happy and productive engineers.
The first day of onboarding at Drop includes meeting with all departments to gain full context about goals, initiatives, and people. Understanding the bigger picture and making connections on day one are important to enabling our newest members.
Within Engineering, new hires are set up for success by matching them with a new hire buddy to take on a starter project with the goal of making an impact in their first week. We don't expect new engineers to have experience with our precise tech stack and so the first 3 weeks are allocated for ongoing education of architecture, frameworks, programming languages, and more. Beyond a new hire's first 3 weeks, we help define a roadmap and mentor engineers to be increasingly autonomous, self-sufficient, and driven.
I look at onboarding for new technical employees as an opportunity for someone on the team to exercise their leadership muscles, so I always assign one person to be the designated technical contact for the new hire, who will show them around the technology and help them as they go for the first month or so. This isn’t always someone in a formal leadership role, and can be a way for me to see how someone does in this kind of task as a trial for future formal opportunities.
This also gives me, as the manager, an opportunity to focus on the parts of onboarding that too often get forgotten: an explicit introduction to the spoken and unspoken culture of the team and the organization with a particular focus on when and how we communicate. Making explicit the expectations around communication avoids a lot of problems and gives your new hire a much better chance of succeeding.
Our secret weapon for onboarding new developers -- and for onboarding every other role in the company -- is that we start every new FreshBooker as a customer support "rock star." After about two weeks of intensive training, we put our new folks on front-line phone and email support. That gives everyone a very thorough grounding in our product, how it works, and -- most importantly -- in our customers and what their biggest concerns are.
Having had direct contact with our customers, and having worked through their biggest pain points, puts everyone in a position to reason about where we should be going next, and about what our customers care about the most. And it teaches a deeper understanding of where our company culture comes from than I've seen
Great onboarding is critical, especially at a company with a highly impact-driven culture. At Authenticiti we deploy decentralized supplychains for large industrial manufacturers using blockchain -- a very niche technology that few developers have experience with. The two primary challenges we initially encountered during our engineering onboarding were 1) Educating engineers with enough blockchain knowledge to understand how our platform works, and 2) Quickly setting up engineer laptops with the necessary software and tooling to quickly jump into Authenticiti's code bases.
In order to help new hires tackle 1), we divided blockchain knowledge into prerequisite conceptual groups, categories such as distributed systems, cryptography, consensus algorithms, etc. From there, we created an in-depth internal wiki of highly curated tutorials and articles for each concept in an order that resonates with the concepts. We found that this self-help wiki (along with asking other engineers clarifying questions), helped quickly ramp-up engineers onto our niche tech stack and got them writing meaningful enterprise blockchain code sooner.
A process we've implemented to radically improve 2) was creating dedicated employee Docker images. We found that having employees install tooling on their new laptops individually was a manual, cumbersome process that was prone to human error. Instead, we opted to create dedicated full-stack Docker images with all the necessary software and tools so that on their first day, employees are given laptops that have everything they need to get started at Authenticiti. Having a Docker image ready-to-go for new hires significantly sped up our engineer onboarding.
When it comes onboarding remote or junior employers to a project, I've worked with several companies who were initially apprehensive about this untapped pool of talent. However, given that a large number of developer positions are going unfilled, and that the cost of hiring this talent is increasing, it's been important to effectively onboard these high-potential individuals. The process I've developed has three pillars: team, process and product.
To integrate remote or junior employees into a team, it's our responsibility as the leadership to ensure that they are held to the same standards as everyone else in a team. This can be enabled by standardized communication channels (for example, standup bots and channels on Slack). Discussions on issue trackers, shared code standards and team code reviews are also great ways to ensure everyone understands the playing field and knows how to contribute.
While a team is becoming integrated with remote or junior employees, it's important to have a simple process everyone can follow in delivering their respective contributions. It's not enough to say, "We are Agile." Each step of the process (from requirements gathering to delivery) has to be made visible for everyone to contribute to. A Kanban board can be very effective in communicating this process across larger teams. For smaller teams, keeping everyone abreast of release schedules through email, Github or Slack can be effective.
Finally it's crucial to bring the team together in working on a common, impactful goal. Sharing the broader product vision can keep a team product-focused and oriented towards delivering great results. For example, communicating customer feedback (good and bad) with a team can be very inspiring since everyone can see the shared impact of their work.
To get great results, we are careful to give remote or junior developers the same mentorship, tools and methods to be involved that we offer to colocated team members. That expectation and support helps them take ownership, contribute effectively and flourish in our businesses.
We've found that for onboarding to be effective it's important to have both teammates to mentor them as well as other engineers they can ask questions to who aren't their direct teammates. This gives them a mentor/contact they can go to without feeling embarrassed.
Further, we ensure that their tech lead sets aside dedicated time to meet with them 1:1 on a weekly basis to follow up on their technical progress as well as their career progression beyond the day-to-day work of writing code.
During onboarding, we place a large emphasis on opening a two way dialogue with each new employee. We co-create a document outlining expectations and explicitly make it as ambitious as the hire feels comfortable with. Then, depending on their skill level, we let them jump in. Along the way, we offer daily check-ins to ensure they have access to learning materials and are making an impact.
The most important part for us is actually communicating expectations and consequences. I've seen organizations where people have more cookie cutter roles (ie "intermediate front end developer") that outline exactly what is expected of the employee. As a result, individuals often take some time to find their own unique approach and cadence of contribution.
Since we are a small company, we set high expectations in short time frames. Our goal is to have new employees feel comfortable chiming in and shaking things up as soon as possible. To achieve this, we set clear and ambitious goals for the probation period. We do this with the understanding that it will take a lot of support and effort from the whole team in order to make it work, and even then some people might not make it. We just have to be okay with that.
Proper onboarding can make or break an employee’s experience. A good onboarding experience ensures employee engagement, while a bad experience will cost the organization in lost productivity and reputation, which hurts all parties involved.
In my 20 plus years experience in the tech industry, it's become clear that when you hire an engineer no matter where they come from it’s imperative to help them through your organization’s processes (which can be many and overwhelming). This can be as simple as getting the right equipment and login information for their first day, to educating them on how to check in their code in bit bucket and deploy a microservice. As a leader, if something needs changing to improve onboarding then you need to drive those changes. That’s on you! And remember, you are only as good as your weakest link, so make sure you have a strong chain and keep building
Staff happiness is one of our most cherished goals at Maple. As a whole, we onboard any new hire, engineering or otherwise, with a focus on making them feel welcome and organized. They get a sense immediately that we value their investment in us as a company and are excited to have them.
The process for onboarding engineers at Maple is always evolving. As our platform grows in complexity and the breadth of user-facing products expands, we continuously examine and update the process. One of the things we do is have new hires go through our onboarding documents with little intervention and encourage them to implement their own suggestions. We give them access to our onboarding Wiki and they can directly make updates to improve it. This allows each hire to have an impact on day one.
Beyond this, the process starts with becoming a power user of our products. They learn all the features and use-cases and get a solid foundation of the platform as a whole. It's easy to get overwhelmed as an engineer coming into a company with a lot of product surface area so we watch closely for that and adjust the path accordingly with each new hire.
Successfully onboarding a new developer requires both an organized codebase and setup process along with an onboarding buddy. Setting up a new development environment should take a couple of hours at most. We achieve this by having clear setup documentation and any config or data needed in version control. If anything is missing, the new hire is responsible for revising the docs accordingly, in order to improve the process for the next individual.
Beyond this, the developer receives a buddy to show them the ropes. This buddy walks them through the code and processes, acts as a sounding board for questions, and helps them get to know how the team operates.