This message was deleted.

Team of 11 - 4 devs, 3 sres, 1 tester, 1 TL, 1 PM, 1 scrum master

Hi 🙂 In my organisation we have ~75 developers and 2 business units. I am the product manager for the platform team which sits in the “corporate” function, reporting to the CIO. We have a platform team of 6 (4 team members, 1 team lead and 1 tech lead) + me half-time as PM. Our scope of responsibilities is all transversal tooling for the software development lifecycle. The team is 3 years old, we had 1 person leaving and 2 newcomers joining 1 year ago. For now, the team is too small to think about dividing it into sub-teams. We divide responsibilities among the team around 3 separate roles that rotate every 2 weeks: • Operations -> basically answering tickets and provisioning stuff that we did not make self-service yet (kind of old school infra job) • support -> open-office hours with devs coming and asking us question on how to use the platform, helping with design, ... • Implementation In the coming month, we are planning to change that a bit with a 6 weeks rotation and the following roles: • SRE -> focused on alerting, maintenance, ... • Support -> grouping operations and support from the previous org • Erasmus -> being embedded in a product/project team to help them in their delivery, the goal is to bring them knowledge on the platform and gather their needs/pains • Implementation Hope that helps 🤗

Hi So work in an org with headcount around 2000. Our Tech group probably around 300 with 40% doing dev work. We have 4 distinct lines of business and so there are 3 dedicated platform teams. (Windows / Windows and Azure / Linux and AWS) So we are a Linux based team running Prod Stag and one QA environment on prem and around 40 development labs in AWS. Our reponsibilities are keeping the lights on in prod as we are a 24x7 Building and extending the labs as new integrations etc come online and eventually push all the way tp Prod Currently we use Jenkins and Ansible and are slowly transferring some of the workload to terraform as scepter has limitations that are annoying Team is currently 13 people (with 2 vacancies) 1 PO 1 SysEng (me) 2 Software Integration (Sofware stack ops) (on call every 4 weeks as part of bigger capability) 1 Network 1 QA 3 Server admins (1 is contractor) (ops work as well) (on call every 5 weeks as part of bigger capability) 3 DB Admins (1 is contractor) 1 Dev engineer and 1 co-op for 8 months Also 2 people that act as scrum masters (and wearing my SM diguise, I feel the eam is getting a little large and unwieldy) J

I relate to this question, as I have been doing dedicated Platform Engineering since 2018. I’ve been in teams from 1 to 8, depending on the size of the company, the maturity of the team and the number of development teams your platform team supports. Some companies can afford multiple Platform teams to have a global internal reach, which is practical when you share knowledge and experiences.

It’s highly dependent on the organization imho. To me it’s similar to any function really. Surface area complexity or contention, performance, whatever. Something acts as a forcing function indicating a need to expand or contract is necessary. It’s healthy for there to be a desire to see budget neutral growth for an internal function as well. You don’t want a platform team scaling in linear fashion to the organization it supports. In terms of size ratio… at Samsung, within SmartThings Cloud, my platform team was approximately 22 total headcount directly supporting an R&D function of around 200? Delivery, Observability, Data primarily. In my current org my internal platform group is around 60 supporting an R&D function of approximately 900. Its overarching charter is similar but different. There isn’t a perfect formula. What are you trying to enable your internal customers to achieve? “Platform” doesn’t simply mean a container platform and some CI abstractions. It means scaling, enabling, and creating leverage. What are they subject to? Compliance? Regulatory concerns? What are you reducing? What bets are you making on their behalf? Scale to meet the needs of the organization, not the other way around. Hold yourself accountable to adoption and other key metrics and use them to drive growth when appropriate.

Thank you all for your responses. These are fantastic insights. @Aurélien Crucifix if it comes to setup in my organisation, the current team structure is: 4 DEV, 1 SRE, TPM, PO, part-time principal engineer and me as a lead. As we are getting more traction we are now putting more emphasis on SRE and this is a first sub-team / domain, which forms quite naturally. The next domain I am thinking of is connected with onboarding of bigger dev teams e.g. 2 engineers could be performing “tour of duty” to help the teams get on a platform. The target plan is to have dozens of dev teams actively using the platform and by that make their lives much easier 🙂