Introduction
Modern SaaS B2B products are large, distributed, complex systems. They operate at the scale of millions of users and have complex workflows, many personas, and a comprehensive set of configurations that control the workflows. To serve these millions of users, the products must address various architectural concerns like performance, availability, reliability, and security while keeping the product usable and always responsive.
These products are built as a set of microservices interacting with each other to produce the behavior desired by the user; in many cases, there are hundreds of such services. Many of these services are created by third parties.
These products are deployed on cloud platforms like AWS, Azure, or Google Cloud and often leverage infrastructure as code, modifying and enhancing their infrastructure at run-time. In other words, infrastructure becomes part of the product architecture.
The engineering processes for creating, deploying, and operating these products are designed for an always-available product in a malleable cloud environment. Agility is the key in all aspects of software engineering and production, and automation is the way to achieve them.
When a novice engineer joins such a company, they are expected to learn and develop a satisfactory understanding of the product before they can produce meaningful results for the company. Understanding such a product with all its complexity is not easy, and most novice engineers struggle. The onboarding process is meant to help novice engineers avoid this struggle.
Research and conventional wisdom suggest that new employees get about 90 days to prove themselves in a new job. Organization socialization, or onboarding, is a process through which new employees move from being outsiders to insiders. Onboarding processes for new engineers are very similar across the software companies: orient the engineer to company culture, assign one or more mentors, and provide a semi-structured program to train them on hard or soft skills, what Bauer categorizes as ’Orientation, Support tools and processes, Coaching and Support, and Training.’ Sim and Holt call it a ’naturalization’ process of ’software immigrants’ and point out that even experienced engineers changing into a new company struggle and require onboarding support. Rollag et al. talk about five myths, with Myth number 2 being ’A massive information dump allows newcomers to obtain what they need,’ which is what many institutionalized onboarding attempts to do.
Comprehending the product during onboarding is complicated because modern application software products are complex systems. These are SaaS (Software-as-a-Service) products that consist of microservices interacting with each other to produce the desired behavior and require significant effort to understand since the campus hires do not have prior experience of comprehending complex systems. This is more difficult for new campus hires who do not have previous experience with similar products and have not developed ways to learn them.
Novices are bound to be inefficient
Most of the product learning for novices comes from the series of code-related activities that they are assigned during their onboarding (also corroborated by the interviews and surveys we conducted). Typically, the novice reads the code after getting briefed about the task (and any associated functional information) and tries to understand what the code is doing, asking peers and mentors questions as required (based on their availability). The focus is on understanding enough to be able to complete the task. As the series of tasks get completed, understanding improves. With enough tasks completed, the novice feels confident about their understanding. The top view helps them break down the learning process into manageable chunks, and the bottom view provides the depth of understanding for these small chunks of topics.
In a survey of novices at two SaaS enterprise product companies, we asked an openended question: What are the learning strategies you usually apply when learning something new? How well are they working, and what challenges do you face as you learn about the product?
Only 20% of the novices demonstrated some strategy (50% mentioned some aspect of learning but not any strategy; others mentioned irrelevant details). We also did 60-minute interviews with novices from several SaaS enterprise product companies in India. The findings were similar: most people had no strategy.
When there is a lack of strategy, novices can end up with an incomplete understanding of the product. Worse yet, they may not be aware of these gaps in their understanding. Here are two examples:
- Coverage: Given the reliance on code-related activities for understanding, the type and sequence of tasks will have a bearing on how much understanding is achieved (and demonstrated). For example, if initial tasks are front-end focused, the novice will have minimal back-end knowledge.
- Dependency: Given the localized nature of the tasks, it is possible that the dependencies between modules are not understood well. It takes effort to discover these dependencies, and typical onboarding does not allocate enough time for such discovery and exploration.
Evidence of learning
There is no good and quick way for the novice to demonstrate their understanding to others; most of the time, it is outcome-based, which takes a longer time and is confounded by other factors (support from peers and mentors, difficulty level of task, etc). This means that gaps can stay undetected for a long time. This also means they do not benefit from others giving them feedback on their understanding level or gaps. Overall, it is hard to say if the onboarding process has succeeded in helping novice engineers comprehend the product satisfactorily.