(This is a continuation of my previous article Platform Strategies With Team Topologies)
“But our team needs something special”
It all started with a workshop on a new internal platform I helped to build. Besides the platform team, we had some seasoned engineers from the (stream-aligned) development teams present. This helped to create alignment, but can be dragging. I anticipated a longer discussion when one of the architects from the development teams noted:
“But our service is special. We will need a special configuration, which none of the other teams will request. With this new platform, I know I will need to wait for 6 months and have endless meetings.”
This is obviously bad. A decline in productivity was not one of our goals for the new platform. Fortunately, the engineer was also very hands-on and wanted to solve the problem. As we were in the means of building the first version of the new platform, we agreed to join forces.
At the same time, I had this uncomfortable feeling that something was not right. Aren't we supposed to build the platform? Shouldn’t this great engineer focus on building his service? This suspicion kept lingering in my mind until I had read about the different interaction modes in Team Topologies. This helped me to disambiguate the different roles and make the interactions explicit.
Product Thinking For Internal Platforms
Internal developer / cloud platforms are a great mechanism to set guard rails, reduce cognitive load on (stream-aligned) development teams and therefore improve the overall productivity. But a common risk is that we build another internal system that doesn’t meet the requirements, isn’t well maintained and slow to adapt. A common approach is emphasizing on a product mindset (e.g. CNCF Whitepaper, Thoughtworks) to ensure we keep users and their requirements in mind and that we prevent feature creep by building the Thinnest Viable Platform.
Collaboration As Competitive Advantage
Something that I miss with these approaches is the unique setting we are in when we are building an internal platform. We don’t have a customer relationship. We have a team relationship between the development and the platform team. If the platform is just another service: Why not hire someone external? Why not buy something off the shelf? Using off the shelf components might be a good idea for certain capabilities, but the reason we are building an internal platform is that it’s doing something unique. Something that our stream-aligned teams can’t just buy. As an organization, we should use this special setting to our advantage. We should enable collaboration between teams and allow new ideas to flourish in this safe internal environment. But to ensure this collaboration is productive, we need to manage it.
Self-Service Adaptation
Just like the architect from my example, good engineers know how to help them-selves. They get around roadblocks and automate toil away. However, they need an environment that allows them to do it. So in the case of our internal platform, we have to ask ourselves:
How fast can good engineers adapt the platform to their needs?
There are several ways to approach this, but if you have good engineering practices likes CI/CD for your platform development, you can treat adaptations from other teams just as normal development. A seasoned engineer should just take your platform, fork it, adapt it and deploy their version of it.
This is not a hard task. Especially in our unique internal setting where we can be open and descriptive on how to run and operate the platform. Frameworks like Crossplane support this out of the box.
Explicit Interactions
Once these forks (or other adaptations) exist, we need to evaluate if we want to get these changes back into the platform. We need to look for adoption signals, and the development team should do some internal advocacy.
If we see a rising interest, we start evaluating if and how the changes should be merged back into the platform. The development team and the platform team start collaborating closely. It’s important that this collaboration interaction is explicit and time-boxed. The final goal is that the new functionality is completely handed over and Team A can get back to using the service as an offering from the platform.
Summary
Great engineering organizations are leveraging their collective internal knowledge. And great platform teams enable adaptations of their platform. To ensure our development continues to flow, we need to be explicit about interaction modes between teams and keep close collaborations time-boxed.
If you have seen similar issues in your org, please reach out or leave a comment. I’d like to learn more about other approaches. I am happy to share more insights on what I’ve learned so far.
(This was also posted on LinkedIn)