Hello everyone,
If you were unable to attend the live event, here’s the recording.
As promised during the event, we captured all the unanswered questions and Gergely has graciously answered them all:
Q. How do you evaluate a value of a feature? How do you know, how much $ does it bring?
A. At Uber, I’d never start a project without having an estimation of its value. We did this by having a few well-understood goals we wanted to move (e.g. for my group this was incremental revenue/year, cost savings/year, reliability increase %, engineering time saved in eng weeks or months and so on.)
Typically, PMs would help define these metrics. For features, they’d work with the data team to bring estimations on what range we’d expect (e.g. $1M-5M in incremental revenue estimated).
Then, after we ship, we’d measure the impact and compare. Of course, your estimates will never be perfect, but that’s not the point. Knowing what metric you’re impacting (or wanting to impact), then learning after your rollout how it worked made a massive difference.
I strongly believe every project/feature should have an estimated impact, before you work on it. Otherwise, how can you tell if it’s worth spending time on it?
Q. Is there anything that’s done on the larger teams (30-100, 100+), that you think would be beneficial for smaller teams (1-3, 3-10, 10-30)?
A. Participate in the community (e.g. present at meetups or talks) if you can! This is great for the people involved (helps you practice speaking skills/gets your name out in the community), the team, and the company. Many teams or companies think “oh, but we don’t have anything interesting to talk about, or at least not as much as {Big company}”. You’d be surprised 
Q. When building mobile apps, do you recommend delegating any business logic to a mobile backend such as a GraphQL API even though you would need to hire backend engineers?
A. The more logic you can move to the backend - without impacting the user experience - the easier you’ll be able to rapidly modify your app. You don’t want more business logic on the app than necessary (which is usually still a lot).
I’m a huge fan of moving everything you can to the backend and yes, of course, you need to hire backend engineers. Reality is more nuanced.
GraphQL is an implementation detail: you can use anything else, from JSON to things like Thrift APIs (we used it at Uber). Also, the more of a backend you have, the more things like versioning endpoints, and a resilient client-side implementation become important.
Q. How long is the longest build time ever happen in Uber and how is the latest condition? What is considered normal & good for day-to-day development?
A. Right now the goal is for engineers to merge a change into the main branch in 30 minutes. This gets very challenging with hundreds of engineers working on a codebase… but it’s around that time. I remember builds being as high as 40-50 minutes and multiple tires to get to merge (due to conflicts) in 2016. Since then the Developer Experience team tracks average, min, max build times. Some background on how they made it work: Engineering Blog | Uber Blog
Q. As career advice to mobile developers, would you recommend joining a company with a larger scale team?
A. There are a lot fewer of these places in the industry, so if you join, you learn insights and practices fewer people have. For example, you’ll almost certainly work with mobile platform teams, have to learn how to convince tens of mobile engineers about your idea (or see how others do it), and see first-hand how these teams ship (relatively) fast with so many moving parts. So: yes!
Q. What was the tech stack that scaled the app to millions of users?
A. Most if it is still similar to these: The Uber Engineering Tech Stack, Part I: The Foundation | Uber Blog and The Uber Engineering Tech Stack, Part II: The Edge and Beyond | Uber Blog The backend changed more than the frontend (moved to Go and Java from NodeJS and Python). Backend-mobile comms layer is Thrift.
Q. Out of topic; when is the big salary metrics blog coming out?
A. It will be a site, not a blog! I’m working on it most of my time for 1.5 months now. Here’s progress: https://twitter.com/GergelyOrosz/status/1419011931080380423?s=20. The first version hopefully in August!
Q. What is your most important advice for upcoming developers?
A. I wrote about this exact thing: Advice to Myself When Starting Out as a Software Developer - The Pragmatic Engineer
Q. Hi Gergely, thanks for the session. Can you tell me more about feature teams? In my setup, we have a platform backend team and few product teams but I noticed there is always a communication gap: usually when a product team wants to test a feature, the platform team builds a full-blown solution.
A. That’s the usual setup, but the devil is in the details. Both teams would have their own roadmap, and the platform team would typically not build full-blown solutions, but own common stuff (from infra through code governance etc). I write more about mobile platform teams both in Building Mobile Apps at Scale, and about how feature and platform teams worked at Uber in Growing as a Mobile Engineer Mobile Apps at Scale: 39 Engineering Challenges
Q. With such an Uber large team, you mentioned breaking devs into smaller ‘feature teams’. Does this mean multiple teams are working in every level of the codebase ( networking and data all the way up to UI), or were teams broken into technical sections of the app? If not, what lessons were learned keeping so many teams in sync with design patterns at every level of the code base?
A. We called “feature” teams program teams at Uber. They owned an experience and everything they needed for it. However, e.g. at Uber, the mobile platform team owned networking, experimentation and many other common libraries these teams owned. The program team would plan, build, ship, measure, own their features or parts of the app. I wrote more about mobile feature teams at Uber in Growing as a Mobile Engineer Mobile Apps at Scale: 39 Engineering Challenges
We designed our architecture (RIBs) to allow separation between teams, not stepping on each other’s toes. GitHub - uber/RIBs: Uber's cross-platform mobile architecture framework.
Q. Could you tell more about the development process which you adopted? What kind of agile framework, how long were the iterations, how PRs and code reviews were organized?
A. At Uber, we didn’t do agile. Each team worked in its own way. We released every week. PRs and code reviews… we always did these. We had the concept of blocking code reviews where teams could assign themselves owners of a certain code part but had to do code reviews within a business day at most.
Here’s some reading about how my teams worked: An Engineering Team where Everyone is a Leader - The Pragmatic Engineer and on project management: Efficient Software Project Management at its Roots - The Pragmatic Engineer
Q. What about the quality in the development process, not only in testing?
A. We had linting, static analysis, unit tests part of the development process. I write a lot more about automated and manual testing in Building Mobile Apps at Scale.
Q. At Uber how often would you use A/B testing?
A. We called it experimentation and used it for everything. Check out the Experimentation chapter in Building Mobile Apps at Scale for more details.
Q. How did engineering work with product & design? How did you guys know what to build next?
A. Product worked with design, “planning” ahead, and pulling in engineering, when needed. Product produced a spec (a Product Requirement Document - PRD) and we started a project with a kickoff based on this, once the whole team read it. We clarified questions on the kickoff, and them worked directly with designers and PMs. Worked pretty well!
Q. What do you use on DevOps processes? Could you prefer to create your own line in local system maybe Azure DevOps or Jenkins etc. or do you choose cloud base(ready to use ci & cd pipeline for app store etc.) solutions?
A. Uber build our own CI/CD thanks to our scale. Vendors like Buildkite are good when owning your own infra, or Bitrise and others for not needing to maintain it yourself. Building Mobile Apps at Scale has a whole chapter on CI/CD: suggest you check it out!
Q. How do you keep yourself motivated (if maybe feeling down/exhausted) and still keep going throughout the project?
A. This question is too big for a simple answer It’s much easier if you have a supportive team, manager, and you’re not working alone, but it feels you’re doing it with others. They can pull you up when you’re down, and you can do the same. And, especially with remote work/COVID: taking breaks and time to recharge is also something I find (to be) key.
Q. At which stage does the company need to establish an approach to innovations? Any advice on building an in-house innovation process?
A. The best way to innovate is to give slack room for teams. If you push people to ship, ship, ship, innovation won’t happen on command. This means having an environment where there is time/space for the team to sometimes work on stuff not directly related to what the business gives them. Having a place that innovates is both hard to create, and maintain, but the companies who do it really do thrive.
A lot of companies organize a week-long hackathon and then are surprised there’s not much innovation.
The best thing any company can do - but many fail to figure out how - is give autonomy to software engineers. Here are more thoughts on this: What Silicon Valley "Gets" about Software Engineers that Traditional Companies Do Not - The Pragmatic Engineer
Much thanks and 
to everyone that participated. 
