James has been at Monzo since the beginning as one of the original team members and is presently working on partnerships, lending, and all the wonderful product-y things! His favorite thing about working here is “The people, and getting to see people using the thing you made :)”
Fun fact - James is the only staff member to have not only an internal company Slack channel named after him (called #weirdthingsjameslikes) but also a meeting room in our current office named after him too (called The James Nicholson Experience)
As before…post your questions, and click the Like button on any questions you like from others!! James will be here on Thursday to answer your questions
A little in depth but… Could you talk a bit about the way requirements and traceability are managed and maintained for software product stuff at Monzo.
How formally and ridigly are the needs defined?
How closely is the team held to them?
How carefully are they checked against the end result? (i.e. does software get thrown back not for bugs but for non-compliance with the look/feel/function in the brief?)
At one extreme an engineer can be free to do whatever they like while at the other they need to produce exactly what is written down for them or they have to rework it. Where does Monzo sit on this spectrum?
(I come from a heavily regulated airborne navigation software background so I may not speak the right language for either banking or app dvelopment…)
Hi James. Without using any words - how many users do you think Monzo will have on 21/12/2027? Also how many of them do you think will also be called James Nicholson?Thanks in advance!
There’s something unbelievably satisfying about seeing someone using a product and thinking “I made that!”
I think Monzo is that super rare combination of a product-centric company, solving a real problem, with the potential to hugely impact people’s lives for the better, and on a global scale. It gives me huge satisfaction to be part of it.
I think @ChrisBeldam’s question ties in really nicely so I’ll answer it here too:
I was lucky enough to get my start programming for iOS in 2008, when the iPhone was a year old and Steve Jobs had just changed tack from “web apps are great, that’s why we don’t support native” to “lol just kidding, here’s the App Store”.
Before that I’d mostly been writing backend Java services, so switching to Objective-C 2.0 was a bit of a shock – Smalltalk-like message passing and, on iOS, manual memory management via reference counting. Thankfully we now have Swift, ARC, and far fewer opportunities for me to shoot myself in the foot
Since then I’ve done a little Android and some backend Go services, but I’ve always come back to iOS. For me it’s just the right mix of programming challenge and creativity – I thoroughly enjoy creating beautiful user experience. At Monzo I have the luxury of working with an incredible design team and that dynamic is really great.
I thought I was 6’3", but the People team recently got everyone private healthcare and when I had my checkup it turns out I’m actually 6’3" and a half. I’m pretty stoked about it
Fun fact: I am not even the tallest James at Monzo.
Weird things have included: orchestras in carparks, paint parties, being on the BBC dressed as an astronaut, meals where everything tastes of chocolate, opera festivals, staying in castles, an all-female a cappella version of Creep by Radiohead, immersive theatre, large numbers of disco balls, clubbing sober in the daytime, live Disney bands, folk music around campfires, and pushing buttons to receive champagne.
This is quite a big question so I hope I can do it justice! As you say, we have to balance speed of shipping with quality control (we’re looking after people’s money, after all!)
I’ll talk a bit about the process from the app perspective. Features usually begin life as prototypes, with Product Managers working with the Design team and with @SamanthaD to test out ideas directly with customers in user research sessions.
From there, PMs and Engineers work with Design to figure out how we’ll implement the feature. This often takes the form of RFCs, setting out our thinking as to how a feature will look, and roughly what work needs to happen within the app and what backend services need to be written to support it.
For new features, we generally try to pare the feature down as much as possible for a first release: the only way to truly understand if you’re building the right thing is to ship something as fast as possible and iterate! We have an amazing community who aren’t shy about helping us refine features quickly
All code written on any platform goes through code review (via pull request) and all iOS PRs go through a large set of automated tests. All new features obviously include new tests. Rather than re-hash what’s been written before, I’ll link to this excellent write-up by @andys.
After code is merged and we’re ready for a release, apps go through a manual testing process. After that, we release to a small group of beta testers. If all of these steps pass muster, we submit it to the App Store for review by Apple.
We aim to ship every two weeks (in future we’re hoping we can make this weekly). Keeping releases regular means any bugs that do slip through are found and fixed quickly
Hopefully the links above answer your question too!
James,
