What would an Uber Engineering Manager do? Part 1

This is the first blog in a two-part series titled, What Would an Uber Engineering Manager Do? You can click here to read part 2. 

In May, we hosted a webinar featuring Gergely Orosz, author and former Uber Engineering Manager. He talked about his experience at Uber building their flagship mobile app, mainly the key challenges and lessons learned as they scaled from a small engineering team to an organization of over 100 engineers. You can watch the full on-demand webinar here.

After an exciting presentation, our webinar attendees flooded the chat with questions about everything from software tool recommendations to team management advice. Their insightful questions were matched with insightful responses from Gergely and his colleague Abhijith Krishnappa, Software Engineer at Halodoc, who dialed in for the Q&A. We would like to share those questions and responses with you in a two-part blog we’ve titled, What Would an Uber Engineering Manager Do?
‍

Q: How was the release process once the Uber app was modularized? I mean, did features have their own versioning and releasing agenda apart from the main binary release?

A: [Gergely] The release process did not change. Uber moved to an iOS monorepo late 2016 that meant that there were no versions: everything used the “latest” versions of modules. In the medium- and long-term, this worked great. When the monorepo was introduced, it was painful, as it was for each breaking change.

Q: Since we just saw updates at WWDC, I am curious about how you plan to incorporate the new updates and how you decide which ones to incorporate?

A: [Gergely] This is always case-by-case. At Uber, many iOS engineers would watch WWDC live, and then brainstorm with the team on what features to add. We’d prioritize user-facing features. For developer features, we’d proceed with caution, usually just leaving it to prototyping, given these features are often unstable (see: SwiftUI introduction).

A: [Abhijith] Usually new features are added to the App Modernization backlog. There will usually be discussion with the product team to make them aware of these features. Post that as and when the need arises we will be picking it up.

Q: Is server-driven UI a good approach to avoid the store’s approval on release?

A: [Gergely] Yes, it’s an approach. It comes with downsides of reinventing the wheel, worrying about backwards compatibility and a bunch of other things. There’s a chapter in this in Mobile Apps at Scale.

Q: Can you tell us more about “feature teams” vs “platform teams” in terms of duties and responsibilities?

A: [Gergely] Feature teams own an experience. Their customers are end-users (e.g. app users or other stakeholders). Platform teams own “building blocks”. Their customers are mobile feature teams. Typical platform team ownership includes the release process, shared mobile components, architecture and code governance, and so on. I write more about platform teams in Mobile Apps at Scale and in Growing as a Mobile Engineer.

A: [Abhijith] We had a platform team in Halodoc as well. Had written more on this: Site reliability engineering for native mobile apps

Q: At what point did you add localization and accessibility, and do you have one platform for localization, or separate ones for Android/iOS/web?

A: [Gergely] At Uber, we added both very early on, as Uber expanded to France in year 2, I recall. We had a team who did the localization, and an in-house platform we used (there’s good vendors in this space now). Feature teams owned all their localization & accessibility. We had occasional localization reviews. Mobile Apps at Scale has chapters on both topics.

Q: Solo developer trying to manage it all. Any advice?

A: [Gergely] If it’s beyond a trivial app, you’ll need help sooner or later. Make a business case for bringing on more people. Does the app generate enough revenue to do so? If not, is there even a business case to have an app?