Tech Leadership at Moonfare, a Rapidly-Growing Fintech Startup

They offer a private equity fund investment platform with low minimums (starting at €50,000) and low fees (up to 0.5%). Since its launch in January 2018, the platform has seen impressive growth.

To date, it has attracted 13,000 registered users and enabled them to invest more than €1 billion. Moonfare receives many rewards and has been recognized among the Top 10 German Startups of 2020 by LinkedIn.

I spoke to Elena Melashchenko, Principal Engineer in Software Development at Moonfare, about what such rapid growth means for the company and about her role in tech leadership. She offered insights on organizing fast-growing tech teams in the financial industry, maintaining effective communication, measuring growth, and honoring the trust that Moonfare’s customers have put into the platform.

Paulina Burzawa: Recently Moonfare celebrated crossing €1 billion in Assets Under Management. Congrats! What does this achievement mean for you as a Tech Lead?

Elena Melashchenko: We are aware of the trust investors put in us. Myself and other team members feel that it's a very big responsibility to make sure that everything will be up and running. This is why we always follow the best practices and test extensively to make sure the platform will work for our customers. Whenever there are any problems, everyone just jumps onto it, trying to solve the issue.

And because of that huge responsibility, our engineers must feel the support from their management.

All our Team Leads and I need to be there for them, making sure that everything we deliver is the best possible product, taking into account the abilities and experience we have.

How much of your job is about technology and how much about leadership?

Mainly, I make technical decisions and support other teams with features and planning. I would say 80% of my job is technical, and 20% is leadership. The technical part involves helping with any tech issues, fixing things, and introducing improvements to projects.

In terms of leadership, I do mentoring, help others learn and grow. We have five delivery teams, each with their own Team Leads. So my role can be about advising them when they need to choose between several solutions.

Asking on behalf of future tech leaders — who are the crucial stakeholders you work with and what are your recommendations for effective collaboration?

I work with the tech leaders I mentioned, and our Head of Engineering. I collaborate closely with other Team Leads and help DevOps with the infrastructure. Another level is, of course, engineers, and I support them with any problems they face, helping them find the best solutions.

On the less technical side, I communicate with every department in the company. When I joined Moonfare three years ago, we didn't have tech people in-house. I’ve been here the longest, so I know a lot about the project. This means that employees from other departments can just ask me about any problems they face and I can answer their questions quickly.

Lately, I’m trying to share my knowledge with others as much as possible.

I want to make sure that Team Leads and engineers will be able to answer different questions related to their domains independently.

How does Moonfare approach the software development process?

We follow Agile principles, and we have a Scrum master from Netguru. In terms of the processes, we use the usual Agile ceremonies like standups, retrospectives, planning calls, and sprint reviews.

During planning (refinement) we go through tasks in the backlog and discuss details of implementation, making sure everyone is on the same page, acceptance criteria are clear, and required information is present, enabling developers to complete their tasks. During sprint review, each team presents to stakeholders the most valuable tasks that were delivered in the past sprint.

What are your expectations towards a cooperation with a software development partner?

We work with Netguru and we have one more company which helps us on the DevOps side. We also try to hire people in-house and work with a limited number of external agencies. The situation with COVID-19 forced everyone to work remotely, so right now cooperating with external engineers would work the same way as working with internal developers. But at some point, we'll go back to the office.

Overall we have had a very good experience with both of those partners. The main expectations we have are clear communication and a willingness to meet our expectations regarding who we expect to have on the team. The quality and the level of expertise of the engineers we work with matter, but we also pay attention to how they fit within a team, and how they collaborate.

Effective communication is often a challenge for companies working with external partners. Is it your case? If so, how do you tackle that challenge?

We use Slack for chatting, with multiple channels to share information between everyone. Google Meets serves us well for any other meetings. And then there are emails, as well as Confluence for documentation. This is our main toolset for sharing data and communicating with each other.

Regarding challenges, internet issues such as people unable to join meetings sometimes, has become a larger problem now when we all work remotely.

I personally miss normal interactions, especially with people that used to work in-house. When I run an important meeting, I require active participation but remote work limits this very much.

When I run an important meeting, I require active participation but remote work limits this very much. Additionally, during calls many people switch off their cameras, so we're missing the human aspect of our interactions as well.

Before COVID-19, it was much easier and faster to get things done.

We try to have more team events online. For example, organizing games and interactions. It’s important to not only focus on work but also on our relationships, team building, and communication. We look for ways to reward people who did a great job, as well, as part of trying to tackle the pandemic.

In our fast-changing environment, not all the tech and strategic decisions lead to the best solutions. What is your approach to testing and how do you manage the implementation and eventual rollback?

At the moment, we try to develop very quickly without losing quality. Of course, not all of the decisions we’ve made have been beneficial for the tech side. As soon as we release a solution that has to be done fast but not in the best way, we make sure to create a supported task to eventually redo or fix it.

This approach allows us to move fast while remaining relaxed, in a sense. Not everything needs to be perfect the first time around, but we do try to conduct proper future planning and delivery.

We have recently introduced a discovery phase for features. We review our process and look into how elements of a certain feature should be implemented to satisfy the end customer. Then the project is handed over to a tech leader, for example, to review what needs to happen on the tech side to deliver the feature. Thanks to that we are able to assess how much time it will take to implement the solution, decide if it’s urgent and what price we are willing to pay for developing it quickly.

What is your approach to tackling tech debt?

We’ve recently changed our approach to handling code debt, i.e. consequences of any compromises in the development process we might have made.

Before, we created epics for each team based on their domain with a few tech debt tasks for each month. So, for example, in January all teams had at least two to three tasks, and each task was taken to a sprint. The team’s job was to make sure that they would be delivered within the month.

Now, we have a pool of tech debt tasks. Before each development sprint planning, Team Leads add several tech debt tasks to their sprints to have at least 10% of all tasks related to tech debt.

We established a quality groups initiative. Its main aim is to identify different areas that require improvements, and in turn, increase the quality of our product. Some of the groups include product elements such as code readability, testing, security, or setup.

Each of the quality groups consist of QA units, developers, and product specialists who focus on different problems we face and try to solve them.

Tasks created from quality group discussions are also considered as tech debt and included in different team sprints.

We make sure that we don’t forget about anything from our tech debt. Otherwise, we would be building upon things that haven’t been fixed, which could result in huge problems in the future.

How do you define success in the software development process and what KPIs do you monitor?

We didn't officially call them KPIs, but we have quite a lot of key points.

Every team does a retrospective after each sprint. It focuses mainly on how long it took to deliver the feature, how efficient the estimation process was, and how many bugs occurred.

The engineers monitor separate KPIs, but with a focus on how successful they were in delivering their goals. If a team delivers what the company expects, that’s the main measure of success for them.

How has Moonfare changed since you joined it?

We became much more mature. Back when I joined, we didn't have many of the processes we use today. The processes were established as soon as we started growing — hiring new people and building the platform.

What really helped was that we hired a lot of very experienced people and that we did our best to build an atmosphere of excitement. We wanted to enjoy doing what we do.

We still have the same supportive environment today, and we openly share what we learn. Many new hires came from different big companies and we try to make sure that we implement best practices they bring on board. We read a lot of books and keep track of how things are working out for Spotify, SoundCloud, Google, Amazon, and other big players.

We try things, see how they work, and if they don't work for us we change them. We want to stay flexible in introducing best practices. Every team is different and you need to try the best solutions you can find, get inspired by other companies, and adjust the implementation based on how it works for your team.