https://platformengineering.org logo
#platform-stories
Title
# platform-stories
j

Jon Skarpeteig

06/09/2022, 11:38 AM
Are there any good references to how to size the platform group within a company? Maturity, company profile, business domain?
👀 3
l

Luca Galante

06/09/2022, 11:41 AM
@Schuyler Bishop weren't you speaking about this?
💯 1
s

Schuyler Bishop

06/09/2022, 11:42 AM
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.
l

Luca Galante

06/09/2022, 11:42 AM
Ah perfect timing 😄
s

Schuyler Bishop

06/09/2022, 11:43 AM
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 🙂
l

Lawrence Jones

06/09/2022, 11:51 AM
My

talk

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.
j

Jon Skarpeteig

06/09/2022, 11:58 AM
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.
Being the Platform Tribe lead it's great having resources to accomplish a lot - but it also makes me vary to attempt to counter the "internal focus" considering our relatively large footprint in the organization
b

Bryan Finster

06/09/2022, 12:11 PM
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.
CD Platform was a subset of the entire platform area though since that covered all of the infrastructure for on-prem, private cloud, and public cloud + DB and all of the other enabling tech.
j

Jon Skarpeteig

06/09/2022, 12:13 PM
So that would translate to an "infrastructure focused team" more than "developing internal products team"?
s

Schuyler Bishop

06/09/2022, 12:17 PM
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)
👍 1
b

Bryan Finster

06/09/2022, 12:18 PM
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.
1
Our docs & training team was key to scaling our support. 2 people focused on curating the documentation site and holding product owners accountable to good docs. They also did ongoing training classes online that were recorded for async consumption. Training is a great investment in reducing OpEx.
27 Views