Our road to autonomous product teams

A deep-dive from the inside - how we learned the best team setup for our neobank, by Łukasz Wójcik

We are a neobank, meaning that we are 100% cloud-based, working with leading tech companies such as AWS, Tink and Snowflake, and our time is spent solving customer problems. But it also means that we are in constant change and growth. I’ve been part of this amazing journey for quite some time now, and have gathered some observations that I believe highlight the key factors that have been driving us towards building scalable and autonomous product teams. These are and have always been, crucial for our success and something that will continue to evolve, as we broaden our product portfolio and enter new markets. In this article, I will share my transparent view of the present setup of our teams and how we have come to this.

When your organization is growing and you have multiple teams, you will always face the moment when decisions have to be made on how to split the work. As I see it, and this is not a conclusive list, but your options are

1. Component teams. Specializes in one part of the system or one component. The team consists of specialists only in this specific area. It means you may have a Database Team, Frontend Team, Business Layer Team and so on. You can break down those areas further if needed. Each component team delivers their part of the functionality and then the bits are connected to receive a fully working feature.

2. Feature teams. Cross-functional teams that can deliver fully working features from A to Z. Within the teams there are engineers with different specialties (database people, frontend developers, QAs, backend developers and so on). The Feature team is focused mostly on the output – to quickly deliver many work items and usually receives requirements from the outside. Either from the product department or external stakeholders.

3. Product teams. Cross-functional teams that deliver full working features. They can have one or many products, but the most important thing here is that the team has full life cycle ownership and responsibility for the products. It becomes like start-ups within the company – meaning the mandates are brought down to the Product Managers, or should I say “Product CEO:s”? They care about the product and the problem it solves for the customers during its whole lifetime. The team has the full context, both technical and business-wise, and is empowered to decide on the product and the way they work.

Reflections of the past
In the past, when our organization was smaller, each engineer usually worked on many products simultaneously and had to switch context regularly. Sometimes daily. This was the only way we were able to quickly react to the ever-changing market and deliver solutions that would help our customers. This worked well to some extent. It is quite a good model for a start-up company. At the same time, it was a demanding environment for the developers. And, unfortunately, this model doesn’t scale very well. When you have a lot of engineers, where each of them “works on everything” and receives tasks from different directions, this could, if you are not cautious, end in a state of inefficiency, and to be frank, chaos.

Later, when we wanted to speed up further, realizing the business needs, we hired more engineers. We created teams of 5-7 people and started thinking about how to split the company backlog between these teams. Very quickly, we excluded Component Teams as that model didn’t suit our needs. We are a highly agile company with a can-do mindset and are fully focused on delivering solutions and solving our users' needs. With Component Teams, it’s harder to keep the focus on the end-user. Engineers may quickly just focus on their own layers, modules, technical excellence and so on, with no connection to the real customer’s needs. Additionally, delivering fully working software in this model requires a lot of coordination. To summarize the advantages and disadvantages of this setup:

Advantages
+ Better code quality / a unified approach in one code base
+ Clear responsibilities

Disadvantages
- A lot of coordination needed
- No end to end ownership resulting in less speed and innovation
- Slower cycle time due to coordination and communication between teams
- No direct connection to the end customers and their needs
- Hard to use agile techniques to deliver something fully working and quickly getting customer’s feedback

Launch, iterate, analyze AND do it all over!
At the time we had just launched our new refinancing product Reduce™, which allows people to lower their interest costs of one or several loans and thereby save money each month. We already had many ideas on how to improve it, what features should be added next and so on. At the same time, we had several products already known on the market, used on a daily basis by our over 200 000 customers. Those products were doing great but also needed some attention. So we had a somewhat classic challenge of prioritizing among many very important tasks.

Technically, our solutions are taking the most from serverless architecture and Infrastructure as a Code(IaaS). Our systems are based on AWS Lambda, SQS, SNS, S3 and ECS services to mention a few. All these elements make it easier to speed up the development, make the maintenance easier and provide the ability to split the work between multiple teams. The solution became that we set up a structure where each team was cross-functional, and could deliver any feature needed for any of our products. We created a Feature Team setup and basically became a factory of features, with one single backlog for the whole company. But after some time we realized that such an approach is associated with some challenges. The most significant ones being commitment and ownership. Since certain areas of the team’s work often change, developers may not feel connected to any of the products. They’re focused on output (implementing features) and not to the same extent on the outcome (the customer’s benefit).

Summary of the Feature Team Model
So, as mentioned, even though the model worked for some time we noticed several challenges. The model makes it less probable that engineers suggest improvements to achieve a better customer experience. They would not be experimenting and would be less interested in how the product is going, what the feedback from the end-users is, and so on. We observed that ownership of the code may be a challenge as well. Who should fix an issue if this is an area where all the teams make changes? Who should improve the continuous integration tooling like Teamcity, maintain cross-product microservice or take care of the AWS organization? It wasn’t obvious and many times issues needed to be directly assigned to a specific team. The team in question didn’t always feel that it was fair to give the task to them. Switching context was another challenge. Not only had the teams switched the codebases, but also the domain understanding. Sometimes even during one sprint. Working this way, how can we keep focused on the customer's needs? Here’s a summary of the Feature Teams Model from my perspective:

Advantages
+ Flexibility with regards where to assign more development teams forces
+ Delivering fully working features without a need of coordination with other teams

Disadvantages
- Context switching
- Lower commitment
- Lack of ownership with regards to the codebase, its quality and with regards to the product, its vision and key metrics

Learning from experience – adapting to change
We were aware of these issues and knew something needed to change. As we never stop moving and aren’t afraid of experimenting (quite the opposite actually, it is in our DNA), we decided to form the teams entirely around our products instead. One team usually has one product they work with. It always makes it very clear for everybody who owns a specific product. We started with one team and systematically added more working this way. Finally, we observed a big change.

Once a team owned the product, the whole team started to understand who the customer is, what problems we’re trying to solve, what the strengths and weaknesses are, how the roadmap looks like and much more. Now, teams have built deeper relations with the Product Managers and received more business context. The engineers have quickly become more engaged in proposing improvements and new features because of this. This way of working introduced more fun, we felt more empowered and felt that we could experiment more, as everybody could find an interesting way of achieving a business need. This also produced a lot of positive emotions when someone’s idea had been implemented and launched into production. All team members started to check users’ feedback on their own. They started to care about the whole product. Now they better understand that the quality does matter. If they implement something wrong, the consequences of the issue will touch their product that becomes like one’s child as they will need to maintain it and fix necessary bugs. Here’s my summary of the Product Team Model:

Advantages
+ Better commitment and ownership
+ Better solutions as now the whole product team shape them and adjust to the context they know and understand
+ Focus on solving the specific issue of our customers and not only on delivering features
+ More fun for the developers! They understand more and can take initiative and make an impact

Disadvantages
- Worse flexibility - It’s not possible to quickly move more people to an area that is the top priority for the company
- If many products use the same code base there’s a need for additional effort to create rules and unify solutions in common areas

Present – where do we go from here?
Have we reached the end of the road? Is our work finished? Nooooooooooo! And it can never be. Being curious and active, questioning the status quo and to never stop moving is part of our DNA. Right now we try to empower the Product Teams, so they have a lot of freedom and power to decide on their own regarding the most important aspects: In which direction should the product go? What needs to be implemented? In which order, and how do we fulfill our customers’ needs? How to organize the work inside the team? Who’s responsible for what?

As you may have noticed there’s a lot of questions to answer. But we know what we want, which is our Product Teams to be truly focused on the outcome – to bring value to the customers! So to summarize this article, truly empowering our Product Teams is the next step in our journey. I can’t be more excited!