[RFC] Relaunch the Platform practice about readme HOT 10 CLOSED

Additionally, the new practice could have clear goals such as:

• Ensuring consistent and additive service design across the company
• A forum for recognizing and acting on technology trends, risks or opportunities
• A service or boost to product teams rather than a hindrance

(Feedback welcome.)

from readme.

I feel like RFC this better represents how we staffed Q4 for platform

• A group of core infra/support-ish engineers who do this full time
• A set of folks who live in other teams but do work that want to consolidate learning's and share

I think figuring out how the regular practice meeting is set up will probably talk a lot to whether this feels like a great fit in the long term. Just like with front-end, there are so many concurrent projects that trying to stay on top of them via a weekly meeting can get tricky in a short timeframe

from readme.

👍 for the renaming of Platform to Infrastructure. That's how I'd mapped it in my head already, anyway.

from readme.

Does the consolidation of the auction engine into Causality belong on the project map too?

from readme.

This makes sense to me (as a collaborator, but not member, of the Platform team&practice).

Finally, for clarity we've been talking about renaming the Platform team to Infrastructure. It's less ambiguous with the practice that way.

Big 👍 from me on this idea.

from readme.

I'm definitely 👍 on this. All of our product teams are making platform/infrastructural level decisions at some level during larger product work. Having a forum to facilitate how we're working makes a lot of sense.

from readme.

+1 for renaming Platform team to Infrastructure and orienting its goals around more concrete KPIs. By narrowing the scope of the core team, I think this gives the practice a real raison d'etre as a way to come together to discuss best practices around service design, modelling and cross-team performance issues.

from readme.

Let's consider Hokusai.

Hokusai is a developer interface to a Kubernetes cluster -- it provides easy-to-use abstractions for deployments, accessing developer consoles, managing environment configuration, etc. Creating and managing Kubernetes is most definitely an Infrastructure concern, but, under my understanding of Platform Engineering, building tooling to easily interact with Kubernetes (aka building hokusai) is exactly the type of work a Platform Engineering team performs.

If Artsy wants to, in a first-class manner, continue to develop systems like and patterns supported by hokusai, then I think having a team titled Platform Engineering is fitting and accurate.

I believe Infrastructure might be too limiting. To be concrete, I would presume that an Infrastructure team would manage a Kubernetes cluster, but not necessarily build tooling like hokusai.

A theme in the previous comments on this issue is that there is a naming collision between the Team and the Practice. As a new member of the Platform Team and I guess Practice, I've found the goal and responsibilities of the Practice to be confusing (as well described by Joey), resulting in a personal feeling of organizational unclarity, which is a bit of a bummer.

Given this, I'd propose that we keep the Platform Team named the Platform Team, and reset the Platform Practice to be in a "discovery mode": unencumbered by legacy org design, we can rediscover the human interfaces needed with the rest of the product and engineering teams, and name this thing as we learn more. I'd propose that we delete the practice, wait a couple of weeks, and then reflect on what is and isn't working with across Artsy's service, and the solution from there. This would solve the naming collision, and simplify organizational design by deleting some organizational constructs.

My 2¢ as a new member of the team!

from readme.

I like the idea of emptying and rebuilding the "practice." At least, the google/slack groups and associated calendar events.

Re. the name, I agree that the team does intend to be accountable for more than the operation of certain back-end systems. At a high-level I imagine the KPIs to be around performance, quality/reliability/incidents, and velocity (so, e.g., including concerns of tooling). I wouldn't want the "infrastructure" name to appear to exclude any of those. I did like how it cleared up the ambiguity with the practice though.

Reaches for thesaurus...

from readme.

Please keep any feedback coming, but:

Resolution

Relaunch the practice!

Level of Support

1: Overwhelming positive feedback 😍

Additional Context:

There was broad agreement about the ongoing need for an improved cross-team forum, but some hesitation about reframing the Platform team as "infrastructure" since that might be overly narrow.

Next Steps

I will cancel the practice stand-up and schedule the weekly practice-wide session proposed above. I'll invite engineers to opt-in to the updated platform@ group corresponding to the practice events.

Exceptions

We'll defer the question of renaming the team for now. This maintains the potential ambiguity, but at least doesn't appear to exclude in-scope responsibilities like tooling.

from readme.