Interview with our Lead Android Engineer — Lucia Payo (Part 1)
A few weeks back, I spent time with Lucia Payo (LP), our Lead Android Engineer. We spoke on so many interesting topics that I’ll split this across two articles. In Part 1 (this article), we’ll learn more about Lucia’s background, her journey at N26 and the android team. In Part 2 (the next article), we’ll focus more on her tech leadership journey.
PK: Hi Lucia! Thanks for taking the time to chat to me. Why don’t you tell me about your background and what you’ve been up to since joining N26.
LP: Before N26, I was an Android Engineer in a consultancy. Consulting gave me many insights in different companies. I learned different ways of working and different ways of approaching problems. Not only at a technical level. I worked with talented people, speeding up my technical and softer skills growth. I learned how to communicate well with clients on deadlines. Or how to arrive at a solution together. Consulting was a lot about adapting and learning. I had the chance to change projects once every eight months. At one point, I decided to commit to a product I believed in, and where there was room to have impact and influence. In 2016 I came across N26. It looked very good but was also very challenging.
Back then, the whole android team was leaving. When I joined, the new android team members had zero overlap with the old team. We inherited a codebase without any guidance. We joined an organisation that was moving very rapidly. It was like jumping into the deep end of a pool.
PK: Tell us more about what happened when you joined.
LP: When I joined, I wasn’t the Lead Android Engineer. I was a Senior Android Engineer. It was also very clear, to me, that the team needed leadership. We didn’t have strong Android leadership at the time. We had a Head of Mobile taking care of both platforms (iOS and Android) but he had a background in iOS. We sat down as a team and started with small baby steps, defining our team culture. We needed to agree on what culture we wanted and what practices we, as a team, wanted to use.
PK: Can you give a concrete example?
LP: One of the very first instances I remember was agreeing on a style guideline. One that we would all share and use in our IDEs. When I joined, we had just received our banking licence. We proved to customers and investors that this was going to last. At this point, we wanted practices that scaled. We wanted to work towards a codebase we knew would be around for many many years.
PK: That’s a great act of leadership. Trying to shape and have an impact across the whole team.
LP: I wasn’t the only person thinking this either. The whole team recognised the paradigm shift, moving into scale up mode. We needed to take over a foundation designed to find a market fit, but not designed to scale.
PK: What was the biggest challenge?
LP: Our biggest challenge is that we had to do a lot of these transformations without much context. We didn’t have the previous team around to guide us or to give insights into certain decisions. That was a huge challenge.
We started with some fundamentals. We established team rules or guidelines that everyone started following. We put together a shared architectural vision. We agreed on how we would approach unit testing as a team. The biggest technical challenge was not building something that scales. It is building something that scales without breaking what we already built.
It’s like changing the heart of a person while they’re running a marathon. It needs to keep pumping, or you know they won’t make it to the end line. At the same time, you know it needs an upgrade.
PK: I love that analogy! So true about critical software. Fast forward to now. The Android Team is a very different team. You have more than 20 members across a few locations. You didn’t have much context, so what is one aspect about the team you’re proud of?
LP: I think we grew a very good culture in the team. This has a lot of benefits. In the beginning, you can’t imagine the impact it has. It’s huge! With our technical achievements, I am proud that we are very consistent in how we write features. The first thing we did was defining our architecture.
PK: This is the reactive clean architecture you described in this talk right?
LP: Yes. At the time, it was a bet. You know, the team didn’t know the project very well. Yet we felt it was the best approach we had. Team members started rolling this out in their features. There were bumps in the road. But we learn. We are now on version three of this architecture. We had to evolve it. It was a solid approach. It gave everyone a sense of how to write a feature. The architecture provided enough structure for developers to understand or evolve other features. Our architecture encourages good practices like modularisation and better testability. It’s been a couple of years since we introduced it. Now almost 70% of our features follow it, which has been a challenge since it’s a large codebase.
PK: How did the team size affect help or hinder adopting this?
LP: You might think that having a larger team slows us down. It’s been great to have a larger team because we’ve been able to move even faster towards our target architecture. When we started with four people, you can only do so much. It was frustrating because you knew what you wanted to do but there was so much code to transform. You could only change small pieces bit by bit. With a larger team, we’ve been able to move much faster as more of the codebase evolves.
PK: Let’s talk more about your team. How would you describe your team?
LP: The Android team is very collaborative, even though members work distributed in different product groups. We collaborate very heavily. Our slack channels are very active. We have a lot of events and we’re friends who often hang out after work! We have good vibes in the team. Everyone celebrates when something good happens. I’m super proud of this!
PK: So you should be!
LP: I am. I feel like this has been one of my greatest achievements. We hired over 18 people in a very rapid time. We have a great onboarding process that helps newcomers quickly come up to speed. I believe we are also one of the most stable teams in N26. It is a completely different picture from before, when all the Android team members left.
PK: You should be proud of turning around the team culture. What are the three biggest challenges for the team in the next 12 months?
LP: This coming year is key for the Android team. We have worked hard towards our technical vision. We’ve identified three more main challenges that will help us grow and scale. Our first challenge is finishing our modularisation work. The second challenge is the ADL (Atomic Design Language). We want to align everyone on how things look and define a common language to use across the organisation and across all features. The third challenge is moving towards our own Backend For Front-End (BFF), which we believe will provide an even better user experience.
We believe that a user focus is very important. We want to provide value to the user quickly. We want to be able to customise what they see to provide a personal experience. To do this, we need to be flexible. Our three initiatives will help with this. These initiatives will have a big impact. It will have an impact not only in the Android team but in all the cross-functional product teams as well.
Want to work with Lucia in Berlin, Barcelona, New York or Vienna?
If you’d like to join us on the journey of building the mobile bank the world loves to use, have a look at the Android Engineer roles we’re looking for here.
This concludes Part 1 of this interview. Watch out for Part 2 where Lucia and I speak more about her technical leadership journey.
