Last year, I worked for a challenger bank in London. Their engineering team leaned heavily toward Leads and Seniors and didn’t have any juniors. Surprising as it may seem, this kind of seniority distribution is standard in the London fintech startup scene.
Based on my observation, this is because:
- Many senior engineers see training juniors as a hassle
- Managers think onboarding juniors can slow down the delivery
After a shift in policy, the Bank decided to start hiring graduates. I saw this as an opportunity to do something I am passionate about: to effect change in an organisation and impact the lives of those involved. I took ownership of this and set out to create a strategy that would be beneficial to all those involved. I knew the concerns of onboarding a junior team to be inconveniencing senior devs or slow down delivery. So I tailored a training scheme in three steps precisely to avoid this.
First step: learning the fundamentals
We were a challenger bank with a cloud-native approach taking advantage of infrastructure as code, docker and event sourcing. Any person learning this will have lots of questions, so the programme’s first step would be learning the fundamentals. Learning through practice is excellent, but knowing the theory will teach someone how to think and understand why we make some decisions. I also selected a group of mentors. They would dedicate time outside of sprint work to help with any questions and explain complex subjects. It worked out very well in setting their expectations that training grads wouldn’t inconvenience them.
In a session similar to event-storming, the team created a syllabus with all the theory we thought was essential. My colleague, the great agile coach Nick Fahey did an excellent job setting up a Kanban board for a graduate to track their progress.
The mythical person-month
How long should a graduate take learning the fundamentals? One month? Why not 28 days? I believe they should have as long as they need, but humans are happier with numbers. I don’t think a graduate would be comfortable with the expectation they would have to learn something until “they got it”. So I gave it one month to set the expectation, but it would be as much as they needed.
The Questionaire
Years ago, when I was studying Computer Science at Royal Holloway, one of my professors showed me some research around the power of writing as a memorisation technique. Thinking of this, we came up with a set of questions for each item in the syllabus. It would help the graduates memorise the core concepts and entice conversation topics between them and their mentors.
Some example questions to give an idea about how it was like:
Why would a dev want to do TDD instead of straight away implementing the production code?
How does ubiquitous language relate to a bounded context?
What is the difference between a command and an event?
Second step: pair programming full time with seniors
In this step, we introduced the graduates to actual sprint work. The challenges here would be giving them the confidence to participate in agile ceremonies and teach them about a complex Banking domain.
I thought pair programming would be the perfect tool for the job. Having said this, it would be a different kind of pair programming. Usually, software engineers look at the board and then self-organise in pairs to drive tickets from end to end. This time mentors were assigned graduates for a sprint. We tried to rotate mentors when possible. I understand a board full of tickets can be pretty intimidating. I’ve seen more junior folk feeling pushed to the side and uncomfortable at times. I wanted to avoid this.
Third step: removing the training wheels
The final step marked the conclusion of their onboarding. Graduates were free to decide what tickets to pick up, self-organise in pairs, and be responsible for delivering work end to end.
Conclusion
We had many applicants and lots of open positions to fill. There was a temptation to start making lots of hires, but we had never tried our training scheme before. We decided to start small and make it work with only one graduate before scaling it up. After one year I am happy to say our scheme was very successful.