"I accept." Every engineering manager hopes to get this reply in an email from the great engineering candidate they have interviewed and convinced to join their team. Great. Time to call it a day, relax? Not so fast. The real challenge begins in two to four weeks when the engineer will show up on their first day. Then the journey of onboarding them and working with them begins, so that they can become productive as soon as possible. There's a lot to cover, and a lousy onboarding experience can cause them to quit. So, no time to relax. The Developer Onboarding Problem Developer onboarding is a bit of a mess. Partly due to poorly defined goals and even more poorly defined processes. But it’s also partly due to a misaligned toolkit (more on this further down). In the case of goals, when is a developer fully onboarded: when they deploy code to production; when they can fully participate in code review; when they can serve as on-call without hand-holding; when they participate in the design and can link the product within the broader ecosystem and business goals of the company? If a developer joins a team from a different org inside the same company, they probably already hold a lot of necessary knowledge: the codebase, tooling, and processes used. What they won’t know intimately are your specific product and team project. On the other hand, a new hire from another company might have to ramp up on a new language, switch from an internal repository to pulling from Github, and have to learn why this legacy code due to integration. (And no, the code snippet isn’t commented out in detail, because of course it’s not.) can’t be touched because it will break a seemingly completely different product managed by a different org An EM can bring either lateral or completely junior new hires onto a team, and each will have different onboarding needs. They have different skills and hence different timelines. They have different career goals, and therefore different things they want to take out of the job. Then there’s the ongoing reality of a product launched or a project completed, and now the team is on to the next thing. In that, they’ll be into a new project, ramping up on new languages, features, frameworks, or design approaches. They’ll need new and additional skills for a new project or a new product, or even to update or migrate the existing product. onboarding In other words, , and even after achieving ramp-up, it has to be continuous. In addition, it has to be specific and secured to your internal processes and tools, while pulling expert data from outside sources. Onboarding needs to become an discipline. onboarding has to be personalized enablement At the same time, a company’s strongest asset - its - should be deployed to its greatest strengths.  If they have to work with every new engineer for weeks to onboard them, the onboarding process can’t scale and will require a lot of repetitive work. people So how do you utilize your own expertise to build and deploy a personalized, continuous enablement platform, one that can get your developers up to speed and empower them through new learning, new projects, and every career step? The State of Onboarding A few years ago, I left my job at Facebook and founded a startup. As we hired our first employees, we used to onboard people with a checklist in a shared Google doc (with links to other Google docs and wiki pages). That was lousy. However, most other companies are no different. Some use Confluence, which isn’t designed for onboarding. Many teams create onboarding tickets in Jira or Asana and rush developers to production code - basically, learn by randomizing. But that puts the burden on the engineer to find resources to learn the technologies that are used, learn the product architecture, and learn internal libraries and APIs - all without any clear path. As a fellow founder has , these different approaches, resources, and nebulous definitions of onboarding put most engineering teams at a significant disadvantage. documented here at HackerNoon None of these are solutions for software engineering teams trying to scale quickly, purposefully and efficiently. They are hacked together, not engineered. actual Engineering an Onboarding Solution In order to engineer a solution to , I’m going to approach this as a system design exercise. We are going to design a scalable system that supports multiple users in a directed learning environment. developer onboarding Requirements for Onboarding Support for multiple users and user classes Managers Team members Mentors Structured and directed learning Modular library of technical material Creation of material as needed Interactive learning environment Surfacable insights (reporting) User-based personalization of onboarding paths Collaboration between the new engineer, mentors and the manager Asynchronous usage Scalable from the individual to enterprise-level teams (world-scale) Constraints of Onboarding Since we are designing a new solution, I am not going to set any formal constraints on the language, hardware, database structure or framework being used. In theory, you could use any frontend framework you want with the appropriate justifications. You could use a relational or non-relational database depending on the middleware to serve data to the client. Since this is merely an exercise, I will say there is one primary concern that needs to be reflected in the requirement: New engineers can feel overwhelmed by choice. Consider learning JavaScript and React: a Google search turns up thousands of hits, YouTube videos, blogs, paid courses, Quora and Stack Overflow… without direction, an engineer can’t know what resources are relevant to their particular need. With siloed proprietary information, such as internal APIs and frameworks, there are too many with different levels of documentation - and none of those documents is anything more than an API reference. Engineers need a structured path to onboard, become productive, and continue learning and growing in their careers. They can't understand all at once and are looking for a streamlined curriculum that will help them get started as soon as possible. What This Onboarding Plan Looks Like Engineering Enablement for Onboarding Engineers Here's where engineering enablement comes in. While most frame engineering enablement as a , I maintain that engineering enablement has to start with engineers. discipline of tool or process implementation Engineers start with onboarding, so we have to start by creating a well-defined and thought-out onboarding experience. Once ready for production, we must continue to help engineers upskill and grow in their careers. With that in mind, let’s look at a typical engineering enablement for onboarding engineers. First of all, split the onboarding plan into weeks. This way, it's easier to understand what's expected of the engineer in the first few weeks. Focus on the following areas: Train them on the core skills they need, e.g., JavaScript, Python, React, Django, etc. Provide them with the hands-on course content, and they can quickly get up to speed on that. Connect them with the team members to build rapport and learn who are the "go-to" people for what part of the codebase, etc. Provide them a structured way to onboard into your internal APIs and frameworks. Give them clear instructions on how to set up their developer environment, test their code locally, and test their code on staging, production, etc. At each step, they should be able to raise their hand if they are stuck, and the mentor/manager can unblock them quickly. As they are nearing completion of their onboarding to become productive, provide them with the documentation to continue learning and growing in the team. Effective developer onboarding thus becomes integrated with an ongoing engineering enablement effort. Continuous, personalized onboarding is the key to unlocking engineering enablement not at the process-level, but at the person-level. As we stand up new tools and processes, we are also constantly standing up new hires. The knowledge necessary to use these tools effectively starting on day one, and a safe environment in which to explore and apply the lessons learned, is essential for ongoing success. Migrations between tools, technological frameworks, and processes happen all the time. People are constant. Quality engineering enablement has to focus on empowering people. With people up to speed, the product development cycle can accelerate, and team performance can scale. Final Thoughts on Onboarding Engineers Every leader wants to reduce cost, improve time-to-market, and maximize product quality. This project management triangle is the chief concern for engineering managers, too, where getting product value out of world-class engineers, accelerating team productivity, and delivering quality code correspond to those chief activities. It would help, then, for engineering managers and business leaders to directly address onboarding. Developers have unique needs with regard to the onboarding experience, so why would we give them an undifferentiated onboarding tool? The software engineering career path is a branched tree; why would every engineer get the same resources? The key to avoiding technical debt in your engineering organization starts with onboarding and continues with upskilling, turning developer retention into a holistic, experiential approach. A complete enablement platform that focuses on enabling , not the process, can empower engineering managers to avoid tales of onboarding regret and develop long-term, sustainable success. engineers

Too Long; Didn't Read

Making security fun one episode at a time

True Engineering Enablement Starts with Onboarding

Too Long; Didn't Read

Fahim ul Haq

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

True Engineering Enablement Starts with Onboarding

Too Long; Didn't Read

Fahim ul Haq

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES