Growing mobile capabilities at Nubank
The challenges we’ve faced structuring our organization before we tripled the number of mobile developers to give autonomy and ownership to our product teams.
This article has been migrated to our new blog. Find it at https://building.nubank.com.br/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, recently, NuConta. 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 doesn’t come as a 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.
How teams work at Nubank
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 define 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 on Squads, up until last year the 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, pairing, have tech discussions and organize whiteboarding sessions to solve problems. On top of that, having a team specialized in mobile development made 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:
Main challenges while having mobile engineers as a service team
1 — 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? Does it have to launch on both platforms simultaneously?) and other variables. The number of developers allocated per 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.
2 — CODE OWNERSHIP: whoever developed any feature/library would still be responsible for that code even after moving along 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; they were also required to go back to work on old projects having to constantly change context.
3 — 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 difficult for them to connect with the Squad Objectives and Key Results (OKRs), and to evaluate how their work impacted the company goals.
4 — PLATFORM NEEDS: activities that don’t belong to any given Squad, inherent from 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 was impacted — as was their life quality.
5 — 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)
Our approach to the problem
To turn things around we knew we had to have mobile developers as an integral parts 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 more developers were hired, they would be allocated in 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.
Having the Mobile Platform Squad responsible for the release of our apps made possible to implement a release train, with releases following their own schedule, independent from 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 are capable of making better decisions, with more predictable results and in a shorter amount of time.
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 weight how they fit within the company’s overall objectives.
It is important to mention that we’re all still adapting to this rule as it comes with its own set of difficulties but we’re already seeing improvements across teams to make sure their code will be in the next release train.
Difficulties we’re facing now
While working as Product Teams has some difficulties, it’s important to highlight the silver lining while teams are getting used to their new composition and workflow.
We work with code reviews using Pull Requests and they are now harder since a PR might not represent the whole discussion behind that change and the tradeoffs made by the developers, specially when the reviewer is in another Squad and wont 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 from 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, 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. An agenda 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 high growth phase? What challenges are you facing and how are you and your company dealing with it?
