Mobile Team Setup Within Tech Organization

My career started 10 years ago as a software engineer. In my first year I was working as a web-developer and by accident moved to mobile, which leaves me with 8 years of Android development and one year of Engineering Manager experience.

I moved through different companies and roles until I eventually joined Scout24 as an Android Engineer. After a year as an Engineer I became the Engineering Manager for the team — and this is where the fun began. And by fun I mean getting my head out of the sand and actually being able to form a bigger picture and overview of how the team is working and contributing to our company’s success.

Through the years I experienced companies being truly mobile focused — some starting their Mobile First journey and some considering mobile apps as just extra feature to an already existing Web and Mobile-Web experience. And of course, these strategies, and others, fully depend upon your company’s purpose, who your customers/consumers are and how you earn money.

Cross-Platform Product Teams

Many companies nowadays are using the following feature/product team setup:

Figure 1

As you can see in the diagram, I put Front-End and Mobile Engineers together. This makes sense if the team is working on a product/features which are available on both Web and Mobile apps and work is done either in parallel or within a reasonable time frame.

From my experience this is beneficial because:

• All product features are exposed to a more diverse group of engineers (the benefits of which you can find in many posts about diversity at workplace)
• The Product Manager is making Mobile a first class citizen in the company strategy
• Better feature parity across the platforms

But there are also a few things to watch out:

• If team consists of only few (1–2) engineers per platform, they might be missing out on pair programming (cross-platform pair programming would be a solution, but it’s time consuming)
• If there is no constant engineer rotation between the teams within the platform, there is the danger of losing knowledge when engineer is away
• The Product Manager has to cover many platforms and constantly learn about new possibilities on each of them
• There should be defined direction for Mobile apps in the company and everyone should be aligned on it. Mobile apps are different from many other services (at least for now) as they are perceived as one whole piece by the user. You need to make sure that all the products within the company are built with those guidelines and best practices in mind
• Another thing worth mentioning is growth opportunity. Very often, for cross-platform teams, a company strives to hire Senior Engineers (they have more knowledge and can work alone while delivering great results). With all mobile engineers spread in different teams, you end up having a lot of Senior Engineers with no opportunity to grow.

Mobile Product Team

At ImmobilienScout24 we have one dedicated mobile team split into 2 squads. Each squad focuses on one aspect of the product or towards achieving a change in a key metric. What the squads focus on is determined by company priorities.

Each of the squads has a similar team structure:

Figure 2

Android and iOS Engineering Managers are shared between both squads at all the times. They also participate in squad ceremonies to get an overview of the topics and provide support if help is needed.

Pros of one dedicated mobile team (which can consist of few squads/sub-teams):

• Full ownership of mobile apps (performance, user feedback, app size)
• Product Manager(s) are Mobile-centered
• Continuous discovery of mobile platforms possibilities
• Team has an overview of all Mobile app features
• Easier prioritization of Mobile topics
• Dynamic resource allocation based on priorities (every engineer has deep knowledge about the app and can easily switch between different features)

Cons:

• All requests for changes in the apps are coming through the mobile team
• A lot of topics for only few Product Managers
• Features are not owned end to end
• Frequent alignment with other teams is a must
• Gap between Web and Mobile

Android App development in our company

Who contributes to our Android App? Mobile team solely? No. We have a mix of both team setups. While the Mobile team is the biggest contributor to Android App, we have Full-stack Product Teams (see Figure 1) in our organization, some of which contain dedicated Android engineers.

All Android Engineers in our company are part of Android Core Team. While product work is handled by different teams, Android core work lays on every single Android App contributor. This includes:

• Releasing the App
• Investigating and introducing new libraries, frameworks, etc.
• Fixing non-product related bugs
• Modularization
• Sharing knowledge with other team members (Dev Talks and Katas)

We also meet several times a week to:

• Give an update on what are current products in Android app engineers are working on
• Give an update on our latest release, if there are any new issues
• Update on Core Platform Work
• Discuss if we want to try new library/framework/architecture
• Discuss/Improve Android app development guidelines
• Talk about new approaches/Learn new things as a team
• Have lunch together
• Joke around about Donut (or Doughnut) chart and many other things

All these points are very important, not just for team alignment and bonding, but also because this way each Android Engineer has ownership over our Android App.

Of course, you could think of dedicated Core (Mobile) Team to handle described above topics, and Android contributors would be only accountable for the features they work on, but later on there would be other issues to handle inside the Core Team:

• Engineers would most probably fall into communication rabbit-hole trying to find out who is responsible for what
• Monotone and possibly boring work, which is cleaning after others
• Lack of recognition

How would I arrange Android Engineers within the company?

There are many factors that play into arranging the mobile teams. What I really like in our Mobile Android Team setup is continuous rotation between the topics. Every new quarter(cycle) we decide who is going to work in which squad and on which topics. This way all engineers:

• are constantly improving knowledge about our codebase and features
• work directly with other Android engineer’s code (not only PR reviews)
• bring their knowledge and ideas to different products
• do a lot of pair-programming

But having only one dedicated Mobile team results in less visibility and attention to Mobile Apps within the company. This can be nice for introverts, but not for business. On the other hand, having Cross-Platform teams will likely cause inconsistence in apps, complicated process of resource allocation and little growth opportunities.

From my experience I would rather go for dedicated Mobile Team(s) with knowledgeable Product Managers and concentrate on communication part within the company: showing opportunities for business value in mobile and pro-actively demonstrating achievements, this would in turn encourage other teams to collaborate on Mobile apps with your team.

Those are my thoughts and I am looking forward to getting feedback and other opinions on how things should be running. Thanks for reading!