@Jelmer Borst thanks for the great insights on how Picnic builds and maintains platforms. You mentioned a very specific example the

picnic-support-modules

. For such a centralized piece of software or feature of your platform. What processes or workflows do you have in place to decide if a certain feature should be maintained by the different product teams or be handed over to the central support module? How does this decision process look like at Picnic (also with respect to the principle of aligned autonomy).

Hey 👋 Very fair question! Generally we don't try to bloat it too much. That means that everything that goes into our e.g. java modules, should apply to almost, if not, all java teams. That means: sensible defaults, and provide the appropriate configuration options. In practice, you generally see the team working a lot on core stuff like keeping libraries up to date, improve build tooling, and supporting the latest of Java/Python/... If there's a feature that's only applicable for a small number of teams, it doesn't go in here. That said, we do quite some POCs, which then lead to porting and generalising the functionality over to it. Usually by the original authors, but having the benefit of having better support by the platform team across the org. Hope that answers your question, but free to ask more 😄

Thanks for the quick reply 😊 Makes total sense. I think the "things that help all approach" seems quite natural and intuitive. However I like your addition regarding the POCs and that many features are sourced from the original authors (which if I understand correctly can also be part of the product teams?). This approach sounds like a internal OSS-like development organization were people are free to contribute to the platform and if their contributions matches some standards they can get their work "upstream" and trough that offload their single team from maintaining this specific piece (leaving the multiplier benefits completely aside and focusing on a single teams perspective 😉)

Exactly! Very very similar to an OSS model. Similarly there are also things openly listed that we want to incorporate in our support modules. This can also be picked up outside the main team. For example, if you need it for you team AND it's listed for the platform team to adopt, why not catch 2 birds with 1 stone? 😁