Since its inception in 2012, Spotify has revolutionized the market. Not only has it become one of the largest music-entertaining companies in the industry, but also it has created some unique processes to drive internal teams for better productivity.
It has inspired many other enterprises to use the so-called Spotify Model, which was a must and has been giving them some direction to orient their teams.
And one of these highlighted companies is Nubank, which is a Latin American digital bank and the largest financial technology bank in Latin America. The company has offices in Berlin, Germany, in Mexico City, Mexico, and its headquarters are located in São Paulo, Brazil.
In this post, you will find how Nubank grew its teams and made more productive and effective goals that led it to get outstanding results using Spotify Model.
Before you see the story, how about checking some articles on Spotify Model?
How the relationship started
In mid-2015, Nubank decided to change the process to reach more productivity results and goals. From that point, the company started using Spotify Model squads and it was formulated to function by work teams with a common goal.
The traditional structure of companies usually places the customer service team in rooms or even buildings separate from all other teams. It sounds practical – and it seems to make sense for everyone who plays the same role to be together.
The problem is that, in this model, customer service analysts become a separate entity, with no contact with the development process, without the possibility of giving quick feedbacks, without the context of what happens inside the company.
If the focus is the customer, the team that acts as our front line could not be isolated. The Xpeers are close to the teams involved in products, processes, and communication.
With Xpeers integrated into different teams, the problem-solving cycle in the company is shorter:
One of the big changes was putting the operating people alongside the product people. Nubank’s customer service team – the Xpeers – is spread across different areas, making communication between product and operation more efficient.
Squads are required to be efficient, effective, healthy, and sustainable.
There are two main reasons for that:
- Xpeers can quickly obtain information that helps resolve customer issues;
- The product team quickly receives information about the most frequent customer issues.
Many squad Nubank teams start each week with a sprint – a meeting where everyone sits together gives visibility to their demands and decides which tasks will be resolved in that period, which ones will be backlogged, and which ones are blocked for some reason.
But holding a sprint meeting is not mandatory. If a squad understands that it doesn’t add up to the type of work it does, the squad is free to forego this ritual.
To ensure the healthy and sustainable scalability of this growth, there was very good planning of the back-end architecture, associated with a strong culture of people and processes.
Likewise, depending on where you are on Nubank, you can be invited to meetings called One on One (between two people, usually a feedback session between an employee and their leader), All Hands (with several squads from the same area ), and Retro (examine what worked and what could be improved).
How do Nubank Squads work?
Every company needs teams that work efficiently. Every company wants to attract the best talent and, nowadays, most of them talk a lot about the importance of seeking diversity when hiring.
But not every company understands what these points have to do with the service they offer their customers.
The microservices model used in the back-end since the beginning of the company and the development culture, with a lot of autonomy and confidence, helped to make this form of the organization very easy to use.
The group is empowered to decide what and how changes will be made, what management methodology to use (scrum, kanban, etc), and what else it needs to perform its role well.
There are several chapters: Engineer, Business Analyst (BA), Design, Data Science, Communicators and Brands Managers, Xpeer (Customer Service), Product Manager, etc. Some squads grew so much that they needed to be grouped into Tribes, such as Acquisition and Nuconta, for example.
Each squad has members from the chapters. In CSD (Customer Support Design), there are Engineers, BAs, Xpeers, and Data scientists (DS). Likewise, at Credit Strategy, the team responsible for improving credit approval models has staff from DS, engineering, and no brand managers.
In Acquisition, the tribe that takes care of everything related to the acquisition of new customers has people from almost all chapters: engineering, BA, Brand Manager, DS, Designer, Xpeer, PM, etc.
Squads can also “borrow” someone else’s figure if a specific demand arises or, if the need becomes more frequent, the possibility of placing a dedicated person is studied. For example, it is common for designers to work on tasks that involve more than one group.
It is also common to create guilds to deal with horizontal issues between squads. Thus, at Nubank, there are the guild of onboarding, hiring, UI, react-native, and many others to take care of matters that are not of a specific squad, but of interest to everyone.
Guilds serve to support new technologies or solve problems common to all squads. If someone is struggling with StyledComponents or has started studying Flutter and wants to know who else is interested, they can rely on the specific guild or create a new one.
How goals are set?
Demands are defined and prioritized according to the squad’s OKRs, which are determined according to the company’s OKRs, and the earnings/expenses predicted by models that people working as BA analyze.
If a particular task has the potential to make the squad hit some or a few OKR(s), then it is detailed, discussed with all the chapters that will be involved, before it is done.
In general, the deadline is not the most crucial component of an OKR. However, as one of the company’s values is “We think and act like owners, not renters” the vast majority of people want to ship – put things into production.
The idea of continuous delivery is strong and there are internal tools made to ensure that everything that is produced goes for public experimentation as quickly as possible, with the highest quality and in the most efficient way.
When something is very repetitive and taking a lot of time from the team, there is the automation of it. Expressions like “quick feedback” and “let’s learn and not be afraid to make mistakes” are commonly heard in the hallways.
Sometimes, by the nature of this structure, two groups are working on something that could be reusable. As communication tends to be more efficient in this model, however, it is common for teams to find out quickly and start working together.
In addition to publicizing it to other squads so that anyone who wants to use and/or contribute can join the group. It has also happened that a problem arises and it is not clear who is responsible for that part, or the squad that implemented that part in the early days of the system no longer exists.
GitScrum helps you get along with all Squads
GitScrum loves to bring all teams together and offers the best tools to help you reach the best result on time! Find your way to work with your Squad with GitScrum!