KYLE: Hey I’m Kyle 👋 I joined Monzo as a Customer Service Representative, known as a ‘COp’, back in 2019. During my time as a COp I worked as an Account Management Expert. This means I was working on customer issues before they required escalation to engineers. At university, I completed the first two years of a computer game design degree, and while working as a COp I wanted to find a way to move into engineering. I’m now working as a backend engineer.
DUNCAN: Hi, I’m Duncan 👋 I’m a senior backend engineer. I joined Monzo back in 2018, and have spent a good chunk of my time here as tech lead of Savings Squad, the engineering team that owns Savings Pots. I mentored and then managed Kyle as he moved from working as a COp to his new role as a junior backend engineer.
Kyle and I worked together to build a new statement feature. This was the key project that saw Kyle through his journey from COp to a full-time backend engineer on Savings Squad. In this blog post, Kyle and I give our own perspectives on how that career change took place.
Customers wanted Pot statements in-app
KYLE: Since the days when Monzo was a prepaid card, you’ve been able to download an account statement from the app. But at the start of 2021, there wasn’t any option in the app to download a statement for a Pot. As we grew, and Savings Pots became a bigger part of Monzo, more and more customers started to ask for Pot statements in the app.
As part of our dedicated personal development time, I (@ModdingFriendly on GitHub) started working with a fellow COp Marcus Nailor (@nexusmaniac on GitHub) to learn Go and fix this problem ourselves. Being COps meant that although we could write code for the backend we couldn’t approve or ship anything to go into production so we had to build all of our code to work in our Staging environment.
2 months later and a whole bunch of broken statements in staging we were happy with our work on the project and we put a post to the team that owns statements at Monzo and waited for the review comments to come rolling in…
Creating an opportunity
DUNCAN: Like other engineering teams at Monzo, Savings Squad has a Slack channel for pull request (PR) review requests, called #savings-pr. Most of the time, review requests pop up in there from my Savings colleagues, though sometimes there’ll be review requests from other teams for changes to systems owned by Savings. For instance, our Platform teams will sometimes make cross-cutting changes to all services, or other teams might need to make changes to support their projects.
But in early January 2021, something pretty unusual popped up in #savings-pr: an enormous PR from Kyle and Marcus to introduce Pot statements!
As Kyle said, COps could write code, but couldn’t deploy it to production so they needed an engineer to sponsor their changes. That sponsor would then have to review the code, ensure it meets our engineering standards, approve it, and deploy it to production. Unfortunately, this Pot statement PR didn’t meet our engineering standards. For instance, one key guideline is “keep it small”. We aim to keep our PRs to 300 line changes or less, and to apply the yardstick that each PR should change “one thing”. This PR added or removed around 6,000 lines of code, and the description outlined four different broad changes.
However, this PR was timely! In-app statements for Pots was bubbling near the top of our squad’s priority list. And Kyle and Marcus’ PR demonstrated their enthusiasm to tackle this problem, familiarity with our backend Statement service, and competence with Go. I decided to explore mentoring one or both of them. Perhaps with their help, we could ship this feature sooner.
Kyle and Marcus agreed to this arrangement and initially worked outside of working hours. Our first focus was on breaking this enormous PR into smaller, more testable, incremental chunks. A part of having a PR change “one thing” is that it should do one of the following, but not both:
Refactor existing logic
Change or add functionality
One of the foundational changes their initial PR made was to consolidate our personal, joint and business statement templates. We had separate template files for each, though the content was near-identical. So I proposed that we start with a PR that would replace these templates with a single template, with conditional logic for the areas where they diverged. Kyle and Marcus were keen to resolve some of the points of divergence. For example, a particular heading was bold for personal statements, but not bold for joint statements. But fixing this would be changing functionality so we agreed to defer this to a future PR, after talking to the respective teams to make sure they were ok with these differences being addressed.
So this first bite-size PR was a pure refactor. A key benefit of this is it made it more testable; we could generate a range of statements in our test environment, and make sure the output was byte-for-byte identical before and after deploying the PR to our test environment.
Kyle and Marcus had no permissions to merge PRs or deploy to production, so we had a workflow where they’d pick a ticket from our Jira board, they’d write the code, I’d review it, they’d make changes, and once it met our standards, we’d join a video call together. I’d then share my screen as I tested and deployed it with them, explaining each step as I went. My collaboration with Kyle grew to the point where in May 2021, we offered him a six-month secondment as an engineer in the Savings Squad. I became Kyle’s manager.
KYLE: Joining engineering full time was a very different change of pace from the part time I was doing in my own time. I had lots of new things to learn and more opportunities to collaborate closely with the people I was working with. Through the secondment I got to meet great engineers and learn a lot about all the inner workings of Monzo and Savings in particular.
As an engineer I would be given a series of tickets for the week and it would be up to me to manage my time and ask for help if I needed it to make sure that I was able to complete the squad goals.
DUNCAN: Kyle was learning at a fantastic pace, I was hugely impressed with his technical skills. One time we were on a call together investigating why a backlog of asynchronous messages had been building up in a queue. We were looking at the Kafka section of our Grafana service dashboard. Kyle hadn’t used this section of the dashboard before, but together with the background on Kafka I’d given him a few days before, he was able to figure out the problem. It was a bit of a moment for me!
To get Kyle to a point where I’d be comfortable recommending him for a permanent position, though, I wanted to give him some constructive feedback around documentation. I wrote up some feedback around the importance of clearly documenting PRs (which later morphed into this blog post). After giving Kyle this feedback, he took some recent PR titles and descriptions, pasted them in a document, and started thinking about how to apply the feedback. I had this document open, and watched him iteratively improve the title. It started out as “Rename template file”, and ended up as “Change extension of Go HTML templates from .html to .gohtml, for better syntax highlighting”. This was another great moment for me and part of the reason why mentoring Kyle was such a rewarding experience.
KYLE: This feedback helped to state the importance of describing the problem to your reviewer especially if your PR is crossing teams or requiring specialised context that you might not have in a year. By taking 10 minutes today writing up a detailed PR description (and choosing the correct title) you can save the reviewer that needs to look at the code hours of unpicking the reasons behind your decisions. This also gives them confidence that you understand the changes that you’re proposing and that nothing will break when you ship it.
During my secondment I got to work on a brand new project at Monzo at the same time as completing the day-to-day Savings Squad tasks: Wise Cashback. This was a super interesting project as a new joiner as being able to work with senior engineers to learn how to build a new system from the ground up helped to inform so much of my early engineering career at Monzo.
DUNCAN: Later in 2021, after helping to deliver the Wise Cashback project, and getting positive feedback from the rest of the squad, we gave Kyle an offer as a full-time backend engineer in Savings Squad. At the same time, I moved to another team, so this marked an end of me directly supervising him. Since then we’ve had a monthly 1:1 catchup, which Kyle named The Hotline…
KYLE: Since becoming a full time engineer I’ve worked on a lot of super interesting projects as part of Savings Squad to help make our savings products better for all our customers. I’ve also worked on the recent launch of Charity Donations in-app once again getting to work with a new team of people to build and launch a project from the ground up. And just last week I got promoted to a Level 2 Engineer and I’m continuing my journey learning from the teams around me.
Moves from COps to engineering don’t happen often!
DUNCAN: Kyle’s journey from COps to engineering isn’t typical, though it’s not unprecedented. Another recent avenue for this within the Borrowing team was where three COps got a sponsorship to complete the Makers’ Academy course.
One final plot twist: Marcus, who co-authored that enormous initial PR with Kyle back in January 2021, now also has a full-time position as a backend engineer at Monzo. His route was different: he went to our website, saw the open position, and submitted his application. Here’s our careers page if you want to take a look yourself!