Where I work we’ve been improving our graduate programme for software developers. Today I would like to share some of the insights we’ve gained over the last few years around how to do this better.
How do I fit into this?
My involvement in our software developers graduate programme has evolved with time. It started as me being a part time volunteer that wanted to improve the experience for a specific participant. With time it’s evolved to be a full-time role where I look after the programme across three cities with about 30 participants at any one time. In this post I would like to share some of the insights I’ve gained over the last few years around how to run a graduate programme for software developers better as well as the lessons we’ve learned on this journey.
Why do we have a graduate programme
Before I get into the meat of what we’ve done and how we have evolved the programme, I want to briefly touch on why we are doing it in the first place. There are two main drivers.
1) It’s fair to say that in my industry we have a scarcity of experienced software engineers available compared to the amount of work needed to be done.
2) It’s also fair to say that we have a major diversity problem in this experienced pool of people doing the work (I realize diversity can be measured on multiple dimensions, the most obvious one right now being gender diversity but there are others).
Our graduate programme allowed us to tackle these two areas simultaneously. We were able to tap into the vast talent pool of brilliant people wanting to enter the software engineering field that just didn’t have enough experience AND in tapping into this pool we’ve found that there is way more diversity on many different dimensions.
The net result is our graduate programme has allowed us to intentionally bring diversity in to our engineering teams which I believe will result in us making better software.
Evolution of high level programme
To start off with, I want to share how our programme has evolved.
Iteration 1 - Simple rotation
We started off with a very simple rigid structure.
- We worked on a 1 graduate per team rule.
- Every 3 months each graduate would move to a new team.
Summary of adjustments
This simple approach had low management overheard. The experience however was hit and miss.
One of the biggest challenges I saw with this approach was as a graduate your growth was largely dependent on the team you join and how experienced they are with growing someone. Our engineering teams had very little experience working with people newer in their careers and supporting them adequately.
Some teams had a complex domain that required serious up skilling. I questioned how much someone learned from the experience in just 3 months.
Iteration 2 - Simple rotation with shared intentional learning workshops
Our next adjustment was to introduce learning workshops. Once a week we would get all the graduates together an afternoon to go through a fundamental software development concept. They would then have a ‘synthetic problem’ to do on their own to help apply that concept.
Summary of adjustments
The addition of the weekly workshop helped us form a baseline for where people were at technically. One challenge we found with this approach was graduates being able to make time to do the synthetic problems during the week. Some weeks they were able to do the work, other weeks they were unable to prioritize it. Another challenge was being able to tie up what they were learning in the workshops to the actual work they were doing. Because we had a fragmented software engineering practices some teams did not value practices like TDD, or making things testable due to ignorance or lack of understanding.
Iteration 3 - Introduction of learning phase before team rotations
The next adjustment was probably the biggest. We introduced a learning phase before graduates entered team rotations. The intention with the learning phase was to give graduates foundational technical skills that they would use regardless of the team they joined.
During the learning phase graduates would work a collection of software engineering practices that we had identified as important to us as an organisation. We provided a handful of synthetic problems that the mentors could use to help their graduates learn. Mentors worked either as solo or co-mentors. We introduced the concept of “meta” mentors who were there to help new mentors figure out what mentoring meant.
At the end of the learning phase the graduates would participate in a “meaningful project” and them move into team rotations.
We also adjusted the policy for team rotations so that graduates could spend between 3 and 6 months in a team instead of a fixed 3 month rotation. This allowed one to stay longer in a team if you were still learning.
Summary of adjustments
The learning phase while useful was chaotic. Not enough guidance was given to mentors on how to develop certain skills and some of them were not experienced enough to teach these skills. There was also no bar on what “good enough” mean. Some graduates spent a fairly lengthy time in the learning phase because their mentors had higher standards of what they expected than other mentors.
The idea of meta mentors never really took off. Some meta mentors met up regularly with their groups, other meta mentors preferred to get involved directly with the graduates. I blame lack of clarity on my side around this.
The introduction of a meaningful project was hit and miss as well. By the time graduates got into the meaningful project they were eager to move into team rotations. They had inexperience around how a team should collaborate and so some projects had friction and added very little value while others appeared to have helped. It also ran counter to allowing graduates to move through the learning phase at their own speed. The meaningful project became this roadblock that everyone needed to be at the same stage to start and complete.
Some instances where we had solo mentors, they had period of having heavy delivery commitments they were not able to dedicate sufficient time to their graduates. We also had some mentors leave the organisation. For co-mentors this was not really a problem since there was redundancy built in. For solo mentors this had a huge impact on how the graduate felt about work.
Allowing varying the crew rotations created some complications on how to plan workforce planning but seemed to still be positive as graduates felt in more control of their learning journey.
Iteration 4 - Refinement of learning phase and more intentional team rotations
I decided to keep the learning phase however it was clear that more work needed.
We’ve done the following.
- Learning phase to only work with co-mentors (no more solo mentors)
- Introduce workshops to support mentors around what their role was and the psychology of teaching
- Introduce guidebooks for graduates, the general engineering organisation and mentors on how they can be effective in the programme
- Adjust meaningful project to be a cohort project midway through the learning phase
- Introduce roadmap on what the journey covered during the learning phase
- Introduce concept of quorum reviews where a group of mentors meet with a graduate at key milestones to review work
- Introduce concept of journey outcomes for each team rotation so that the purpose of why the graduate is in a team is clear
- Adjust mentoring circles to be led by myself as a tool for alignment across the programme
- Introduction of weekly health check emails for mentors and graduates to monitor how they are doing during the learning phase
Summary of adjustments
There were a number of adjustments. I’m going to just summarize the 5 that stood out to me the most.
Guidebooks - First off, producing guidebooks for all roles has been important because it has allowed us to scale the programme while still stay relatively aligned. Getting the balance of the guidebooks so that they still allow mentors the flexibility to change things and adjust based on needs but give direction is always a challenge. I believe we have the balance right but we will see. The guidebooks for the graduates were extremely important and have helped reduce a lot of the unknowns and provide further direction.
Quorum Reviews - Introducing quorum reviews has helped mentors be more aligned on what good enough is for each graduate during learning. It’s also given the graduates clearer guidelines on what we are aiming for. I believe we will continue to see quorum reviews mature as groups of people establish “what good enough is” and how to assess it.
Mentoring Circles - Moving the mentoring circles as a tool to up skill AND also stay aligned has been beneficial. Right now while things are still changing fairly quickly it makes sense for me to continue leading these. I suspect as the dust settles and we rely more on the guidebooks my participation in these can decrease or be shared with the wider engineering group. Right now I feel like a key person dependency in this, but a necessary one.
Cohort project - Moving the cohort project to midway through the learning phase has its pros and cons. The big pro is it breaks up the monotony. Some of the cons are around splitting attention between the work the mentors are guiding and the learnings from the cohort project.
Journey outcomes for team rotations - Having a clear purpose of what a graduate is going to achieve in a team rotation I believe will lead to more meaningful team experiences. It’s still early days on this one.
The high level structure of the programme is continuing to evolve. We are beginning to see where the current structure falls apart. I often question the introduction of the learning phase but still believe the benefits of it outweigh the challenges it introduces.
In the next post I’m going to share some of the learning we have gained around the learning phase and how to be an effective mentor during this phase.
