Building an internal platform for maximum impact on the company requires a transformation.
I will clarify, but let me start somewhere else first.
For the last few decades or so, we have heard of digital transformations everywhere, in the public and private sector alike. Thousands of businesses and armies of consultants involved in “transforming” companies into a digital existence. But that is not a transformation those companies go through — rather a digitalisation. Most of these digitalisations really entail companies using digital means for what they used analog ones in the past. Pretty much the same structure and processes, but with digital resources instead. Which is why a better term for these changes would be digitalisation rather than “digital transformation”.
For it to be a transformation, companies would need to rebuild the whole company, or parts of it, from the ground up with digital means in mind. A company built from the beginning to be digital would most likely look quite different from the same company that started analog.
Getting back to internal platforms and software. Creating a platform team and a central platform while expecting no real changes to company structure, processes, and ways of working is equivalent to a digitalisation in the previous example. By taking only this step, there is an opportunity lost — hard to say how big, because it depends on the context, but it could be a large one.
Let’s take an example. Say the new platform is supposed to handle the way product services are deployed, and a new platform team gets to build or consolidate existing blocks into it. Since it’s very likely there was no clear structure for this part of the service lifecycle, there are probably multiple ways deployments were done in the past. If the platform team simply tries to act as a drop-in replacement for each service and each way of doing deployments, the platform will carry unnecessary complexity that makes it hard to maintain and improve, and there won’t be major gains at the organisation level (digitalisation). If instead the platform team feeds back to each service owner the improvements and changes they can take to simplify deployment logic — for them and for every other service owner — then the complexity of the platform is lower, and the platform drives improvements and standardisation in the services and teams it supports (transformation).
There are many examples and areas like this: CI/CD pipelines, monitoring and observability, provisioning of infrastructure, and many others. All of these are usually done in a somewhat ad-hoc way in the organisation before a platform is introduced. A platform team can have a transformational impact on the company by feeding back improvements and best practices to the teams and services it serves — or it can have a marginal impact by simply taking over complexity as-is.
A platform can start with marginal impact in order to minimise disruption and increase adoption, but it should not stop there, nor be expected to.
The shift from marginal to transformational isn’t really a technical one. Absorbing variance and reducing variance are about equally hard to build. The difference is that the second requires conversations the platform team often isn’t set up to have — pushing back on service owners, aligning with leadership on what “done” looks like, occasionally saying no. That’s probably why the marginal path is more common, not because anyone planned it that way.
So the next time you consider introducing a platform, plan for a transformation and not just a convenience.