Onboarding project
Joining a new team can be a nerve-racking experience. There are so many things to learn, so many people to know and a new culture to fit in. Over the years we've established a training process to help new team members onboard to KMS. We want them to feel welcomed and challenged at the same time. One important factor of the process is the onboarding project. When a new team member joins KMS, we assign an on-boarding project to help them: 1. get hands dirty as early as possible (Bias for Action and Dive Deep) 2. deliver something useful to customers and stakeholders (Deliver Result and Customer Obsession) 3. learn our process and culture, interact with other team members. (Earn Trust) On-boarding projects are usually limited in scope and complexity. They do NOT have hard deadlines. The priority of these projects is to help new members learn about KMS and our software development process. Good on-boarding projects: 1. require less than 3 months to complete 2. have small scope, usually touch a single component 3. have very little ambiguity in requirements 4. have limited design and implementation complexity 5. require limited cross-team/org interactions 6. prioritize fast feedback loop and iterative, incremental deliveries. We have a mentor assigned to each new team member. The responsibility of the mentor are: 1. be a guide, help the new member navigate through the whole life cycle of the project. 2. show kindness, pass on the torch about our best practices, culture and our spirit. 3. make major design decisions. New members are not ready to make independent design decisions yet. It is the mentor's responsibility to keep the project on track. Every new team member is different. Each one has unique background, personality and aspiration. We pay careful attention to new members' onboarding progress. We tailor the scope and expectation of the their onboarding projects accordingly. Several new members not only completed their onboarding projects, but also became component owners because their projects turned out to be really useful, we continued to invest on them. For example, one engineer's onboarding project was to develop a map-reduce style workflow using AWS Simple Workflow (SWF) to address the scalability of an asynchronous worker. It was so useful that he evolved that project into a reusable partitioned workflow framework that can scale asynchronous workers horizontally. He quickly became the go-to people in KMS to solve workflow scalability problems. But I also had onboarding projects that took more than a year to complete, both the mentor and the new team member became frustrated because of the scope creep. The moral of the story: if you want to optimize new team members' learning experience, give them well-scoped onboarding projects.
Last updated
Was this helpful?