Hi everyone, though I'm new to the concept of Platform Engineering, I'm by no means new to engineering team inefficiencies... My first intuition on PE is that it looks like an appealing promise but doesn't help to small R&D organizations cope with their inefficiencies. Small = up to 50-60 developers. I'd be pleased to get your feedback on such engineering teams, which problems you think they suffer from, and how PE aims to solve them. Looking forward to some good ideas 🙂

generally disagree but i’m also not familiar with your small r&d org’s specific inefficiencies so it’s hard to challenge your stance. i agree that it may not be a fit for every organization, and there’s a point of complexity where it becomes more optimal to bridge the dev team needs to the ops team requirements (k8s/security/compliance/cloud infra) with a dedicated platform engineering discipline that focuses on enabling self service patterns for dev teams, but with the knowledge of the requirements of the ops teams. i’ve seen this need first hand in a 50 developer shop, but it was under circumstances of 4 separate dev groups within that org and high compliance requirements that they all had to conform to. every 50 developer team obviously isn’t organized the same way and every project doesn’t have the same compliance and infrastructure complexity burden, so it’s case by case in my mind. but 50 is nowhere near too small to take advantage of platform engineering in many environments.

I think that most of the tools being built are geared for 150+ engineers solving day 3+ problems and there are a bunch of tools that are good for 0-.5 and maybe to 1 problems. The challenge is that each of these phases requires migrations to the next set of tools. The issue with platforms tends to the migration tax at these stages and the adoption at later stages. nailing a tool that is capable of growing with you that does NOT require 1-3 HC to maintain during the .5 - 1.5 phase is relaly hard. its much easier for platform companies and teams to say “our ideal customer is only greater than X and requires a migration but the ROI is Y”

Dont stick to the term platofmr engineering. Create your own ID{P that serves the developers various services. "consolidate" how you create pipelines, how you deploy to dev/prod, how you provision infra, how you onboard/offboard users. What you want is self-service. You dont need a PE to create a service that is consumed by youre devs.

Hi @Regev Azriel some great observations there. At first PE can look like it only adds benefit to large engineering teams, but upon closer inspection you’ll find that the value of PE increases exponentially with the number of engineers. In my experience the best time to start your PE journey is while things are still manageable, as this allows you to set some early guidelines that you’ll be thankful for when things start to get chaotic. WRT the tooling comment, Compass is a great developer experience platform that requires almost no overhead to maintain as it is a SaaS product. You can literally sign up in a few clicks and you have something that will add value immediately, and will help as things grow. It’s free to use at the moment so I’d recommend signing up and giving it a go.