Hi all - new to this group. Heading up Technical Prog Mgmt for our IDP at Ford Motor Company. We've finished our MVP and actually have our first production workload now running, with sizable services onboarding in the next 12 mos. My question - do you have tips/suggestions for how to plan engineering team sizes for building/supporting/maintaining IDP's. We have some bottoms-up sizings based on the work we can see in our roadmap, but was curious about team sizes and the ratio of customers/services those team sizes support. Thanks!!

A lot of the work y'all have done over the years around cloud foundry teams is applicable to your developer platform efforts. Do you have contacts in those parts of the Ford organization?

We are considering separating teams by capability. E.g. the data team looks after data services, the ci/cd & automation team, looks after CI/CD & GitOps services, tooling team looks after developer tooling, etc. You then have a core team that looks after the idp, kubernetes, tieing the entire thing together. Each engineering contains roughly 8 engineers. For every two engineering teams, we have one Technical Product Owner who owns the roadmap for their teams’ services.

@Bill Anderson if you have a central team/s managing the platform, I would suggest the '2 pizza team' approach, so you're probably talking 5-8 people max, and then scale horizontally depending on how much throughput you need. Its obviously key to have good feedback mechanisms in place in order to understand the user experience and best prioritise the work you are doing.

Just want to throw in one point here when it comes to potential team size - the most important detail, in my view more than any other, is that the platform team should scale non-linearly Otherwise, you’re in the same ops trap where as your platform serves 10x the developers, you need 10x the platform engineers. Recent platform I was demo’d had 30 PEs serving 600 developers. The most important thing is that if they doubled to 1200 developers. They would not need to double the PE team to 60. Obv this is easier said than done, but it’s why it’s usually better to gradually scale up over time. Don’t go from MVP with 1 team, to 100 teams in one swoop. Gradually roll out, and use that to gauge you’ve got the non-linear scaling down. It’s better to move slower and take some time to be sure how you’ll scale - rather than race to onboard as many people as possible, as fast as possible.

Thanks all!

In EY, we have an internal platform that serves 75k developers today, with a platform team of 800 - 1000 folks.