[sam_lowry_]

My personal experience with core teams has often been a disaster. The only successful core team I saw adopted the servant leadership approach, letting product teams make choices and staying pretty much out of their way while codifying existing practices and moderating discussions. It also served as interface to external infrastructure and engineering.

This core team was busted after a few years, its head fired and replaced by an oppressive junkie that started spewing corporate standards and imposing frameworks with the speed of an office printer.

You really have to have a special mindset to be willing to join a core team, and this mindset is opposite to what people that deliver a working product have.

There is a reason why "premature optimization is the root of all evil" is the motto of many generations of programmers. From their perspective, core teams are personified evil, because their only purpose is to optimize, prematurely.

[sascha_sl]

My first experience on such a team was a team that started out improving a lacking standardized deployment process (including changing the target from a very bad slow scaling prone to errors AWS product - yes beanstalk - to k8s). The biggest benefit here was that the team was on the same floor as most developers, and the entire company was really small. We knew the challenges that developers faced.

We then eventually rewrote the platform from an "everything is implicit" approach (branch leads to deployment with stable URL x, logs end up at Y, metrics get scraped at Z) to "everything is explicit but we have a second component that emulates the old way unless overruled". Nothing changed for developers, except that they got a lot more levers.

Then that company was merged back into the mothership (it was a "moonshot startup make an online shop for us" kind of company) and everyone there that could be enthusiastic about technology was excited about the stack, considering they were stuck in the 2000s before. The tech turned out to be flexible enough to accomodate the needs of modern Scala/Node services and legacy PHP alike (with the help of a base image that included a little go proxy to add standard HTTP metrics).

Unfortunately there was a change in leadership to someone who wanted to essentially recreate a tech stack they had used elsewhere. Akamai to Cloudflare, AWS to GCP, Slack to Teams... unilaterally. The team imploded within a year and a large Kubernetes vendor came in to get developers on "standard tooling".

As far as I can tell, 2 years later, our infrastructure survives though. We built it pretty tough and I guess none of the other "standard tooling" solutions really fit. The vendor even ended up asking if they could open source the system. Unfortunately nobody in legal cared enough to figure that one out. I'd have liked it to survive somewhere.

It's a very unique story of a platform that actually evolved mostly organically, and I realize that most attempts at platforms don't work that way. I always try to take learnings from this into new attempts, and it has been working pretty well. Getting someone from platform to work in development teams is probably the most useful thing I'd recommend.