Growing your mobile engineering team sustainably while also delivering quality features in your product is a difficult challenge. Adding more engineers onto a project does introduce new problems. How do your development, testing and delivery processes evolve as a team grows? Deniz Veli will share advice and lessons learnt from working on small, medium and large scale mobile engineering teams, including scaling the mobile teams at Etsy and iflix.

1. Scaling Mobile Engineering
Deniz Veli
denizmveli@gmail.com
@denizmveli

2. What do I know?
Worked on small and large apps teams
● Platforms Lead at iflix, Melbourne
● Mobile Engineering Manager at Etsy, NY
● Android Freelancer, Melbourne
● Personal apps

3. Etsy

4. iflix (we’re hiring)

5. Growth.
People. Teams.
Development.
Testing.
Delivery.

6. Growth.
People. Teams.
Development.
Testing.
Delivery.

7. Growth
Why do teams grow?
● Build more features faster
● Expand into new markets
● Integrate/partner - Google, Apple, Facebook, Twitter etc
● As a result you need more help with management,
tooling, testing, delivery and general process stuff
● So you hire more...

8. Growth.
People. Teams.
Development.
Testing.
Delivery.

9. People
● Hiring - it’s hard
○ try to mix your skill levels
○ junior, mid-level & senior
○ provide mentoring opportunities
○ consider diversity not just in experience
○ gender, race, background, age
○ diverse teams consider more perspectives
○ your users aren’t all the same
● Can’t hire fast enough? Training can complement hiring

10. Teams
Web iOS Android Backend
Shared feature / project knowledge
Platform Teams

11. Teams
Feature A Feature B Feature C
Feature Teams / Cross-functional
Feature D
Cross team platform groups

12. Growth.
People. Teams.
Development.
Testing.
Delivery.

13. Development
App development platform - which will scale?
● Webviews?
● Hybrid?
● Native?

14. Development
If you’re growing, aiming for millions of users and great ratings,
go native.
Hybrid
Best of both worlds or best of
neither?
Still not fast enough give a
full native like experience.
Usable in parts but not core
app flow
(want to get featured?)
Webviews
Fast to get started across
platforms, slower for users.
Consistent for the product,
inconsistent with the
platform standards.
Not recommended by
Google / Apple
(want to get featured?)
Native
Slower to build initially but
optimum experience for
users in the end.
Consistent with platform
expectations. Easy hardware
integration
Recommended by
Google / Apple

15. Development
Invest in your apps architecture
● Front end architecture (MVP, MVVM, VIPER, etc)
● Define your app architecture
● Build for testability
○ dependency injection
○ separation of concerns
● Build components where you foresee re-use
● Code reviews / pairing is essential

16. Development
How do you speed up development on multiple native platforms?
Make your apps dumb! Offload logic to the server in you API’s.
● Basic
○ data storage
○ business logic
● Advanced
○ server driven layout
○ configuration and feature toggles

18. Development
More on feature toggles…
● Switching functionality in your app based on a flag - ideally updated remotely
if (featureIsEnabled("show-new-redesign")) {
showNewRedesign();
} else {
showOldDesign();
}
● Enable continuous delivery and A/B testing
● Services - Firebase Remote Config, LaunchDarkly + more
● Cleanup overhead
● Reading - https://martinfowler.com/articles/feature-toggles.html

19. Growth.
People. Teams.
Development.
Testing.
Delivery.

20. Testing
● Testing pyramid
● Lots of unit tests
● Some integration tests
● Fewer manual and end-to-end tests
● Private internal staff testing
● Public beta release groups

21. Growth.
People. Teams
Development.
Testing.
Delivery.

22. Delivery
Feature based delivery
● More people = more code.
● If you don’t release regularly = big releases
○ mammoth testing cycles and increased risk
○ developers are further from the changes made
○ increased mean time to recovery on incidents
○ users go without fixes and improvements

23. Delivery
Continuous Delivery - unused code doesn’t teach you a thing
● Release train = “bug fixes and performance improvements”
● Ship to the app store every 1 - 4 weeks
● Feature toggles = big goals, small steps

24. Delivery
Monitoring
● Crash reporting
● Error logging
● App analytics and tracking
● Performance monitoring
● Respond to customer feedback

25. Easy enough?

26. Hard parts
● Losing control & letting go
● Perfectionists vs pragmatists
● Big changes in the code & app take time
● How big is too big? When does more = less?

27. Where do you start?
You’re growing but don’t know where to start?
● Start thinking server driven and API first
● Deliver your apps regularly to users
● Setup basic feature toggles so you can keep shipping

28. Questions?
Deniz Veli
denizmveli@gmail.com
@denizmveli