DevMic – Interview with Eduard Schikurski

DevMic is a part of our blog where we give developers the opportunity to share their experiences and ideas with the community. Have a great story and want to be featured? Get in touch with us through devmic@pusher.com

Eduard Schikurski is working on the next generation of business operations systems at Monzo, a young London-based startup with the mission to build the best current account in the world. He wants to push the boundaries in terms of how technology can enable and support a highly scalable and agile customer-centric organisation.

Can you tell us about your background and your company story?

I joined Monzo as a full-stack software engineer last March, when we were just about to start the beta phase of our prepaid card programme. Before this point, I had been working for several startups in the London area, focusing on front-end web development with Play Framework and Angular. This was a big change from my previous role in Germany, where I led the backend engineering team of the German Insurance Association’s national insurance risk and fraud prevention system – as one would expect, it was a project build on top of a Java and JEE backend using SOAP and proprietary message queue solutions, though at least without the burden of heavyweight JEE application servers. Instead we packaged the application into smaller lightweight services, which communicated with each other over a custom-build RPC solution.

Joining Monzo was largely driven by my deep dissatisfaction with banks and how they treat their customers. But even more than this, I was deeply upset by all the opportunities that the established banks missed because they had lost their focus on what should be their most important priority: the customer. Instead, they often think in terms of financial products and instruments, where the customer gets degraded to mere consumer. At Monzo we take a different perspective, we put the customer firmly in the centre of our focus. We try to learn everything we can about our customers, and then transfer this insight into a solution that helps them manage their financial life in a delightful, effective way. Achieving this requires a great interdisciplinary effort and a continuous passion for our customers and the problems they face, but it is worth the hard work. A great example of this approach is the prepaid card programme – it allowed us to develop a world-class mobile banking application with our customers’ needs and voices driving that development.

Having experience in both the enterprise and the startup environment, I gained a great perspective on what is going wrong in a lot of established companies. I’m absolutely thrilled to see how well the approach we are taking at Monzo is working so far and how huge a positive impact it’s having on us and our customers.

What are you building in Monzo?

I’m part of the Internal Product team at Monzo, whose purpose is to increase the efficiency and effectiveness of everything we do at Monzo. This includes everything from building internal tools to support our Customer Operations team, to improvements in our mobile application such as the in-app help screens. The long-term aim of our team is to enable every customer support agent to support 100,000 customers – 40 times more than the average UK retail bank. We believe that the key to achieving this goal is to take a holistic approach (looking at the problem from both the supply and the demand perspectives), and to develop the applications in-house (so that we can tailor the solutions to our specific problems).

One of our main internal applications is the business operations portal, where I am heavily involved in the architectural design. This is designed to solve a problem many large companies face: how do we manage tasks that can’t be automated but require a human to perform it in a effective way (e.g. by making a decision), given that different tasks requires different qualifications, have different SLAs, and different priorities? And how do we do this with a globally distributed and very diverse workforce?

Supporting this kind of work becomes even more important in a highly agile organisation, where there are not only tasks you can’t automate but also many tasks you don’t want to automate, e.g. tasks that are part of an experimental product feature and service. Because these types of task can come from any team in the company, we’re empowering developers across the company to easily feed into this framework: you can create specialised user interface components within hours on top of our micro-service architecture, and simply embed them into a central worklist application. This will allow us to stay agile, even on a large scale.

Designing and developing this application is one of the most interesting projects I have worked on in my career. It crosses so many boundaries, and the technical solutions are often only a small part of the overall solution due to the organisational and cultural changes that are accompanied by it.
If you want to know more about how we build our internal system then you should watch this short recording from one of our last Open Office meetups.

How is Monzo innovating the backend compared to regular banks?

Regular banks tend to rely heavily on legacy technology – as mainframes and large codebases written in COBOL, which makes it very hard for them to adapt to new realities like the trend towards cloud computing, agile micro-service based architectures and containerised operational model. It is quite understandable that there is a natural tendency towards minimising the amount of change when you consider the huge risk that every change introduces to a system like this. But the world is moving fast, and the established organisations have to move with it, otherwise they will fail. More recent approaches that promised to help with this kind of problems like SOA, ESB and Web Services failed in some instances spectacularly, and in many cases they didn’t deliver what they promised. The way we build and run large software systems has changed so dramatically over the last decades, so that it is often easier to just write it from scratch instead of trying to iterate on existing systems.

At Monzo we are following an approach often associated with large internet companies such as Amazon, Netflix or Spotify where we split our backend systems in a large collection of small micro-services. We write most of our microservices in Go, although our platform supports polyglot service development. Go is a fantastic language for this, as it offers many important features such as in-built support for concurrent programming, while remaining very simple. The services are containerised with Docker and run on a fleet of CoreOS machines using Kubernetes as our Cluster Scheduler. For the communication among the service we use linkerd for RPC based communication and Kafka for asynchronous messaging.
This modern architecture allows us to build highly flexible banking systems that can be easily changed and adapted to new circumstances. Engineers from any team are able to deploy new backend services within minutes into our production system without worrying about breaking things. This allows us to move fast, to run experiments and to iterate in very short cycles based on feedback from our community.

How important is it to use realtime in online banking?

How important or not this is to any service is largely driven by customer expectations. As many companies are incorporating realtime features into their products, customers get used to it and often they don’t understand why others don’t offer this immediacy. Companies that are able to respond in real-time and provide information when the customers asks for it have such a huge advantage over companies that can’t do this (e.g. due to batch-oriented processing systems, etc.)
This realtime requirement doesn’t stop at the customer-facing applications, rather expands to a lot of internal systems that directly or indirectly contributes to the customer experience. A good example of this is the worklist application I have mentioned earlier. A lot of the tasks have a direct customer impact (e.g. identity verification tasks) and we want to be able to resolve them as quickly as possible. This requires a very efficient process where the worklist application really supports our customer support agents as the user of this system. Part of the solution is to make the current state of the system always visible to the user and to ensure a steady flow of productivity. Some of the problems we’ve had to solve include showing incoming tasks, updates to the task status, indications which task is currently in progress by another user – and all this in real-time without any page refreshes which would break the flow. Pusher was fantastic in helping me to develop solutions to these problems in a very short time!

Do you use bots or AI at Monzo? How did you integrate them in your app?

We don’t use any chat bots at Monzo. We believe there is a lot of value in the personal contact to our customers. Our customers really appreciate this, especially when they need help quickly because something went wrong. In addition it is a great way for us to ensure we’re getting continual feedback about our product and service, which is the raw material for improving our offerings and developing the company.

But maintaining world-class customer support while scaling up our customer base will become an ever-growing challenge to us. Customer support is at the heart of our business and it is essential that we find ways to scale up our customer support operations without compromising on quality. Supporting our staff to offer the same or even better level of service is the main goal. Everything related to customer operations must become more efficient and more effective, and this is where we start to explore how we can use AI to improve our systems and processes. One of the first machine learning models we’re training is dedicated to identifying the most likely actions a customer support agent will need to take to resolve a customer support query. This will help us to speed up the the resolution time of customer support queries, and to speed up and simplify onboarding new team members into the customer operations team. Another advantage of having such a model is that we can use the results in a different context – e.g. in this case we were able to use the model to improve the in-app help screen’s search functionality. This is part of our self-service initiative, and another piece of the solution to scaling our customer support organisation to an ever-growing customer base.

If you’re interested to read more about the data science at Monzo I recommend reading the blog posts from Monzo’s Head of Analytics here and here, or our blog post about how we use machine learning to fight fraud here.

What are your favourite tech stacks and why?

At the moment I’m heavily invested in React and Redux based web application development. I’m still utterly amazed by the speed the JavaScript community gained in the last couple of years and the solutions they came up with to address problems we didn’t even know we had just a couple of years ago.

React is a prime example of this development, as it changed the way we think about front-end development for good. A lot of preceding approaches were based on the MVC pattern that tries to separate the codebase on a structural level, but is lacking in terms of predictability. Problems such as cascading effects can have a huge impact on the application performance but even more on the developers’ productivity in large front-end applications. Instead of improving upon existing solutions and best practices, Facebook took a fresh perspective on the problem along with some inspiration from other software engineering fields. And it was worth it! The solution they came up with has changed the way we look at the problem of developing web-based front-end applications, and introduced a paradigm shift whose impacts can be seen in a lot of popular open-source projects and applications.

I believe that having the courage to discard common best practices and experiment with novel approaches together as a community is a key ingredient to the future of our discipline. It is easy to see that the React community, and the JavaScript community as a whole, have internalised this and I think that this development is amazing and cannot be overrated.

What is the best and worst advice you ever received?

I have learned a lot the hard way by making a lot of mistakes first-hand instead of seeking out advice early. It took me quite a while before I started to proactively ask for feedback. I can’t really remember the worst advice I’ve been given, as I tend to forget about these. The best advice I must have received was while working for the student organisation AIESEC: namely how important it is to actively look for feedback you can act on, and to use this for my personal and professional improvement. Getting feedback is the single most effective way to become better in whatever you do. Everyone has a lot of blind spots – things you don’t know or are not aware about yourself, and the only way to uncover these is to talk with people you trust and value. At the same time, giving good useful feedback is one of the most underrated skills, which is why I really appreciate that Monzo has built up such a strong feedback culture based on trust and collaboration.

What other developers inspire you?

There are a lot of amazing developers that have pushed the boundaries of possibilities and changed the field of software engineering for good. I’m fascinated by the work of early software engineering pioneers such as Parnas, Dijkstra or Brooks following the software crisis in the 60s, their work was instrumental in defining what it means to be a software engineer in the modern world. Studying the work of these early pioneers, and many of the academics and practitioners following them, is of the best things one can do to become a better software engineer in my view.
That said, I think the world changed significantly since these early days. A lot of innovation now happens in public, in the form of community-driven open source development. Think about projects like the Linux kernel, React, Kubernetes, Chromium, and many others. Both the quantity and quality of open source projects has increased dramatically, sometimes to a level where no proprietary solution can match them. One of the developers who work I followed closely while learning React is Dan Abramov. He developed Redux, one of the most elegant state management solutions I’ve encountered. And he has done it by focusing on a few clear goals, such as high predictability and debuggability, instead of trying to solve a huge number of problems in one go. The library is a great example of what you can achieve when you really accept that every solution is just a balance between tradeoffs. Furthermore, he’s provided excellent documentation and a world-class video series on egghead.io for free.

Redux is not even the most inspiring aspect about Dan Abramov: for me, it is the way he embraces the open source development community, and his efforts to help it thrive. Seeing how he engages with the community on StackOverflow and Twitter, his humbleness when giving feedback to the community, and the way he encourages and fosters new alternatives and experimental ideas – these have had a profound impact on me and my view of what excellent open source development should look like.
There are still a lot of unsung heroes in the open source community and I would like to thank every one of them for their efforts contributing to this incredible ecosystem of ideas, problems, and solutions