Hi everyone 👋, great conference so far! 👏 My talk is about applying #platform thinking across the entire organization. It includes a "state of the union" on #platformengineering - what have we done well so far and what might still be missing? I'll be answering questions ❓ here from 7pm-9pm CEST | 12pm-2pm CDT. Join in and let me know what you think: can the #platform mindset be applied more broadly than #Engineering? What are the challenges you see? 🚧

@Manuel Pais (co-author Team Topologies) Just watched your talk and I'm curious about the section on Trust Boundaries and what your thoughts are about innersource in this context. You mentioned aspects of control in other parts of the presentation, but I think there is generally a lot of issues raised by teams with allowing other people to touch the platform itself.

Hi @David Stenglein, sorry for the late reply. I think in general innersourcing is a good strategy to avoid having too rigid platform boundaries. Allowing other teams to make changes they need in the platform is generally a good thing. But there are two main issues I see: first the platform team need to already have good engineering practices in place (test automation, code standards, etc) otherwise it an become a mess and a blame game. With sound engineering in place it shouldn't be hard to define the criteria for accepting changes coming from other teams. The other point is trust as you point out. In environments with low trust, just setting up a process for innersourcing is likely not enough. It might even be perceived as a "façade" for actually making it harder to change the platform. So in those cases the platform team has to "promote" innersourcing effectively, talk to teams about it, take advantage of some simple use cases where another team might be willing to give it a try, and collaborate/pair on those initial cases. Then use those early small victories to showcase to the rest of the teams that the platform team is serious about making innersourcing work.

@Manuel Pais (co-author Team Topologies) Thanks for the reply! I agree that the engineering practices need to be solid in order to accept work from contributors outside the team. I like the solution to the trust issue and this might be a place where a rotation could help a lot too.