In 2004, Zopa embarked on a quest to build better financial products using technology. One of the lessons we learned is that building a well-functioning tech team is hard. You need to hire great people and put them in an environment where they can thrive. The team structure has a huge impact on their productivity and during the years, we’ve been trying to find what works best for us. We started with functional teams but as we grew we found that they were limiting us. This prompted us to reorganize into cross-functional tribes. In a series of blog posts, we’re going to tell you what we learned during this journey.
The problems with silos
Most classical companies are organized in functional divisions. What those are depends on the industry, but some typical examples of functional divisions are marketing, sales, development, product, operations, and customer services. This structure feels natural. Each person in the team has a specific job, so it makes sense to put people doing the same job together. At Zopa, we followed a similar approach. We had a marketing team, a development team, a product team, an operations team, a risk team, a data science team among others. This had some benefits.
- Knowledge sharing. People in the same team naturally talked to each other and shared knowledge. More experienced people could coach others and develop their skills
- Leadership. In a functional team, it was easy to see who the leader is. In most cases, it was the person with the most experience
- Guidance and mentorship. Inexperienced people could go to their line manager for guidance in their specific job, as they have the same skills.
However, we found many problems as well
- Communication. The teams easily became isolated from each other. Developers talked to product managers less. The same happened with other roles, leading to miscommunication.
- Process overhead. As we needed multiple skills to deliver a product, we had to involve people from multiple teams. Because of silos, we needed a process to manage this, so there were a lot of rules to follow.
- Lack of ownership. There wasn’t a single owner for each product. Responsibility lay with multiple people, who were only responsible for finishing their own work, not delivering the whole project. People handed work over to other teams, and stopped caring about what happens next. We called this the “not my job” syndrome.
- Misalignment of incentives. Each person was assessed on their functional skills. If they wanted to grow in the company, they only need to become better at their job, but not necessarily work well with other roles. The silo structure promoted experts, but not a broad set of skills.
- Slow delivery. The introduction of more processes for managing projects and handovers caused a significant drop in productivity of the whole company. A good example of this is the launch of our automated risk model. The project involved product managers, data scientists and developers. The machine learning model we use was originally developed by data scientists, without involving developers. When we needed to put it into the production environment, there was a lot of frustration about not following best coding practices. If developers had worked with data scientists from the beginning, we wouldn’t have had such problems.
- Inflexibility. The structure was quite rigid, and we couldn’t adapt it to different projects. It assumed every project is the same and follows the same process. When projects were technical in nature, this wasn’t a problem (as they were only done by the dev team). The moment there was any customer or business impact, it caused a lot of pain. One project we did was to redesign our lender statements. This was a major reporting feature for our customers and it had tax implications, but also impacted accounting. In addition, we needed to revamp the way our ledger was implemented, because the original implementation didn’t support the features we needed. All this meant that the project involved UX, accounting, development, product and customer services. It was a single screen on the website which took us months to deliver, but everyone thought it should have taken us a fraction of that time.
As the Zopa team grew, we quickly realized that this structure wasn’t working. It could have worked well in a factory, where each person’s job follows a recipe. In a dynamic environment this wasn’t the case. We knew we needed a change and started exploring what a new structure could look like.
The first step was to identify the objectives of implementing a new team structure. We wanted to have a clear idea of which problems we’re trying to solve. After some discussion, we narrowed down the list to the following:
- Ownership. We wanted to encourage everyone to own the product they are working on and feel like they are responsible for it. No more “not my job” syndrome.
- Autonomy. We wanted each member of the team to feel empowered. We didn’t want people who just implement ideas given by the company management, but free thinkers who have opinions on how to make the product better, and feel confident that they can do it.
- Communication. As our team grew, we knew that we have to communicate better, otherwise any team structure would fall apart.
As we did more research on alternative agile team structures, we found many potential solutions. One of them was a model proposed by Spotify. It was promoting cross-functional tribes focused on product areas, and sub-divided into squads focused on delivering specific features.
We really liked the ideas proposed by Spotify and decided to give them a try. However, we knew that we had to make some tweaks. Working in the financial services industry is very different from the music industry. We have to stay on top of regulation and pay more attention on treating customers fairly. After all, this was why Zopa existed in the first place. We started exploring how we can adapt the Tribe model to our needs. We came up with an alternative and completely reorganized most of the company. It was a bold (and scary) move, but in hindsight, it was definitely worth it. It had a massive impact on productivity and focus, and we managed to meet crazy deadlines which looked impossible before. In the next part of this series, we’ll share more details of the journey and the how we approached the change. Stay tuned.