Unlocking Efficiency: Transforming Your App Team for Streamlined Success
In my decades-long journey, I’ve witnessed various team configurations in native mobile development, from agencies to full-fledged corporations. While they all worked out in some ways, none truly empowered an independent, streamlined, product-focused, and self-sufficient team. Many companies, especially those not primarily focused on mobile apps, face similar challenges. In this article, I’ll share our experiences, struggles, and successes in forming such a mobile app team.
Before diving into our experiences, it’s crucial to understand two influential concepts: Conway’s Law, which emphasizes the connection between organizational structures and technical architectures; and Metcalfe’s Law, which quantifies the cognitive load increase as teams grow.
Conway’s Law
Conway’s Law suggests that team collaboration and software architecture are interlinked. Organizational setups dictate information flow and, consequently, architecture. While engineers want to design efficient software, they also need to efficiently maintain, adapt, and extend existing software to stay competitive. This requires a lot of communication, meetings, and commitment, which can be challenging with multiple teams having different priorities.
Metcalfe’s Law
Metcalfe’s Law states that the number of unique connections in a network grows exponentially with the number of nodes. High cognitive load due to excessive connections can hamper efficiency. To address this, progressive organizations use decentralized networks of small, autonomous teams to reduce cognitive load.
Please find here a little visualisation (thanks to Nina Winter for spicing up the Metcalfe’s Law Animation!):
To go a bit deeper and understand exactly what too big means when considering team size, you might also want to read about Dunbar’s Number here:
Team Topologies
To address the impact of Conway’s and Metcalfe’s Laws on product teams, Matthew Skelton and Manuel Pais introduced the book Team Topologies. This seminal work offers insights into optimizing organizational structures for maximum efficiency and productivity.
Key Concepts of Team Topologies
Mainly four type of teams and three interaction modes are identified in Team Topologies:
- Stream-aligned teams are product focussed teams; they focus on the main target of the company. All other teams act as support teams, where the ultimate goal is rather enabling than constant support.
- Enabling teams enable stream-aligned teams with specific tasks.
- Complicated subsystem teams, are domain experts and develop and provide domain-specific solutions.
- Platform teams provide existing platforms to the team, and manage the platforms avoiding de-focus of the stream-aligned team.
How do the teams interact?
- Complicated subsystem team is providing the system-as-a-service.
- Platform team is providing the platform-as-service.
- Enabling team enables the stream-aligned team to use a specific technology/service themselves.
The main target is to limit the length of temporary interactions between teams as much as possible and, at the same time, to put absolute focus on the interaction as long as the interaction was required.
Additionally, the roles of the teams interacting are clearly defined. This results in different responsibilities during the interaction.
The length of the interaction of the complicated subsystem team with the stream-aligned team will most probably not end with the introduction and provisioning of the system, but will also require maintenance and further development of this system, resulting in the same interaction length as the platform team.
Now, how do these principles apply to a newly created app team?
App Team Transformation
Initial Setup
Starting with a web team is common for many IT companies. However, when transitioning to native app development, a common pitfall is omitting backend developers from the app team. This forces the app team to constantly collaborate with a separate backend team, creating friction and distractions.
What you need to do native app development? Native app developers! This is how one would do the initial setup:
- Product Owner (maybe shared)
- UI/UX (maybe shared)
- Some iOS and Android engineers
- QA Engineer (or maybe even none)
The initial setup of the app team shows already one flaw: there are NO backend devs part of the team, and it’s extremely rare to find a full-stack mobile native developer…
This means the app team is dependent on the backend developers of a different team on collaborating with them on a constant base to get the data required.
The API Team That Was Not There
This lack of backend developers often leads to the web team unintentionally becoming an “API team,” diluting their focus on the website.
Now you have two teams that can’t work streamlined and independently: not really what you were looking for.
I observed the exact effect like Conway’s Law suggests: the teams try to find technical solutions according to the organizational structure and barriers.
The app team starts to prefer implementing logic twice in both iOS and Android; rather than specifying, requesting, and waiting for the web team to fulfil their needs in the backend.
The web team designs the API according to their existing system, which also results in a lot more transformation logic required in the app clients.
Freelancers Will Fix It
Ok, if the web team can’t help us, then let’s try to scale by money and hire some freelance experts for our backend.
Hiring freelancers for backend work can be a temporary solution but for sure will create dependency issues when they leave.
Who is entitled to take over then?
Most probably the web team will cheer now…
One app to rule them all
To avoid duplicating logic between iOS and Android, cross-platform frameworks like Kotlin Multiplatform Mobile or Flutter can help. However, these frameworks come with their own challenges, and many native developers prefer sticking to their expertise.
Cite from Hendrik Kokocinski, who applied KMM in a real-life production app:
Our iOS developers have evolved from enthusiasm to indifference and resistance, and now towards boycott. The topic is more or less dead among us…
Staffing and maintaining a Flutter team is a challenge, for different reasons: Firstly, there or not many Flutterianians around; but additionally, in most cases, it’s not sufficient to know just Flutter — instead you have to dig into the native Android and iOS world for specific libraries, functions, or errors.
…So you end up staffing a Flutter/iOS/Android native team.
Besides all the possible downsides, the usage of a cross-platform frameworks might be a temporary improvement of the situation.
Cross-platform sounds great… but hey, got an idea! Let’s use web-technologies for apps also, then we even don’t have to staff an app team at all!
Next to native and cross-platform frameworks, there is the hybrid and Progressive Web App approach, based and the same technologies that the web team is using also.
But is this solving our problem?
Not rly…
Besides the additional work and expertise required on the hybrid/PWA assigned-developers, usually you don’t mirror the functionality of the web site in the app, but you enlarge your existing product portfolio with a specialized app use-case.
If you do that, you need a specialized, product-focussed team again, just with a different tech expertise. Furthermore, you are losing the native advantage while competing with other native apps in the App Store, that are focussing an haptics, use of joy, and deep native integration.
Server-Driven UI
Even though we decided against multi-platform for the reasons above, we voted to go with Server-Driven UI (SDUI), to keep us rolling fast!
With the control of the backend business logic by our team, we can shift as much business logic as possible in the backend, avoiding a lot of duplicated code in iOS and Android, hence moving FAST! Additionally, this enables us to switch implementation on server-side only, being instantly visible in the app clients, without required app releases.
See also the chapter Server-driven UI and Dynamic Endpoints in following article:
Team Setup and Qualification
Let’s take a step back, and check the frame conditions we are working in.
We have a team consisting of native app developers for iOS and Android, a product owner, a UI/UX designer, and QA, but… we require a backend to make the apps work and therefore permanently rely on another team.
If the frame conditions do not match the requirements of a streamlined team, then let’s adopt the frame conditions to the team needs!
Ok — then let’s staff a dedicated backend engineer (team)!
Easy call — but in a realistic business context you always have to consider the context you are working in, which limits the budget that you are able to spend on hiring people. At the same time, creating teams with less than four people will not work out, e.g. for velocity, vacation/sickness covering, and recommended minimal team size for agile development.
Creating a third team consisting of at least four backend developers was not a realistic option for us. Hiring just one backend developer and having them form a “one-man-army” dedicated the backend would only work in the movies.
Cross-(cross-)functional Team
We don’t have the budget to staff a full backend crew, but we still require backend experience to form a cross-functional, independent, stream-aligned app team, but how?
Meanwhile in web development, fullstack devs in form of frontend-backend or backend-ops (DevOps) is a common creature — native app developers usually only focus on development in iOS OR Android.
Is it possible to develop the mobile devs to become fullstack?
And what does fullstack mean in our case? Does it stop with app and backend development? Who will run our backend? Are we able of creating a Frankensteinian App-Backend-Ops-Developer?
Expected to be an expert in many highly specialized tech domains often means having no expertise at all.
Asking an app developer to become an overnight expert in two new tech domains at the same time,is a huge stretch… and we haven’t even mentioned ops yet.
Nevertheless, we were convinced that creating an independent, cross-functional team would help us, big time, in achieving our goals. But which path should we take?
So far, we had been focussing on solving our problem on the staffing level; but maybe, if we broaden our horizon and look at persons, qualifications, tools and technologies that we have at hand, we might find a possible way forward.
iOS developers use Swift as a programming language, while Android developers use Java-based Kotlin. Swift is mainly used in iOS or Mac development only, but Kotlin is used in backend development as well; and is compatible out-of-the-box with Java and therefore many backend libraries and frameworks.
Additionally, in backend development the combination of Kotlin and Spring Boot Framework is a very common one, also used in other units of our company, so knowledge exchange was granted. Knowing the language already, and having experts using the same technology at hand, facilitates the adoption of a new tech domain for any Kotlin-native dev.
Creating a cross-functional team with a full-stack developer mentality, is not a self-runner, but requires an active commitment of every team member to personal development and constant learning. In the best case scenario, that personal development is supported by a personal coach and expert in the new domain.
Having the budget granted, we hired an experienced backend developer and briefed her with the mission to:
- take main responsibility for the backend component.
- mentor and coach the Android developers to dive into the world of backend development.
- keep in touch with the other backend teams, whose services we rely on.
It was not an easy call to find the right person, but after some time we were happy to find a candidate, with backend experience, coaching skills and the willingness to take the challenge!
And What About Ops?
Running a backend does not stop at the business logic and the server. There is much more to cover, e.g. monitoring, alerting, patches, security, scaling, infrastructure architecture, cost optimization and more…
We could have tried going for a Platform-as-a-Service (PaaS) like AWS Fargate, but since our internal ops crew MaPS offers a nice shared, managed k8s service, we voted to go with their platform.
Why?
The answer is focus!
There are two concepts pitching in this case:
- We want to move fast and therefore limit the dependencies and do everything we need by ourselves.
- We want to focus on the product and developing features, and the ops management leads us away from the essence of our work.
We neither have the skills in our team nor the budget to hire another ops gunner, so the platform provided sounded like a match.
Ok, interesting. But you lost me a bit there:
What all of this has to do with Team Topologies?
Back to Team Topologies
Reading the book Team Topologies really was an eye-opener for me: it not only described the problems that big corporations face to organize team collaboration, but it also provides best practices how to overcome those hazards.
The collaboration of teams is not only dependent on managerial organization, but also on team self-responsibility and self-understanding:
- Are we identifying ourselves as stream-, enabling- or platform-team, and… are we happy with this role?
As mentioned above, my takeaway from Team Topologies is that you should focus on product, the product team, and the product team’s independence to allow stream-aligned teams to move fast and efficiently.
In this article, I described our path — and our struggles on that path — of agile adoption of the app team’s organization, with the target to achieve fast flow under the circumstances and opportunities given.
By adopting our app team’s organizational structure, we are also shaping the type of product/software being developed and the value being delivered.
The options of transforming the findings in Team Topologies into a concrete organization are dependent upon your specific context and budget:
- How much focus is possible for your team?
- How can I optimize the focus of teams to boost the team velocity on product-focussed feature development?
- How much value does this team’s product have in the company’s product portfolio, and hence how much budget do I have available to form the optimal stream-aligned team and efficient team collaborations?
- Are the solutions suggested by Team Topologies matching our situation?
The answers to those questions depend strongly on your environment, and might even change along the way… because nothing is constant!
The last setup described works very well for us at present, even though there is always room for improvement. We are eager to adopt for future challenges and constantly optimize for fast flow!
Our current challenge is to establish a working on-call duty, and enabling the full team to address the main issues expected with our backend… but we are looking forward to tackle this challenge — with the support of our company’s enabling team MaPS, specialized in ops!
By the way: Greetings to our Ops-BEAST :)
I hope you feel inspired by our journey and, being part of an app team, you might also see similarities in your current team setup.
Let me know about your solutions, setup or struggles: I am always open for exchange and happy to learn from others experiences!
If you are interested in different setups for native app teams, please read on:
