When asked if I would be interested in tech leading the signup squad I was unsure how to answer.
I had been working in the squad as an Android engineer for 6 months and the change in tech lead coincided with a change in product manager. We were entering a period of flux which seemed to me to contain equal opportunities for both success or disaster. Perhaps an engineer fitting the more typical shape of a Monzo tech lead would be more suitable.
My view of a Monzo tech lead was a backend engineer with lots of tenure and a wealth of backend technical knowledge. You are a point of contact for those outside the team for all things related to the inner technical workings of Monzo.
As an Android engineer, my area of expertise is focussed on the customer-facing aspects of the bank. Would the team think I wasn't suitable or that I was out of my depth?
I spoke to my manager about these concerns and we agreed I’d take the role on for a trial. We wanted to see if my concerns were real or just misconceptions.
18 months in I’m pleased to tell you that my concerns were misconceptions. Here’s what I learned along the way, the tactics I employed and how I feel this has benefitted my growth and squad.
Embracing the unknown
It was very important to me to stay focussed on app development as it's what I enjoy most. This meant starting the journey to become a backend engineer, or even a hybrid of the two, was not an option. Rather than trying to emulate what I previously believed a Monzo tech lead to be, I decided to figure out how I could do the role most effectively using my skills and experience.
I felt it was important to acknowledge what I didn’t know. I wasn’t afraid to ask questions, however basic. I leant on others to help fill in where I couldn’t, for example writing backend technical proposals or fielding backend support requests. This approach had the benefit of creating room for other backend engineers to contribute and avoided the tech lead anti-pattern of dictating or being a martyr.
However, it didn’t mean that I ignored the backend and instead I focussed on the fundamentals: what services do we own? What dashboards are monitoring them? How do things work at a high level?
I then applied the same approach to help the rest of the team understand our app development and product fundamentals by:
helping make it easier to get an overview of signup screens using Figma and using client analytics and Looker dashboards to help visualise how customers flow through them
encouraging the entire squad to get involved in test parties and using debug builds
supporting squad members who wanted to set up client dev environments, empowering them to test their own changes and raise their own client PRs
understanding the app release process to see how long changes take to ship and how that might affect our technical approaches
Energising experimentation
Experimentation is a key part of the product development experience at Monzo and something I was keen to get the wider squad involved in. I worked with our data scientist to help foster a culture of experimentation within the squad where members own experiments, helping drive them forward, from hypothesis to rollout. We set up weekly experiment review sessions with the team that gave us time to share our progress and analyse the results. They also served to keep experimentation in focus and reminded us all squad members should stay involved.
With a deep knowledge of how the client apps are built, I’ve been able to help work with our product manager to take more tactical approaches in our delivery and help get features to market sooner. Things like identifying:
where we can reuse or augment existing solutions, for example updating our existing forms solution for collecting customer data rather than building a bespoke solution
opportunities to implement a subset of a feature rather than the entire thing, reducing effort needed to be shippable. If the experiment was a success we filled in the gaps.
shared responsibilities that can be implemented by the wider discipline rather than our squad, like de-prioritising UI library improvements in the squad and raising awareness at discipline level
These tactics have led to a greater shared understanding of our product, processes and customers. With that understanding followed higher levels of contribution to the wider development process: ideation, QA, data driven development, and more ownership of initiatives and experiments.
Challenges and results
This approach helped us to generate a wide range of improvements to our signup flow and test them over a series of experiments on iOS and Android in parallel. We recently published a blog post on just one of these experiments. These kinds of experiments helped us optimise parts of our signup flow, contributing to Monzo’s growth to 8 million customers.
It's not all been easy and I've had my share of challenges...
For the majority of my time as a tech lead I’ve been the sole Android engineer in the squad. This raised challenges with time management to ensure I could perform both roles effectively. I often found I was aiming at two targets; working on my own delivery and supporting the team with theirs. Task delegation became critical to managing these situations as well as learning to effectively prioritise my work and communicate those priorities with my teammates.
Would others share my thoughts that a mobile engineer was an unusual choice for a tech lead? Imposter syndrome certainly crept in at times. Though situations still arise where a certain level of backend knowledge is required, being comfortable with my knowledge boundaries and relying on the expertise of others helps me navigate these effectively.
Despite these challenges I’m no longer concerned about fitting a preset notion of a tech lead. Focusing on my strengths and unique viewpoints have made me a more authentic leader and has resulted in better outcomes than I would've achieved if I tried to fit myself in the standard backend tech lead mould.
Over the last 6 months our squad’s focus has become far more product oriented and app knowledge is key. Would a backend engineer in this squad now share the same concerns I had about becoming tech lead? Ultimately this required me to leave my comfort zone and without doing so these opportunities would never have arisen. I’ve certainly no regrets I did and I’m thoroughly enjoying the challenge of tech leading the squad.
For readers considering a tech lead role or those currently leading squads of mixed disciplines I encourage you to look at your own strengths and experiences and consider how they can uniquely impact the team. It was through this approach that I was able to maximise my effectiveness. Holding on to concerns of not fitting the type or trying to fit that mould may have cost me the very thing that helped me succeed.
If any of the above sparks an interest and you want to check out some of our roles, take a look at the open jobs below, or head to our careers page;