I recently mentored a graduate engineer (Chiat Kit Yeo) as part of Xero’s Technical Graduate Program.

Although I was nervous about taking on the immense responsibility of nurturing someone early in their career, it turned out to be one of the most rewarding and fulfilling experiences of my software engineering career.

I wanted to reflect and share insights on it in this post – potentially persuade other engineers who might be on the fence about taking on a mentorship/coaching role while I’m at it!

Bonus: I’ve also reached out to Kit’s to include his perspective and experience – this should also give interested graduates and early-career engineers an inside look into a program like this and how to make the best out of it. 🚀

Xero’s Technical Graduate Program

Firstly, what is Xero’s Technical Graduate Program?

It’s a twelve-month long learning program, where technical graduates at Xero complete three four-month long rotations at different teams within the company.

Each rotation has unique learning outcomes and objectives, ensuring when you’re done with the program, you have:

Met and worked with a variety of people from cross-functional teams
Understood how the business operates at a high-level
Worked on a range of products with varying types of work – front-end, back-end, data reliability, security, infrastructure, etc.
Built your fundamental technical and non-technical skills as a software engineer

Here’s a quick breakdown of the learning outcomes of each rotation:

Rotation 1: Learning to work in a team

Rotation 2: Learning what it means to be a contributor

Rotation 3: Finding strengths and looking forward

Most importantly, graduates are assigned a “Buddy” – an experienced engineer to coach and mentor them in their assigned team for each rotation, supporting their technical learning and development.

This is where I came in.

What I Did

I was Kit’s Buddy on his second rotation, helping him achieve his learning outcome – Learning what it means to be a contributor

Kit had completed his first rotation, so he had already learnt the necessary skills to work effectively in a team. It was now time for me to support Kit, and supercharge his learning, helping him become an excellent contributor in any team he choose to join in the future.

In short, I was Yoda and Kit was Luke.

We began our journey with some good old-fashioned goal setting.

Set Goals

Dreams without goals are just dreams
— Denzel Washington

Goals are cliché, but there’s a reason for that – because they work.

But it’s the reason why they work I find fascinating – it’s not the goal itself and whether it was achieved or not that matters. It’s the process of coming up with and committing to the goal that does.

Goals create intention. Goals give direction. Goals create clarity.

Goals make you akin to an arrow shot by a skilled archer, unswerving in the gusts of distraction, travelling only towards its destination.

The designers of the graduate program at Xero understood this well. Before starting a rotation, graduates are required to:

Decide on goals they’d be working on for the rotation
The goals’ timeline
Why the goals matter to them

After an initial session with his manager and I, Kit came up with a great set of goals for his rotation, all focused on meeting the overarching goal of learning what it means to be a contributor, ranging from things like:

Having one-on-ones with everyone in the team
Getting his development environment setup
Shadowing a release
Running a release
Running team ceremonies
Submitting his first PR

Now that we had established a clear set of goals, it was time to set up a way to track progress towards them.

Establish Communication Channels

A key part of mentoring is ensuring there are clear and open lines of communication between the mentee and mentor, allowing for seamless flow of feedback, support and collaboration.

This becomes all the more important with remote work – not being right next to each other in an office only multiplies the hesitation to ask questions.

Having been a grad myself in the past, I knew all too well about this problem. So I ensured we set clear expectations on how we’d communicate upfront at different levels.

Between Kit and I

The first meeting I wanted to setup was a regular, 30 min one-on-one between Kit and I. During our first meet and greet together, Kit let me know that a weekly cadence would work well for him, so that’s exactly what we did!

The main topics we covered during these one-on-ones:

How Kit was feeling
What went well during the week
What did not go well during the week
Any kind of support Kit would like from me
Any feedback Kit had for me or vice versa
Just hang out and have a good time together sometimes!

Although minimal, these meetings allowed us to personally connect, build rapport, give and receive feedback at a comfortable cadence.

Between Kit and the rest of the team

Apart from myself, I was keen for Kit to meet the rest of the team and become a part of it. The best way to do this would be setting up short, informal one-on-ones with members of the team.

Kit was very proactive in setting up one-on-ones with the rest of the team during the first couple of weeks of the rotation, so I didn’t have to do much here!

These meetings helped him meet everyone and understand the work they did, and hit the ground running when it came to collaborating in future tasks he’d pick up.

Between Kit, Kit’s Supervisor and I

We also had to ensure that Kit’s supervisor (PJ Waga) was across the work that he was working on. So we also setup a fortnightly, 30 min meeting between the three of us.

What we covered during these sessions:

What Kit worked on during the week
Areas of improvement for Kit
How Kit was progressing towards his goals
Any feedback Kit had for us or vice versa

This meeting helped build alignment between the work Kit was doing in our team and the goals of the graduate program.

Targeted Induction Sessions

Before letting Kit get his hands dirty on our codebase, it was also crucial to get him well versed with:

How our part of the product works and the features it offers
How our product works under the hood
Which tools we use and how to access and use them
What our development processes and ways of working are
How our testing and deployment process works

Because despite contrary belief, writing code is actually a very small part of a software engineer’s day!

So we setup several hour-long sessions over the couple of weeks to cover these topics. While I ran most of these sessions, I also decided to add in folk with more domain knowledge about different subjects as and when needed.

Shadowing and Pair Programming

Now that Kit was armed with knowledge about our product and ways of working, I felt like he was finally ready to take on technical work.

Although throwing someone into the deep end is always a viable strategy (I’ve been a lucky victim of that more than once), I felt that Kit would benefit from some handholding before picking up more technical tasks independently.

The best way I’ve found to facilitate this is to run shadowing/pair-programming sessions for the majority of tasks that an engineer is expected to perform in his or her workday, ranging from:

Feature development work
Code and infrastructure deployment
Monitoring and alerting
Software testing
Maintenance
Resolving customer issues
Software design

We had several sessions targeting these tasks during the first few weeks of the rotations with myself and other members of the team.

This allowed Kit to:

Take copious notes and ask questions, capturing hidden and assumed knowledge, making him efficient when it came to him performing these tasks independently
Learning how different tools and techniques can be used together to solve business and technical problems

With all that done, Kit was finally ready to take on some real work independently!

Support Independent Contributions

While Kit did most of the work in this stage, there were some strategies that we used to ensure Kit felt well-supported on the way to become a successful contributor on our team.

Timeboxing

It can be quite challenging when you’re early in your career or new to a team to admit when you don’t know something. You’d much rather try to resolve matters all by yourself and spin your wheels, to avoid bothering other people and risk looking incompetent.

I know that feeling. I’ve made this mistake far too often in my early days.

To avoid this, we set an expectation of time around tasks – time that Kit was free to try and resolve things independently before reaching out for the team’s help. This cleared expectations on both ends, while still allowing him to build his debugging skills and develop persistence in the face of problems.

Example: For the task of building a new API endpoint, we’d set a timebox to 2 days. If Kit was blocked past this time, he could essentially “tap out” and reach out for the team’s support without hesitation. Kit was happy to finally get some support, and the team was happy to unblock planned sprint work.

Win-win – what’s not to love?

This worked surprisingly well for more complicated / less clearly defined tasks – tasks that grads could be stuck on for weeks, yet could be unblocked by a 30 min chat with a fellow team member.

Ad-hoc Pair Programming

Without being prescriptive about pair programming, we encouraged Kit to engage in ad-hoc pair programming sessions whenever he encountered challenging tasks or concepts during his tasks.

This not only provided him with immediate support and guidance but also fostered a collaborative environment in the team where knowledge and skills were shared organically.

What I Learnt

To Teach is to Learn Twice

Ever had that experience where someone asks you to explain something to them in layman’s terms – something you think you know all about, but when it comes to it, you’re stumbling on your words?

Trust me, I’m no stranger to that.

The fact is that our knowledge is often full of holes, gaps and leaks. Activities like teaching illuminate these gaps, and give you the requisite self-awareness to understand and address them.

Also, revisiting old material also shows you things you thought you knew in an entirely different light, from a freshness and innocence of a beginner eyes, which is fun in its own right!

Much like a married couple going through the pictures of their early days, you might just rediscover what made you fall in love with certain technologies in the first place.

Don’t know if it’s just me, but there’s something beautiful about that.

The Value of Documentation

Much like the fine print on a terms and conditions page, not much attention is given to documentation until a crisis comes about, when suddenly the question that arises in everyone’s mind is, “Why the hell didn’t we write this one down somewhere?“

This is especially true when you’re helping someone onboard onto your team and codebase. I can’t recall the number of times I wanted to bang my head against the wall when we encountered problems during Kit’s setup – problems I’d faced and solved during my setup with great difficulty, but forgot to put down in a document.

Your documentation doesn’t need to be as detailed a work of art like Tolstoy’s War and Peace. It can be as simple as:

A short 5-10 min post jotting down key points of knowledge
A meeting recording of an important session
A short video or screen recording of a process

Like a strenuous workout, documentation is painful in the short-term. But it saves you from significant pain in the long-term:

People get up and running faster
Decisions are made quicker and with more confidence
Async work is enabled, creating more flo w

This comes with the obvious overhead of having to maintain the documentation as the team’s processes and codebase evolves over time.

In my opinion however, the benefits of documentation far outweigh the costs.

Coaching Skills

Taking on the role of Kit’s mentor helped me realize the profound impact it had on my own growth as a coach and leader, affording me the opportunity to refine my coaching skills, develop empathy and enhance my ability to provide constructive feedback.

One of the key aspects for me was understanding the need to adapt my communication style to cater to Kit’s level of experience and knowledge – breaking down complex topics into simpler terms, being more patient when working through challenging tasks, and even overcommunicating sometimes to be understood.

Another aspect was learning to tailor my approach, adapting to different learning/working styles and preferences.

While Kit demonstrated a proclivity for independent learning and asynchronous work, others may thrive in a more interactive environment.

As a coach, it was my responsibility to discern the most effective approach and adapt accordingly, creating an environment conducive to his growth and development.

No two mentees are the same, making coaching as much as an art as it is a skill.

Fulfilment = Giving back

Success without fulfilment is the ultimate failure
— Tony Robbins

There is a certain joy in building valuable skills and attaining mastery in your expertise, but it pales in comparison to the joy of sharing your success and experiences building others up.

So, how do we go about infusing more fulfillment into our professional lives? My advice – give back.

Giving back comes in many flavours, and you don’t necessarily have to mentor someone to give back. But as a software engineer, mentoring graduate and junior engineers is IMO one of the most direct, effective and valuable paths to give back.

The joy of witnessing someone enter your team with limited knowledge and then blossom into a proficient team member, knowing that you played a pivotal role in their development, is a sentiment that transcends words.

While I’m not there yet, I’m guessing this might feel like one of the many joys of parenthood!

Now let’s hear Kit’s experience.

Bonus: Kit’s Side of the Story

Q: How was your overall experience of the rotation?

It was an overwhelmingly positive experience – I felt a sense of belonging and was well-supported and cared for in the rotation

Q: What did you learn?

I learnt how much bigger Xero’s tech ecosystem is. While my other rotations showed me the Payroll division specifically, this rotation gave me a holistic look of the organisation.
I gained a lot more confidence as a software engineer, primarily because I felt psychologically safe to fail. At the end of the day, the only consequences were a few light-hearted jabs and casual fun-poking, which gave me the breathing space to persist.

Q: What areas of improvement did you identify?

I felt that my technical ability fell shorter than I expected. I didn’t realize my CS degree wouldn’t fully prepare me for software development in a big tech company. I’m keen to improve in this area as I go forth into my career.

Q: Any parting advice for future interns/grads?

I found that was the fastest way to learn software development is by doing. Practice always trumps theory in this craft.
You don’t always need to read all the documentation before starting off a task. Take controlled risks and try whacky stuff (in a safe environment) to accelerate your learning. Default to action.

Conclusion

And with that, I have some wonderful news to share with you.

At the end of his graduate program, Kit decided to join our team as an Associate Engineer!

And it’s a real challenge for me not to take some personal pride in that fact. 😉