I'm an Android dev working at Monzo - AMA

Monzo Chat
21

Hi Nathan!

I’m not sure if our working structure has been talked about before, but generally we’re formed of very small cross-functional teams that we call “squads”.

Most squads have a single iOS and a single Android engineer - some may have more, for example if a new engineer is being onboarded. Having such small squads means that we’re able to work on lots of things in parallel and because each squad is responsible for a given feature, the squad can decide how the feature should behave, meaning for the most part, the decisions stay in sync.

1 Like
22

I truly could not tell you the difference between Material and Material 2 :grimacing:

For us, it’s not changed a lot. Our amazing designers have been working on a really cool design system though. The intention is that there’ll be an implementation of this system on each platform, which will allow us to:

  • focus on the logic and not redoing the same UI over and over
  • keep UI more consistent throughout the app
  • make changes in one place that are reflected throughout the app (ON PURPOSE)

My favourite thing I’ve worked on has been bill splitting. It’s the first thing I worked on properly when I joined. My favourite thing I’ve produced is an animation that’s going to be forthcoming when Monzo Plus ships. Hope to work on more things like that in the future.

2 Likes
23

Can’t wait to see them both, particularly the animation!
Thanks for your hard work :slight_smile:

1 Like
24

I started Android when I started at uni in 2008. I gave up because I couldn’t get the emulator to work (I didn’t realise it actually took 5 minutes to start, and that you weren’t meant to close it between builds).

I got into Android dev when I did my year in industry (sandwich course). I worked alongside another intern who I made several apps with: “What’s the Score” and “Study Pal” for example. “What’s the Score” was really simple, it was a score keeping app, because we used to play pool a LOT. Like the final score at the end of the year was 220-225 ish (he won).

My favourite Android feature is probably accessibility services. They’re like apps with elevated permissions which are intended to help users with disabilities access content and interact with their device easier. Invariably, developers started to misuse this, and in the last few years Google has cracked down. I wrote one that clicks “Skip ad” for you on YouTube :smiley:

1 Like
25

  • Does each squad tend to complete their work on one feature before moving onto the next or is it common for a squad to work on more than one feature at the same time?

    • For example, if a feature requires a few more days spent on backend coding, would the iOS and Android engineers work on the next feature in the pipeline for those few days or would they be allowed to decide what they work on?

  • How much say do engineers get in what they work on next (outside on Monzo Time)?

  • What is the process to take something from a Monzo Time project to a fully fledged feature on both OS? Does the Monzo Time feature reach a point where a squad takes over to finish it off and ship it?

Great Q&A so far!

26

I don’t have much to add except thanks again! Feedback like this is really helpful for us.

If there’s something that’s unusable, please get in touch. If there’s something that’s usable but not ideal, that feedback is also valuable. We have a process for escalating queries regarding accessibility whenever someone raises it via the in-app chat.

I wrote about this topic a while back and I think the points raised are still legit - let me know if you have any comments/suggestions!

27

Hi again Rachel, not much to add from the last reply :sweat_smile:

I don’t think we would build a feature in-app specifically for this, but perhaps one day there’ll be a bug reporting tool (either in-app or external).

I think for now going through customer support (in-app, Twitter, or however else we support) is best.

28

I think it can be really effective but only when it’s done thoughtfully :sweat_smile:

I find motion in UI really helps me navigate and process UI elements and everything on screen easier.

This is true when it’s done well :+1:

And can we expect to see some of this in the Monzo app?

I think it will take a significant effort to do it right, and I don’t think we would want to ship something like this unless we could do it right.

1 Like
29

Good to know thanks.
I’m going to wait till my changes from last time get changed first before I send all the other ones in the chat. I can’t overwhelm you all at once.

1 Like
30

Hi Ade

We have a GitHub repo for Android designs and another for iOS designs. These repos contain directories, organised by screen/feature, and each has a Sketch file.

We don’t use Zeplin - things change reasonably quickly here so it’s more efficient to up-skill the developers into using Sketch to a rudimentary level (exporting assets, navigating, and checking properties) than for the designers to spent time exporting assets every time they change something - we can grab the things we need as and when we need them.

The designers here are great. I’ve not worked with any designer at Monzo who hasn’t been willing to set some time aside to have a quick chat about how to implement something - or how best to scale back designs based on technical constraints (my abilities :yum:, time or actual platform constraints).

What I love really is the way they work with us to come to a solution - just because we have a Sketch file doesn’t mean our interaction is finished, it’s just started.

31

We’ve got a team of testers who are split between different squads but they swarm and help each other out as necessary. We have a QA lead who started this year who has a lot of experience, and it’ll be exciting to see how testing evolves over the next 12 months.

On Android and iOS, we mostly write unit tests. On Android, we also use Espresso (a testing framework that allows us to test the app as a user might, with clicks and drags) and iOS employ the use of snapshots (automated comparison of screenshots before and after a change to verify that nothing has changed).

How much do you rely on automated testing versus QA/software testers?

Bugs are an unavoidable side-effect of writing code :grimacing: We work together with our product testers to minimise the number of regressions we introduce, and also to cement our common understanding of how the app should behave in various situations.

1 Like
32

Does each squad tend to complete their work on one feature before moving onto the next or is it common for a squad to work on more than one feature at the same time?

It’ll differ for different squads, and differ based on the scope of what they’re trying to achieve.

For example, if a feature requires a few more days spent on backend coding, would the iOS and Android engineers work on the next feature in the pipeline for those few days or would they be allowed to decide what they work on?

We try to do as much in parallel as possible in order to move as fast as possible. This means having a few upfront conversations and agreeing on an API interface. We can then work to that in the app while backend engineers work on the backend, and then meet in the middle.

There’s always something to work on though :weary: :joy:

How much say do engineers get in what they work on next (outside on Monzo Time)?

We decide as a squad what to work on. Monzo is organised in collectives, which consist of many squads. Each collective has an overarching goal (e.g. increase growth or increase revenue) and each squad will focus on a different way to achieve this goal.

We’ll discuss together what we think is feasible and valuable, that will bring us closer to our goal, and we’ll work on what makes sense from those constraints.

What is the process to take something from a Monzo Time project to a fully fledged feature on both OS? Does the Monzo Time feature reach a point where a squad takes over to finish it off and ship it?

A proposal! We’ll write a proposal to outline what we want to do and then we’ll share it. If it aligns with a particular squad’s goals, then they might take it over, or it can be done whenever there’s time between other pieces of work, I’ve seen both cases.

1 Like
33

This is really interesting. Thanks!

  • Do you know how many squads are working in each collective (ie: how many have a goal of growth, how many have a goal of revenue, how many have a different goal)?

  • How is the make up of each squad decided and is there some sort of scheduled rotation for people between squads?

  • How often, if ever, does a squad get told (or nudged) that what they’re working on doesn’t look like it will help towards their goal by management or does each squad have to submit their projects to management for approval (would you have to submit a proposal for management to approve)?

34

Do you know how many squads are working in each collective (ie: how many have a goal of growth, how many have a goal of revenue, how many have a different goal)?

It changes every quarter :slight_smile:

How is the make up of each squad decided and is there some sort of scheduled rotation for people between squads?

No idea :grimacing: There’s no scheduled rotation though.

How often, if ever, does a squad get told (or nudged) that what they’re working on doesn’t look like it will help towards their goal by management or does each squad have to submit their projects to management for approval (would you have to submit a proposal for management to approve)?

I’ve never seen or heard of this happen. In my understanding and from my perspective, squads are generally autonomous. Before releasing new features there are product approval checklists that have to be followed, because there’s lots of regulations and we have to make sure we’re in compliance :nerd_face:

2 Likes
35

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.