How do we onboard new hires in mobile team
At Fandom, we believe that a well-structured onboarding is a crucial part of successfully hiring new talent no matter if you have a distributed team, work from the office, or in a hybrid solution. The onboarding process should be well known and understood by new hires, the team, and other people from your organization.
The Mobile Apps team breaks down the process into ten days. Each day is devoted to a theme and during the day a new hire will meet with one person on the team for approximately 60 minutes to go through the content together.
Day 1 — Intro
On the first day, the new member is likely to be already busy with other onboarding meetings, e.g. with the IT, finance, and HR teams. To not overwhelm them, we start with an intro day. During this day we set up Google Calendar meetings, add them to Slack channels (to not miss those funny memes ;)) and also set up GitHub accounts. During the day, the Engineering Manager will hop on a quick call and explain the purpose of the meetings and channels.
Day 2 — Business Day and App walkthrough
The next day the person meets with the Product Manager to get knowledge about the business model and the strategy of the team. This covers also the company and team goals, challenges, and roadmap. We walk through the brief history, as well as the direction of the Mobile Team at Fandom. We talk about the fans’ influence on our products and how we communicate with them to better understand their needs.
On this day we also schedule a meeting with a team member to walk through the application. We present what features are implemented in the app and what we’re currently working on. This gives the person more knowledge of the product and future roadmap
Day 3 — Intro to codebase and code quality
On the third day, we meet for an introduction to the codebase. The session is led by a developer from the team to help set up the development environment. Although there is documentation on how to set up the project and setup scripts that automate the process, there is always room for improvement as some of the scripts may need to be updated. This session should end with confidence that the person knows how to build and run the app either on the simulator or device. During the meeting, we present tools we use on a daily basis and explain why we need them. After the meeting, the new hire should also know what the architecture pattern used in the project is and how to contribute. We usually leave room for questions and if something is not clear we have a confluence page with common “How To” questions.
Throughout the day the person also has another meeting about code quality. During the meeting, we explain how we write unit and functional tests. We demonstrate the mechanism for mocking data and other code conventions. The new hire also learns how we measure code quality and what quality expectations we have. Last but not least, they also familiarise themselves with the tools we use to track crashes and errors.
Day 4 — Team process
The fourth day starts with a team process overview. As we’re working in a Scrum team, the new team member should get familiar with the whole process. We present what kind of meeting the person is expected to attend and what the purpose of each meeting is. We typically involve developers specializing in the other platform (Android or iOS) than the new hire into running this session to create opportunities for cross-platform collaboration at the very beginning. This is crucial since, in our team, Android and iOS engineers work together in sprints. By the end of the meeting, we will have also presented how we carry out sprint and quarterly planning. This also sheds some light on how we communicate across teams as well as how we track progress on tasks.
Day 5 — Testing process, tools & CI/CD
It’s all about testing! The new member meets with our Quality Engineers for two meetings. We present the process of distributing builds in the test environment as well as the process of releasing the app to the store. The QA team presents what our Continuous Integration and Development process looks like and what infrastructure we use on a daily basis. Besides the engineering part, there is also a chance to get familiar with the quality assurance process. The person is informed about regression testing, prioritizing bugs and tasks as well as our Definition of Ready and Definition of Done.
Day 6 & 7 — Backend and core components
On days 6 and 7 meetings are focused on the backend and our core engine which powers the rules logic of D&D Beyond character sheets. The person learns about services used at Fandom. We also give guidance on contributing to other team’s repositories as well as our own part of the mobile engine.
Day 8 & 9 — High level of tech and engineering, Engineering Levels and Performance Management
During this day, the Engineering Manager presents the structure of the whole tech and engineering organization, and how the mobile team fits into this. The person should know what teams we usually communicate with or depend on and how we can reach them.
The next day, the Engineering Manager presents the career paths and what are the expectations for each engineering level. This gives the opportunity to learn what a person needs to do to get to the next level and how their performance will be assessed.
Day 10 — Design
During the last onboarding day, the person meets with our design team member. The new hire gets familiar with the tools we use to create layout designs for our applications. They are also onboarded to the process of designing new features, i.e. how we identify the problem, brainstorm solutions, and test the designs.
When designing the onboarding process, we’ve identified a number of principles that we believe enrich the process. Let’s have a look at them:
Start by documenting the whole process
We’ve created a Confluence page where we divide the onboarding process into a 10-day process. You can use any documentation tool e.g. Confluence, Google Documents, or your own system. Each new member of the team is able to check the whole process at every stage and can get back to it when they need this.
Engage the whole team in the onboarding process
Each team member meets the new hire at least once during onboarding for a maximum 1-hour meeting and walks them through topics listed in onboarding. This is a good opportunity to meet the whole team and get to know each other. It also gives the chance to members of your team to improve their onboarding and mentorship skills.
Give feedback to a new member
Onboarding is not only about knowledge sharing but also about giving feedback. By the end of the first 30 days, the new member receives feedback from the manager and also from the person assigned to help them. This is crucial for new members because they get to know what they are doing well and what others expect from them. After receiving feedback there is a good opportunity to discuss it with the manager. We also set a feedback checkpoint after the 2nd and 3rd months. The last one is also an evaluation if we need some adjustment to our working process.
Learn from new hires
Each new team member gives us feedback about the onboarding process so we can also improve it. We have already made a couple of changes to the process. For example, based on feedback, we’ve pushed Business Day back a couple of days to give more context about the business needs and better frame the expectations of new joiners.
Use this for offboarding
While we have a well-documented onboarding process, it is crucial to also have an offboarding document as it is natural for people to change their career paths at some point. In this case, some parts of the onboarding process may be reused. For example, we use the page where we document the services after offboarding to make sure that we properly update access privileges.
Assign a code-buddy
We think that it’s good to have a person you can always ask anything. After all, there is no such thing as a wrong question. This person will reach out to the new hire every now and then to check if they’re doing fine and ask if there is anything to help with. Moreover, if a need arises to schedule a meeting to explain something or do pair programming this will be a good person to meet with.
Assign a task to a person for their first week
The best learning is by working on a feature. We think that it’s a good idea to start with a simpler task and, while we onboard the person, they will be more confident to contribute and go through the whole process of software development if they have an opportunity to touch parts of the code early on.
Iterate
We think that we learn through onboarding also. We update the links and documentation if something is unclear, unknown, or outdated. We keep in mind that the tools or services we use are changing constantly, so we need to update them as well on a regular basis.
Conclusions
We have found that up-to-date and detailed documentation is instrumental in guiding a new team member as well as the rest of the team through the onboarding process. This helps new hires to get enough knowledge so they can start working on their own as soon as possible. If something is unclear or unknown they can get back to those materials if they want. I also encourage you to try documenting your process of onboarding so that the whole team can benefit from it.
If you have your own experience of the onboarding process or you are responsible for it in your team, and found something useful let me know in the comments. If you have any thoughts or questions, don’t hesitate to reach out to me at amichna@fandom.com, I would be happy to answer.
Originally published at https://dev.fandom.com.
