Fahim ul Haq is the co-founder and CEO of Educative, the world's leading upskilling platform for and by developers. He is a former software engineer at Microsoft and Facebook with a deep passion for creating better, more efficient ways for developers to master in-demand skills.

As mentioned in my previous newsletter on the Core Tenets of Engineering Enablement, the onboarding experience is the first impression developers encounter when joining a new team and company. Overall, the onboarding process affects developers on a personal level and leaves a larger impact on a company’s goals.

With today’s highly competitive job market, especially in tech, engineering leaders are usually focused on building developers up to minimum workable knowledge. With high team churn, merely having engineers capable of contributing to the product roadmap and squash bugs is a seemingly endless challenge. Having built a startup myself, I’ve felt the urgency to get developers to production as soon as possible.

But the real challenge begins when the company needs to rapidly scale their product to stay competitive. At that point, a forward-thinking onboarding framework is better suited to enable developers and help a company thrive more efficiently. 

By approaching onboarding with this goal, we can start by identifying onboarding in distinct stages. Each stage should push a developer to become more productive, provide a bigger impact on the team, foster a culture of continuous learning, and lay the foundation for a product to scale.

Tied to a developer’s lifecycle, developer onboarding has three distinct phases or stages:

• Stage 1 Onboarding: Minimum workable knowledge 

Giving the developer the ‌tools, processes, and technical understanding to contribute code with minimal supervision and setup time.

• Stage 2 Onboarding: Team-oriented developer

Stepping up to contribute to team-level activities, e.g., code reviews, deploying to production, etc.

• Stage 3 Onboarding: Leading with long-term thinking

Contributing to the long-term success of both the product and the team, e.g., design discussions, recruiting, mentoring other engineers, and participating in performance reviews

This newsletter summarizes each stage at a high level, but does not provide a comprehensive approach to these onboarding stages. I want to start the conversation around a developer onboarding framework ‌I believe better fits today’s challenges and offer one solution to implement this framework. I plan to give a more detailed and applicable breakdown of the broad practices mentioned below in future newsletters.

Stage 1 Onboarding: Acquiring minimum workable knowledge

Here’s what an engineer does during Stage 1 Onboarding:

1. Understand core technologies used in the product: programming languages, frameworks, APIs, deployment infrastructure, et cetera; for example, at Educative we use Python, JavaScript, React, Google Cloud and more.  

2. Acquire a working knowledge of tools, e.g., Git, CI/CD.

3. Go through internal documentation (if it exists) to learn about 

   • The overall architecture of the product

   • Structure of the codebase

   • Reasons behind the major design decisions

   • Internal or product-specific API, frameworks and libraries

4. Connect with team members and recognize their areas of strength

Once a developer has shipped a few features and has gone through a few release cycles, they ‌get comfortable with the codebase, tools, and frameworks. Then it’s time to uplevel them to help other team members. That brings us to Stage 2 Onboarding.

Stage 2 Onboarding: Contributing to team success

Stage 2 Onboarding includes things like:

• Code Reviews: It’s hard to do effective code reviews without having a certain comfort level in the codebase. Every engineering org is different, and it’s good to train engineers on how to perform productive and useful code reviews. Developers at this stage need enough functional knowledge that allows them to give valuable and succinct feedback to ship great products. 

• Deployment: Most companies have a release cadence ranging from a few days to a few weeks. No matter how frequent or infrequent the release is, there is always some work that needs to be done to prepare the build for the release, roll it out slowly while monitoring interesting KPIs, and verify everything works accordingly after the deployment has completed.

• On-call Duties: Most products these days are online services that need to maintain an SLA of 99.9% or better. That requires dedicated developer support to quickly debug and mitigate live site issues as they arise. On-call is the designated developer for a specific period (typically a week) who triages all alerts and issues and either mitigates them or involves other team members based on the severity.

  A new engineer cannot become an on-call right away. It requires a certain amount of working knowledge of the overall product, understanding of the KPIs, and the tools available to quickly assess the impact of an issue, etc. Now that the engineer has some experience under their belt, they can assume the on-call duties. Wish them luck, as the ride might be bumpy in the beginning. 

With more in-depth knowledge around deployment, building roadmaps, dependencies, and building production rollout plan, your developer is ready to start helping lead the team in activities and planning with long-term impact. While the comments in this section can feel more theoretical, I’ll dive deeper into each topic in future newsletters. I also know that I’m not covering everything that has to do with this stage, so I’m curious to hear your thoughts.

Stage 3: Leading the team through long-term thinking

Now that the developer has developed a breadth of team knowledge alongside a depth of technical expertise, they should be trained to lead the team through prudent decisions. They are now taking part in long-term decisions and activities with a generational impact on future teams and developers building the product.

Stage 3 Onboarding includes things like:

• Recruiting & Hiring: Hiring the right team members can have a generational impact on the product and the team. Developers entering this phase should be trained to evaluate a candidate’s potential success in the role they are being interviewed for. A developer understands the basic journey of every candidate from personal experience, so the training at this stage should be evolving as the company grows (i.e. your interview and hiring process should look different at every growth stage of your company and product).

• Architecture & Design reviews: Participating in discussions about architecture and design reviews should be supplemented with a firm knowledge base. Making these decisions will have strong downstream effects that can last for years to come. The consequence of incorrect architecture can result in huge costs later down the road.

• Mentorship: Mentorship is an important way to help people around your developer grow and raises the bar for the entire team. Effective mentorship as a senior developer revolves around being available for other junior developers to seek help. It’s not necessarily a regularly timed meeting, but part of building a culture in being ready to help others. Your developers will grow to be someone who provides a more clear and stronger opinion that might also address nuances of the organization. 

Once a developer becomes onboarded across these 3 stages, they are prepared to step into the next role as an engineering manager, tech lead, and so on. 

Final Thoughts

When I was a developer myself, and even in building out our own engineering organization, we didn't really have robust tools to seamlessly move developers from one stage to the next. Scattered documentation, wikis, skip-level and lateral connects, a checklist on a shared doc — this was the reality of onboarding at Microsoft, at Meta, and at Educative.

As we speak to speak to developers and engineering managers today, we find similar problems. Some are kludging Confluence, while others refer to knowledge bases. Some HR teams have a process, but it's not optimized for developer skills, and it's not usually managed by the team who brought the new hire on.

There's still work to be done to truly unleash developer potential, so I'm curious to know how other leaders are developing their onboarding processes and growing developers’ careers.

Next up, I’ll share a more detailed perspective around the current state of developer collaboration and how collaboration should evolve with today’s tech environment. Make sure to hit subscribe below to stay in touch!