Growing mobile capabilities at Nubank

Nubank has always been a mobile-first company with products built to create a close relationship with our customers. We began as a Credit Card company in 2013, then launched our own Rewards program and, in 2018, Nubank’s account. All of them have two things in common: they were built to help our clients understand and take control of their financial lives, and they must work perfectly on people’s phones.

So, it comes as no surprise that the mobile development team should be deeply involved in decisions regarding our products — and, as we’ve grown our portfolio, we’ve also learned a few things about growing our mobile team.

Nubank was influenced by the Spotify model, with autonomous teams called Squads to tackle business objectives. “Squad is a small, cross-functional, self-organizing team. They sit together and have end-to-end responsibility for the stuff they build: design, code, deploy, maintenance, operations, etc. Each Squad has a long-term mission and defines its own OKRs each quarter. Autonomy basically means Squads decide what to build, how to build it, and how to work together while doing it. There are some boundaries: squad mission, overall product strategy, and short-term goals.”

While most of the company worked in Squads, up until last year, our Mobile Engineers were an activity-oriented team (or Service Team), shared across the organization as the number of mobile developers was not enough to have them in Squads.

Our Head of Product was responsible for prioritization across Squads and kept a list of features to be developed. Mobile Engineers would then move to the Squad on top of the list and work with them until the feature was shipped.

By working this way, Mobile Engineering was benefiting from the closeness of its team members, making it easier to share knowledge, have tech discussions, and organize whiteboarding sessions to solve problems. On top of that, having a team specialized in mobile development made it possible to keep code consistency across products in our codebase.

However, as the company and the number of squads grew, it became harder and harder to keep working as a Shared Service. We faced several problems, as it shows in the next section.

Allocation

Decisions around specialists’ allocation kept increasing and becoming more complex. It was also troublesome to match platform needs (new iPhone is out; another version of Android was released; need to fix crashes, etc.), product decisions (Is this feature platform-specific? Do we have to launch it on both platforms simultaneously?), and other variables.

The number of developers allocated to each project would depend on the answers of those (and many other) questions, such as developers’ needs and availability (holidays/vacations/days off/sick days); work on productivity tools, pipelines, etc.

Code ownership

Whoever developed any feature/library would still be responsible for that code even after moving to another Squad. That posed two challenges: we were specializing our developers even further and concentrating knowledge of shared libraries in just a few people. It also means they went back to work on old projects, having to change context constantly. 

Sense of belonging

There’s unity inside a Squad. Its members share a goal and a vision of where to take their product. This unity motivates and makes teams focus on their objectives. Mobile developers would come and go, not participating in the discussions and definitions of the Squad long-term goals — making it difficult for them to connect with the Squad Objectives and Key Results (OKRs), and evaluate how their work impacted the company goals.

Platform needs

Activities that don’t belong to any given Squad, inherent to both Android and iOS platforms, were difficult to prioritize and would take time away from product development. Examples of such activities are: upgrade a plugin the app uses; build and deploy to the store; improve the build pipelines; SDK updates; etc. With no time to improve the tooling, developers’ productivity suffered — as well as their life quality.

Rework

Developers would join Squads at random stages of the product development life cycle, forcing a lot of re-discussing on what was “already decided”. When mobile engineers arrived, they would often need to refactor APIs or review, re-test, or even discard animations that were too heavy on our customer’s devices. This would also impact delivery dates.

These are all well-documented side-effects of working as a Service Team. Sriram Narayan, in his book Agile IT Organization Design states:

“By definition, shared services are used by teams responsible for different business outcomes. The shared team itself isn’t responsible for those outcomes. It is no surprise then that we sometimes get the feeling of dealing with mercenaries when interacting with a shared service team. They don’t seem to have their skin in the game. Shared services struggle to find purpose. An organization design that aims for conditions of autonomy, mastery, and purpose should strive to minimize shared services and eliminate them from mission-critical value streams.” (p. 54)

To turn things around, we knew we had to have mobile developers as an integral part of Squads, moving away from the Service Team model, working in Products instead of Projects. This new team structure requires a bigger number of developers, and we needed to hire at a much faster pace, which we did. As we hired more developers, we would allocate them to Squads according to the list of priorities.

We also had to improve developers’ productivity and overall quality of life. For that, we created a “productivity” team called Mobile Platform that started by improving mobile pipelines and tooling. This team took over the responsibility of building, deploying, and rolling out the app to our customers.

Since the Mobile Platform Squad was responsible for the release of our apps, it was possible to implement a release train, with releases following their own schedule, regardless of each Squad’s production cycle, avoiding bottlenecks.

Another great benefit of improving our tooling and forming product teams is the increased responsiveness: developers with both business context and technology knowledge can make better decisions, with more predictable results and within a shorter time frame.

By working on this model, decisions about prioritization remain in each Squad and are thus less centralized. Sometimes, there’s still the need to prioritize something across all Squads, such as an Xcode update or a big redesign launch. But even these situations are now simpler to sync since each team handles its own priorities and can better weigh how they fit within the company’s overall objectives.

It is important to mention that we’re all still adapting to this rule, since it comes with its own set of difficulties, but we already see improvements across teams to make sure their code will be in the next release train.

While working as Product Teams has some difficulties, it’s important to point out the silver lining while teams are getting used to their new composition and workflow.

We use Pull requests for code reviews. They are now harder, since a PR might not represent the whole discussion behind that change and the tradeoffs developers made, especially when the reviewer is in another Squad and won’t have the full context around that PR. Reviews would raise questions already considered, and this could lead to unfruitful discussions if we didn’t take this as feedback to improve our PRs, communication style, and overall review process.

Another issue raised was the underutilization of mobile developers, to which a great answer is this quote from Sriram Narayan’s book Agile IT Organization Design:

“Will specialists dedicated to product teams be underutilized? Probably yes. This is where the rubber meets the road in terms of trading off cost-efficiency for the sake of responsiveness. Beyond a certain threshold of utilization, responsiveness decreases as utilization increases. This is a well-known effect of the queuing theory. Without some slack, we can’t have responsiveness. A fully utilized highway is a parking lot.” (p.60)

It’s important to notice that the underutilization of developers in each Squad is what allows them to have frequent meetings to share code architecture across products, talk about our build pipelines and discuss feature development, hiring, and technical improvements, to reduce the impact caused by the difficulties listed above. This time is important to understand the bigger picture and keep the unity of mobile developers since we all have to ship one binary together.

Our current structure gave teams the autonomy and capacity to act on their whole value stream, and developers are finding a sense of belonging and contributing much more to their newfound squads. A schedule of releases makes feature planning easier, and customers are receiving an app of better quality. If any of these challenges resonates and is something you would like to work on, we’re always hiring. 😉

Is your company going through a hyper-growth phase? What challenges are you facing, and how are you and your company dealing with it?