We believe to have a successful graduate program you need the following:
- Long term outlook
Long term outlook
The goal of the graduate program is not to get the get “cheap” labour. The goal is to invest in growing someone to become a great employee.
While we believe that graduates can and should produce valuable work, we see the graduate program as a platform for creating the people we want to work with - we are optimizing for learning and growth.
It begins with a mentor
The foundation to a successful graduate program is effective mentorship. All other structures are there to support the mentor/mentee relationship and enhance it.
What type of mentorship are we referring to?
We are referring to the type of mentorship where an experienced software developer takes an inexperienced software developer (graduate) under their wing in order to teach them the skills necessary to become a professional. The focus is on experiential learning, the process of learning through doing and reflecting on what has been done.
Identifying mentors in your organization
We believe there are two main areas to keep in mind when trying to identify good mentors in your organization, the mentor and the team the mentor is in.
Attributes of the mentor
Mentors should be people you want more of, they should be the best of the best.
- Who would you like to clone?
- Who is always willing to help other people out?
- Who has their own good skills and disciplines?
The willingines of someone to be a mentor is important, but not the only qualifying requirement. Mentors should be endorsed by the leadership of the organization. Remember, the graduate is largely going to learn and mimic the behaviors of the mentors.
Mentors should also be able to dedicate sufficient time to a graduate, which would mean several hours a week of dedicated time.
Attributes of the mentors team
The mentors team should be in a place where it can provide a supporting environment for mentorship.
- What is the current size of the mentors team (we don’t want teams to be too big)
- Do team members work together, or alone (prefer teams that work together)
- Is the mentors team in a good position to support the mentor
Skills of a mentor
Mentors mentoring graduates who want to become “developers” should be “developers” themselves. Likewise, if a graduate in the program to become an analysis, their mentor should be currently practicing in that area. It would not make sense for a graduate to be doing ‘coding’ work and have a mentor that is not currently coding and is not equiped to pass down the learnings past a superficial level.
Identifying candidates to take on as graduates
Good graduates should show the following attributes:
- Smart, we want people with natural intelligence
- A doer, can the person get things done
- A self-motivated learner, there is no spoon-feeding in learning
- Humble, there should be no ego
- Committed, they should be the type to push through the resistance of tough problems
- A hacker, they should already tried to write some software, software should be their thing
- Be someone you want to work with
When evaluating potential candidates for the graduate program, you should look at the trajectory of the candidate rather than measuring them on their current state. For instance, rather than examining the current state of a candidates code, give them an opportunity to present their current state, measure and provide feedback for improvement, give them some time to learn and apply what they have learnt and then gauge the rate of improvement.
How does a graduate get a mentor and a team?
Because mentors will be investing several hours a week in their graduates (this could range from anywhere between 3 to 5 hours a week of one on one time, and many more hours of team interaction) the mentor and the mentors team has the final choice in choosing a graduate to take on.
Providing mentors, their teams and potential graduates as much time as possible to interact and to get to know each other before formalizing a graduate/mentor relationship is important. Opportunities to interact with potential candidates before an actual selection occurs could include:
- Working with candidates at hackathons
- Pairing with candidates at Code Retreats
- Interacting with candidates while they are “interns”
- Interacting with candidates on graduate recruitment activities
Once a mentor and their team has selected a graduate, the graduate joins the mentors team.
We think the ratio of candidates to actual graduates will be high, so it is fine to do some upstream filtering prior to a mentor meeting potential graduates, however we do not believe a graduate should be selected and allocated to a mentor by someone in HR or by a manager. No mentor should be forced to take on a graduate they have concerns about.
How many graduates should be in a team
There is no one size fits all rule when getting the balance between graduates and more experienced developers in a team. That said, because a graduate will place a load on a team, we would recommend that a team have only one graduate at a time. In the exceptional circumstance where a team feels it has enough depth to support multiple graduates, the rule that a mentor should only have one graduate at a time applies.
What interactions does a mentor have with their graduate
- At least one 1-on-1 a week
- Pair programming with the graduate on learning material from the jedi academy
- Interactions when doing team work (pairing and mobbing)
- Discussions around reading & blog posts
The curriculum (aka what does a graduate work on)
The graduate learns by doing, the work that graduates does should focus on what the graduate needs to learn.
There are three areas of things that a graduate works on:
- self-studying & building things to learn
- group projects with other graduates & interns
- working in a production team
Self-studying / building breakable toys
- Graduates will also have work to do for the Jedi academy, they should take time each day to work on their academy work during off peak team times.
The MYOB software craftmanship academy is a supporting program to increase a graduates knowledge in being a professional software developer. The academy meets every two weeks to focus on a core areas of software development. Each session is facilitated by an expert who’s aim is to provide attendees hands on exposure to certain essential software craftmanship practices. Sessions can be up to 4 hours, with pre and post session work.
Some of the fortnightly topics include Crafting Code, TDD, Refactoring, Design principles, Object Oriented Design Patterns, etc. For a more complete breakdown of topics covered view the following post on content for the Jedi academy
Working in a production team
- Graduates should not be treated like 2nd class citizens and given the ‘dirty’ jobs to do when working in a production team.
- Graduates will typically pair/mob on high value items with their mentor and the rest of their mentors team.
- Graduates will participate in all the team activities (stand up, retro’s, etc)
How long does a graduate stay with their mentor / team
We believe that a healthy period of time that a graduate should stay with a mentor is about 6 months although we believe this should be handled on a case by case basis and that for some it may be appropriate to make longer or shorter (from 4 to 9 months).
Part of a graduate becoming a professional is having an opportunity to work in different teams. When it becomes appropriate for a graduate to change mentors (and teams), the same care and consideration should be put into a new mentor selecting/exchanging graduates.
To provide useful interactions for future mentor/graduate selections, graduates should have day “exchanges” where they spend time with other teams and potential mentors. We believe this should only be done nearing the end of the first 6 months. During these exchanges they should be primarily pairing with people in the team. They should not be left to do work on their own. Teams that have had graduates for an exchange should give feedback on whether they believe the graduate would be a good fit for the team.
A graduate is supervised by a mentor.
Because a graduate will be in a team (the mentors team), the graduate will have the normal interactions that any other team member would have with the teams leadership (At MYOB these interactions would typically happen on a weekly cadence in one-on-ones).
We see a need for graduates to get together and share experiences as a larger group of peers, this will be done at a fortnightly cadence. We see this as a platform for graduates to support each other and share experiences.
Finally, there will be someone allocated to oversee the graduate program in a locality. They will meet in person with graduates and mentors at a four-week cadence. They are also the alternative point of contact should there be an issue between graduate and mentor.
Good mentors are grown, not found. Equiping new mentors with the skills to be effective is crucial to the success of the program.
We see the need to invest time in producing content for new mentors to get started. MYOB already has a program for helping people to give good feedback. In addition, for first time mentors it may be appropriate to have a co-mentor model, where an experienced mentor works with an inexperienced mentor to grow them.
From Graduate to Software Professional
Assemble a team of 8 or so people for a review board. A graduate is given a mixture of experiences/projects to complete within a short time frame. These should necessitate new learning, demonstrate acquired skills.
There will be a review day when a presentation and “defense of challenges” is done. The review board makes a decision
Yes - move from graduate to developer No - part ways / extend graduate mentoring