Modern software is complex.
Modern software 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 behaviour 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.
Onboarding processes do not help.
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 through their contribution to the code. 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. However, they are mostly ineffective.
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 Bauer1 categorizes as ’Orientation, Support tools and processes, Coaching and Support, and Training.’ Sim and Holt2 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.3 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 attempt to do.
Comprehending the product during onboarding is also complicated because modern software products behave like complex engineering systems. They consist of microservices interacting with each other to produce the desired behaviour and require significant effort to understand since the campus hires do not have prior experience or skill in comprehending complex systems.
Novices have no learning strategy.
Most of the product learning for novices comes from a series of code-related activities assigned to them during their onboarding (also corroborated by the interviews and surveys we have 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 open-ended question: What learning strategies do 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 to understand their onboarding experience better. The findings were similar: most people had no strategy for comprehending the products and also didn’t know how best to use the onboarding process for learning.
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 affect 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.
How should they articulate their understanding?
There is no good and quick way for the novice to demonstrate their understanding to others; most of the time, it is outcome-based – when an engineering task is assigned and accomplished, the outcome shows whether the understanding existed or not. This takes a long time, is risky, 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 since they do not have a quick way of demonstrating their understanding. Overall, it is hard to say if the onboarding process has succeeded in helping novice engineers comprehend the product satisfactorily.
What is the way out?
The organization and the new campus hires need to take steps to address this. The new hire needs to have skills and a learning strategy to make the best use of the resources available during the onboarding process, and they should have a way to articulate their understanding to get quick feedback.
I have been experimenting with this by intervening in the onboarding process and teaching a few skills and a learning strategy to aid product comprehension. A key skill is to do a top-down comprehension by modelling the existing system using the existing information and refining the model when new information is available. The learning strategy enables them to take more structured notes, frame relevant questions and articulate their understanding more precisely, by leveraging a system modelling notation and approach.
As part of my research, I am still collecting evidence from the field about the efficacy of this approach, but initial results seem promising. Please connect if you would want to know more.