'At which point do you need a platform team?' and other audience questions answered

If you who joined our Building Mobile Apps At Scale webinar last week, you know how fascinating it was to hear Gergely Orosz’s journey at Uber, and how their mobile team responded to the engineering and scaling challenges. 

If you didn't have the chance to join, you can still watch the full recording here.

This is the second part of a series of blog posts summarizing the Q&A part of the webinar, where Gergely was joined by GDE Pooja Bhaumik, Coding Mentor at MentorCruise and Startup Clinic initiative by Google For Startups; and Franz Busch, Staff Software Engineer at Sixt who responded to a wide range of questions. You can read the first summary article here. 

This first part focuses on questions surrounding building engineering teams and culture. Coming separately later, we’ll examine refactoring vs rebuilding.

Today we’ll be answering:

• What would be your killer argument to stakeholders for a platform team in traditional (non-tech) companies where we hit 15 mobile engineers per platform? 
• At which point do you need to have a platform team?
• Could you give some specific examples of what a platform team does? What kind of products/services would a team use instead of building their own platform teams?
• If your org has multiple apps, do you see the platform team specific to an app product, shared capability, or both?
• Can feature teams share tasks with the platform team? Are there examples where organizations were able to operate and scale without a platform team?
• Can you elaborate a bit on the importance of having platform teams while building scalable apps and about the scope of the responsibilities for platform teams?
• What is your strategy for dealing with technical debt when you have multiple feature teams trying to continually ship features quickly?
• What are some good ways of building discipline in paying off tech debt on a regular basis in a team that focuses heavily on adding features?
• It's so frequent to see a company get to a certain size and become a market leader and then slowing down and eventually getting disrupted by a new competitor. How can this situation be avoided in your opinion? 
• Can you share some best practices for onboarding new developers quickly, or producing documentation as the engineering team’s size starts to grow?
• When hiring a mid-level engineer what are the top 5 things you look for? Can you share some examples of working with the best engineers and what was it that made them great?
• Would you let the different feature teams are entirely independent, or if not, how would you align the teams on different best practices and similar designs?
• How can code reviews be done in feature teams if you don’t have enough people per platform in each team?
• How do you avoid or limit people over-engineering? It sounds like an individual thing but what if it’s supported by some of the older employees?
• What’s your take on structuring teams — cross-functional (Android & iOS) versus split per domain?

Platform teams

1. What would be your killer argument to stakeholders for a platform team in traditional (non-tech) companies where we hit 15 mobile engineers per platform? How can the idea of not working on features be sold?
2. At which point you need to have a platform team?
   

Franz: I've been doing that founding of the platform team at Sixt now. I think it's a hard decision. So let's talk about at what size it makes sense. I think for mobile teams, probably per platform, it can already make sense when you have five engineers, right? Because there's a lot of things the platform team can take care of. With 10-15 engineers, I would say it’s a must to have a platform team to help the others unclog, from actually working on feature development and not on the platform stuff. 

And how to actually convince businesses to form a platform team is very tricky. What I did back in the days was that I came up with a list of topics a platform team could cover, and then prioritize them. Because when I was founding it, I was alone so I couldn't take 10-15 topics right away — I was focusing on the highest priority ones. 

But the thing is, I think you really, really have to write down what are the things you're doing. And I think the first one is probably CI/CD, and then you're going to focus on architecture and developer performance. You also need to write down how much time you’re wasting on your pain points, just do a rough calculation, how much time engineers are wasting every day on these things.

How much time will you save them, and then it's a way easier estimation. I would guarantee that in 95% of the cases, it's a net positive time calculation for the company. This is what helped us in a semi-tech company Sixt, right to get that platform team going. 

Gergely: If you're interested in platform teams, my short advice is, first of all, it will take a long time — a lot longer than you think. Second of all, you need your manager and your manager’s manager, to agree on this, you actually need to talk to them and convince them. No paper, no document will do the trick, if they're not in the mindset, you know, it’s going to be tough. 

And it does help now there are a lot more resources, the books like ‘Team topologies: Organizing business and technology teams for fast flow’. I write a lot about this. You can use Uber as an example. Uber, does a platform team. I talked with the VP of engineering, who created the first platform team with five engineers — they invested very early. 

It's tough. Productivity is not good without it. And almost all companies I know, not tech first, like travel companies whatnot, around 15-20. They just bite the bullet, do a platform team with two engineers or so, and it kind of starts to grow from there. 

‍

3. Could you give some specific examples of what a platform team does? What kind of products/services would a team use instead of building their own platform teams?

Gergely: See my thoughts on platform teams here, and in the Platform Teams section in Building Mobile Apps at Scale. 

‍

4. If your org has multiple apps, do you see the platform team specific to an app product, shared capability, or both?
   

Gergely: At Uber, platform teams owned shared capabilities, libraries, and challenges. You can read more about them here and in the Mobile Platform teams article."

‍

5. Can feature teams share tasks with the platform team? Are there examples where organizations were able to operate and scale without a platform team?

Gergely: It's all down to what you're building. If a feature team can help the platform team, they should! Platform teams should enable other teams to move faster, but feature teams should not wait on platform teams. I don’t know of any mobile engineering team that has more than 40 mobile engineers working on an app and has no platform team. Most I talk to wish they would have invested earlier.

See my thoughts on platform teams here, and in the Platform Teams section in Building Mobile Apps at Scale. 

6. Can you elaborate a bit on the importance of having platform teams while building scalable apps (especially when dealing with tech debt) and about the scope of the responsibilities for platform teams?
   

Franz:  I think as we mentioned, it's invaluable to have a platform team at some point, because otherwise all of your engineers need to maintain these different things and they can't get the knowledge for that. They need to focus on their product, on their features, on their customers, what they need to deliver there. 

So at some point, you really need to have it. The scale of a platform team can be as large as you want. As it happens in larger companies like Uber, the platform team actually gets split down into different sub-teams, focusing on different areas: one team focuses on CI/CD, the whole pipeline, but also on the infrastructure required for it. 

The other teams focus on the developer experience and build systems for that, using basil or buck or whatever is out there to have great performance. The next team is focusing on the core libraries for networking, persistence, co-generation, all of the things that are needed there. 

Another part is focusing on designing systems so that the user experience across the episodes is the same. For our platform team at Sixt, we had around 20 to 30 core libraries that the platform team was owning, ranging across various things. We were only tooling the build system, the infrastructure team, and I think if we’d grow a bit more now, we’d have to really split up the team to focus on what is actually needed. And not everybody in the platform team needs to know everything a platform team is owning because that can be overwhelming as well.

Tech debt

7. What is your strategy for dealing with technical debt when you have multiple feature teams trying to continually ship features quickly?
8. What are some good ways of building discipline in paying off tech debt on a regular basis in a team that focuses heavily on adding features?

Gergely: I would take the following steps: 

1. Make a list of all the tech debt you have.

2. Assign an "impact" against it. What would happen if you did nothing, and what happens if you remove it?

3. Can you "couple" some of this tech debt work to build new stuff?

4. Spend about 20% of your capacity paying down the highest prioritized tech debt or the best "band for the buck".

9. It's so frequent to see a company get to a certain size and become a market leader (or at least one of the market leaders) and then slowing down and eventually getting disrupted by a new competitor. How can this situation be avoided in your opinion? I think Microsoft might have just avoided this fate, so maybe Gergely can share some insights on how this was done since he worked there.
   

Gergely: You keep teams small, boundaries clear, and make it easy for these teams to ship fast. This is where platform teams are enabling other teams to move fast come to play. Also, look at Facebook, Amazon, and Apple on how they keep moving so fast. They keep their teams small. I'd argue Microsoft is also moving fast. They built an equivalent of Notion in probably less than a year, and an equivalent of Slack (Teams) rapidly. Teams has more customers than Slack, so I would think they succeeded there.

Onboarding and hiring

10. Can you share some best practices for onboarding new developers quickly, or producing and updating documentation as the engineering team’s size starts to grow?
    

Gergely: I recently wrote an article about onboarding. In short, the more you write down, the better. You need to keep it updated as well: this is a challenge for everyone. A strong writing culture from day one in a team or company makes a huge difference.

Franz: When you have new developers on board, they are not really up to date with the decisions made in the team or the architecture decisions or like what the structure should be like. And obviously, the documentation is going to be the starting point for these new developers. 

And yet, in a lot of teams, they do not focus on documentation, a lot like in especially smaller teams, where documentation is probably not updated throughout the decisions when the decisions are like changing throughout the course of the product building, documentation is probably not updated. And that definitely hampers the growth of these new developers on the team. I think a mentality change is what we need to have in some of these teams where we need to keep on changing the documentation, making it up to date. 

But also, when these new developers come, they probably need to have a mentor, buddy, or a senior engineer who could mentor them around. Because yes, you can read the documentation and learn things and understand the code base, but you probably don't understand a lot about how the decisions were made. Junior developers will stumble upon a lot of questions. And if they do not have a dedicated person to talk to, they might end up as a liability in your team in the beginning.  And that's something that you probably would not want in the beginning. 

And one thing that really helps is having pair-coding sessions with people who are actually building the features. The new developers can definitely join them in these pair-coding sessions and see how the feature is being written. And that's where they will have a lot of questions and where they will understand the thought process of the engineers in the team. 

And that is where they can get onboarded as well. It may not work in a very large team because involving so many people when there's just not enough time for the sessions. But I think you could also do it during office hours, where you basically open a specific time slot for the new joiners to get started with the codebase, that could help them get started.

11.  When hiring a mid-level engineer what are the top 5 things you look for?  Can you share some examples of working with the best engineers and what was it that made them great?

Gergely: This is highly dependent on the company and what they expect from engineers. Most companies have internal competencies. I wrote an article about some of the most important qualities in an engineer, based on some of the best engineers I worked with. 

For mid-level engineers, expectations are usually:

• Software engineering: knows of and follows engineering best practices to write maintainable code.
• Execution: gets things done. Completes somewhat complex projects without needing much guidance. Unblocks themselves.
• Collaboration: works well with others, across disciplines.
• Architecture: is aware of architecture approaches and tries to design their work so it's extensible or reusable.

Sharing the workload

12. Would you let the different feature teams be entirely independent, or if not, how would you align the teams on different best practices and similar designs?

Gergely: I would optimize for the ability to move fast. I'd keep teams as independent as possible, while the platform teams would enable them by taking the time-consuming work — or work that should be done but none of the feature teams has the time.

13. How can code reviews be done in feature teams if you don’t have enough people per platform in each team (imagine 1-2 developers per platform for a feature)?

Gergely: I've seen either code reviews across the "other side" (e.g. iOS and Android), or mobile engineers working across features reviewing each others' code.

14. How do you avoid or limit people over-engineering? It sounds like an individual thing but what if it’s supported by some of the older employees?

Gergely: It depends on your code structure. Usually, when you have a really tightly coupled thing, like what we had in the old days where we had this file with 5000 lines of massive presenter. It wasn't really over-engineering, but we were just stepping on each other's toes. And then we put in place a super opinionated architecture that was a lot of immutable states, a lot of separation. It was really difficult to accidentally modify things. 

And because we were so opinionated, people didn't really over-engineer but our problem was that it was just too opinionated for a few people. The other thing is I do believe in ownership. Just give teams ownership if they want to over-engineer, just have them own it — if it doesn't hurt the code. 

If you have some sort of central governance team, that’s helpful. I’m really wary of governance teams, like platform teams who try to shut people or teams down — you should really be supporting them. In short, I wouldn't see it as a massive problem, as long as it's just their own thing. If it's impacting everyone, well, that's a big problem, then you’d want to talk with them and figure out what's going on.

Franz: Yeah, I think I think you hit the nail on the head. I think it's always a discussion on what layer you're over-engineering. On some parts, especially talking about platform teams, I think it's important to spend a lot of time engineering the basic foundational blocks of application the right way: networking, persistence design system, these kinds of things need to be engineered very well so that they have great APIs.

If you do feature development, and this is not the central feature that's making 95% of your revenue, I think you should be quick, get it out to the market. Don't over-engineer it. You can refactor later on. But you always need to wait, where does it make sense to spend more time and where not. I think this proposal process that Gergely was mentioning, also helps a lot in actually thinking within the company. But this is networking, it needs to be very solid. The platform team needs to help them to develop it the right way. But the teams own it and they can do whatever they want, as long as they're not breaking the overall project guidelines. 

Pooja Bhaumik: Yeah, absolutely. I agree with the fact that for a lot of people, this is about obedience in a way. Maybe it's a very simple problem yet, some people just want to try out over-engineering to make sure that everything goes well. What we want from them is not just to ship it early, like what Franz said, but to spend more time on making sure it's perfect. But it does not work in certain scenarios, like when we have to ship probably the next week, for example.

And when we are refactoring as well, we can have those in a week, so we can refactor them in a better way. But people just want to do it perfectly the first time. So those kinds of scenarios are probably dependent on the developer. Some developers like to just get it done and they can refactor later. Some people want it to be perfect for the first time. It also depends on how early you want the feature out, on the timelines as well.

15. ​​What’s your take on structuring teams — cross-functional (Android & iOS) versus split per domain?

Gergely: At Uber, we went by cross-functional in all cases.