Evolution is one of the most crucial parts of employees' career development so that they can progress and evolve in their roles. One of the engineering manager's responsibilities is to provide support and the right resources to the employees, depending on their goals and personal objectives. But software engineering training is not only about the latest programming language or frameworks, AWS service, or technology to run containers.

At calldesk, we have a complex cloud infrastructure with many components and around 100 microservices. Joining the team as a new software engineer can be hard and it can take some time to become fully confident in this infrastructure. That's why we consider internal learning paths as important as learning a new programming language, and newcomers need to be supported in this adventure.

Step 1: Breaking down our infrastructure as components

The first step to create learning paths was to break down the whole infrastructure into components. This step was not really hard as our infrastructure is already divided into plenty of micro-services and repositories.

As an illustration, the following components exist:

• the speech-to-text component, responsible for using multiple speech-to-text engines in real-time and selecting the best possible transcript
• the text-to-speech component, responsible for creating an audio file using a specific human voice from a text
• the telephony component, responsible for communicating SIP requests and media with our providers
• the calls component, responsible for storing calls audio files and transcripts and make them available in our Studio through an API
• the turn component, responsible for gathering data at each conversation turn (wich speech-to-text provider was used, which intent was detected with which level of confidence, an utterance that was not understood) and make some data (like not understood utterances) available through an API
• ...

Step 2: Gathering components depending on the team's focus

We are 10 Software Engineers at calldesk, distributed into 2 different teams. One of the teams is focused on the Studio, which is our SaaS interface to build voice agent, while the other is responsible for the voice agents runtime, which implies more work on our cloud infrastructure and AWS services (discover our infrastructure in 5 minutes).

Each team has its own focus and responsibilities regarding the components. That's why we gathered the components related to the runtime and make it belong to the team responsible for the infrastructure. The other components, that are more related to the APIs and the front-end SaaS interface are the responsibility of the other team.

Step 3: Writing down the component's specific knowledge to have

We have decided to create 4 different levels of knowledge for each component:

• Level 1: a software engineer who implements already scoped and specified tasks with the help of the team
• Level 2: a software engineer who helps find solutions to problems and implement solutions in autonomy
• Level 3: a software engineer who can argue and take technical decisions, can lead grooming sessions to find effective solutions, and can help other team members in their own journey