This message was deleted.

@Schuyler Bishop weren't you speaking about this?

I’m going to give the former-Thoughtworks-consultant answer: it depends. If you’re early in your maturity process as an internal platform, you’ll need a higher ratio because you have little automation, likely a lot of toil and debt. As you grow your self-service platform your toil and debt should be decreasing (you are focusing on toil and debt reduction, right???) so then your ratios should decrease. I refer to this as “sub-linear scaling” with a twist.

Ah perfect timing 😄

We serve 60 engineers with 6 total people currently but we’re under-sized since we’re early in our process. • Leader/manager • TPM • Staff Eng • Eng x 3 Also given our size, both myself and the manager of the team do support and code - but I wouldn’t suggest that for long 🙂

My spoke was on my experience scaling a platform team from serving 15 engineers to 200+. As I planned the talk, I was surprised to plot the team size against that growth. I’ve attached a table from my notes. The “platform count” ends up being split into relevant teams, with: • CI: Core Infrastructure, SREs providing production tools • DI: Data Infrastructure, data estate and BigQuery management • DE: Developer Enablement, dev tools and productivity It’s kinda surprising that CI needed 4 people for a 40 eng org headcount, and 7 for 200.

I seem to be at the opposite end of that slightly, with a substantial percentage of all developers being in Platform Tribe (Company size is ~500). I notice that we're geared slightly different though - with less emphasis on infrastructure but also encompass "internal products" (billing engine, audit logging, abstraction APIs, token factory (OIDC server) et. al.

At Walmart when I left, we had about 80 people in the CD platform area building and supporting, CI, orchestration, delivery metrics, code gating, docs & training, and a few other platform capability teams. That number includes developers, support, and management. We supported ~18,500 developers. I’d grow it the same as I would any other product suite. Stand up small product teams for the first set of capabilities and grow from there. Optimize for scaling of support with good docs, good DX in the platform, and good customer service. I talk about some of this in my talk.

So that would translate to an "infrastructure focused team" more than "developing internal products team"?

Agree Bryan - my previous org was ~75 engineers serving 500 sw eng. The 75 was pretty evenly divided across five domains: • CI/CD and devex • Runtime (k8s) • Security • Cloud • Events (kafka)

Our CD platform teams were doing product development. Looper: CI product. Abstraction of Jenkins to provide extensible, declarative CI templates. Concord: concord.walmartlabs.com: Our orchestration engine for the pipeline Sentinel: security and compliance gating Insights: pipeline metrics etc.