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
After level 3, the last level is "Owner". It means that the software engineer is now in charge of taking technical decisions, driving grooming sessions with the team, keep track of the technical debt backlog, cloud costs, bugs backlog, production handbook (which references what to do in case of failure in production)... Anyone who would like to become the owner of a component has to first reach level 3.
Once these levels of knowledge were defined, we wrote down specific knowledge to have for each component, depending on the level. This is a really good exercise to do as a mentor, it gives you a clear view of what you are going to expect from the software engineers in your team.
As an illustration, here is a quick overview of specific knowledge to have for level 3 on the speech-to-text component:
- Know how to check usage for each provider
- Have a global idea of running costs
- Quota and keys management
- Know how the initialization phase is working
- Know how the VAD interacts with the STT
- Know how the normalization of utterances on the STT component side works
- Know the role of different emitter classes (StreamProvider, ArrayEventEmitterMerger, BufferedEventEmitter, StopableEventEmitter...)
- Know how the stop stream strategy works
- ...
Here is an example of the final result of this spreadsheet:
Step 4: Creating quizzes to allow software engineers to assess their knowledge in autonomy
We took inspiration from how AWS assesses the level of the candidates taking a certification. They basically provide a multiple choices quiz to verify that the candidate has the minimum level of knowledge required to get the certificate.
We thought it could be a good idea to let the team assess their knowledge, so once we got this list of specific knowledge to have, we were able to create quizzes using Eduflow. These quizzes were made of 10-20 questions per level and per component.
One of the hardest parts as an "instructor" is to create not ambiguous questions, with fake answers that make sense but are not a trap neither.
If a software engineer doesn't pass a quiz, he is able to ask for support. His mentor will point him out to the right documentation, video, or any other resource so that he can understand what he missed during the quiz.
What's next?
These learning paths are a good way to provide clear objectives to our software engineers about how to get more knowledge and responsibilities in the team. They told us it helped them to set up goals like "I want to to become level 3 on these components because they are very important in our infrastructure, and it will help me become more confident". As a mentor, you should really think of how you can empower your team and give them the resources to progress in their career.
