Planning and Decision Making with Large Mobile Teams
When you work on a small mobile team with a handful or engineers, or less, you just go and build the new features. You’ll probably discuss decisions with each other, and comment on code reviews, but that’s about it. With a larger team, this process will have to change - both to avoid stepping on each others’ toes, and to keep the code and architecture choices consistent.
Formalizing the planning process is a practice worth introducing above a certain team size. I’ve seen companies do this as early as a few mobile engineers, and ones delaying it until they had 20-30 native engineers. Uber started an RFC planning process this early on, when there were less than a handful of mobile engineers.
You’ll probably want to formalize the specification phase before, or at the same time as the (mobile) engineering planning phase. A large part of project delays come from unclear requirements and scope creep - and being clear on what the business wants to build. This is usually done by product managers starting up a PRD (Product Requirements Document) process, this document being a formal, “you can now start work” step with engineering. See this list as examples on how various companies approach PRDs.
iOS and Android teams working together on planning is such a big win efficiency-wise, and yet a good part of companies keep working in silos. By planning features together, you ensure you’ll both build the same functionality. iOS and Android engineers learn about the differences on the “other” platform. You can standardize things like feature flags, analytic events naming, and, perhaps, even class structure. Engineers can review each others’ code and an iOS engineer might be able to point out an incorrectly implemented business case in the Android code. A win for everyone!
At Uber, one of the major advantages of using RIBs as our architecture is how the structure of the app and components were very similar across iOS and Android. This made shared planning a given: something we just did, without even thinking about it. Why would you not do so?
Decision paralysis is a situation that comes up with teams that start to get good - and thorough - with planning. I’ve observed teams doing thorough analysis of the problem space and alternatives, then delaying making a decision.
I suggest timeboxing planning, and in the end going with the most sensible approach, given the information you gathered. I’ve noticed diminishing returns in spending more time over planning, instead of building in short iterations, and getting feedback if your plans actually work. Especially on mobile, where you can run into tooling and framework issues, shifting to spend time on prototyping can often be more useful than whiteboard additional approaches.
Getting the “signal to noise ratio” right is a problem many teams and companies worry about with planning. Teams are often hesitant that they are working on a new feature, as they don’t want to create too much noise. Executives sometimes worry if their teams can focus on shipping features, if the teams start to broadcasts plans more openly.
I’ve personally only seen downsides of working in silos - at Microsoft, this was the case back in 2014. At Uber, I was surprised to see the “broadcast to all” model work exceptionally well. Whenever a mobile team was about to build a new feature, they sent an “Intent for RFC” summary to a mobile-only RFC mailing list. Almost all of the 300+ mobile engineers at Uber were on this list. Then, once the RFC was ready to review, they emailed this list as well. This process helped catch problems early, it spread knowledge fast - it even helped people decide on moving teams to areas they were more passionate about!
I’ve since advised startups and mid-sized companies on starting a design doc or RFC process. My advice in brief runs like this:
- Define a design doc template for a given stack (e.g. for mobile, backend or web)
- Get most engineers onboard with the idea
- Start writing short docs, and sending it out to everyone, as well as making it clear who the required approvers are
- Overcommunicate rather than under communicate. Prefer lightweight process and tooling to heavyweight ones.
- Observe what happens, and iterate based on the reaction.
If your mobile team is not yet doing planning with lightweight design docs or RFCs: consider giving it a go.
You are reading an early draft from the book Building Mobile Apps at Scale. For the final, expanded and improved content, grab the book now - it's free to download as a PDF until 31 May.
Building Mobile Apps at Scale
"An essential read for anyone working with mobile apps. Not just for mobile engineers - but also on the backend or web teams. The book is full of insights coming from someone who has done engineering at scale."
- Ruj Sabya, formerly Sr Engineering Manager @ Flipkart