The situation is usually like this: For a long time, technical debt is not an issue, or it is ignored. Eventually, development slows down and more and more problems arise. Technical debt slowly becomes an issue. Discussions begin about how to tackle it. By that time, so much technical debt has accumulated that single teams are overwhelmed.

When refactorings affect multiple teams or are too large for a single team to handle “on the side”, the idea of a dedicated platform team eventually arises. A platform team can take care of such issues and ensure that all other teams can continue to work smoothly.

Each team still remains responsible for technical debt and refactorings in its own context. The platform team only takes over when all (or at least several) teams are affected.

Basically, this sounds like a good idea. It’s a way to get technical debt under control and at the same time push development forward without overburdening the teams.

Unfortunately, experience shows that despite the good intentions, a different effect occurs in practice.

  • The most experienced developers are withdrawn from the development teams to set up the platform team; after all, the platform team is working on key components that are relevant for everyone. Their knowledge and experience are needed here. Nevertheless, this approach is problematic because it often removes key people from the teams. This has many consequences: The teams have to realign. This automatically leads to increased friction and - most likely - more technical debt. The workload of the individual team members increases. Problems that were prevented by the balancing nature of the experienced developers in the teams now occur regularly.

  • The introduction of a platform team creates additional dependencies in development. If a platform team is responsible for the central components, this also means that other teams may have to wait for the platform team. On the other hand, it can happen that the platform team builds solutions, although it is not yet clear whether they are needed or not. If adjustments to key components are necessary, they must be communicated to and prioritised by the platform team, which can further stall the development teams. In short, there is another external dependency of the development teams that can slow them down.

  • Retreating teams. Unfortunately, another effect of a platform team is that individual teams no longer consider themselves responsible for reducing major technical debts on their own. Instead of actively looking for solutions and, if necessary, requesting the time for refactorings from the product owner, teams tend to sit back. The feeling of ownership disappears and is replaced by a dependency on the platform team. This is - from our point of view - one of the biggest risks, since only the teams know which technical debt is actually relevant and how to solve it best.

  • The root causes of technical debt are not addressed. A platform team can help reduce technical debt, but it cannot prevent the development of new technical debt. One possible driver of technical debt is poor communication between teams. Having a platform team would further exacerbate such a problem instead of solving it. To get technical debt under control in the long run, it is essential to find and address the root causes of technical debt, otherwise a platform team cannot solve the problem.

If you want to set up a platform team despite these problems and risks, there are a few key points to consider. This may reduce some of the negative effects that can arise.

  • The platform team provides technical services or components that are needed by the other teams and allow them to write simpler code. This could be a component for uploading images or sending push notifications, for example. In other words, these are generic components that could also be found in the open source world.

  • The platform team supports the other teams in integrating these services or components into their own code and, if necessary, getting rid of their custom solutions (in other words, reducing technical debt). This keeps the platform team close to the problems and requirements of the development teams. It becomes more likely that only the things that are really needed are implemented and that the technical services/components are really useful in the end.

  • The team is built around one experienced developer. Under no circumstances should too many (experienced) developers be taken out of existing teams. This also means that it is better to start with a very small team instead of bringing too much disturbance into all the other teams.

  • All technical components are inner source (internally open source) to minimise dependencies between teams. This way, each team can consult with the platform team and implement new requirements themselves, instead of waiting for the platform team.

There are many more questions to address before actually taking the step towards a platform team, such as:

  • How to make sure that the platform team is working on topics that are relevant?
  • How to ensure that there is no communication gap between the platform team and the product teams?
  • How to make sure that the platform team is not perceived an ’elite team’ or sees itself this way?

Overall, we are quite skeptical about the idea of platform teams. There are some advantages that can result from starting a platform team and for some companies and situations a platform team might be exactly the right step. However, there remain many risks that can lead to a lot more problems than a platform team can solve.

Webinar: Scaling software development as a SaaS company without becoming consumed in the growth process.

The webinar addressed exactly the pain points that are occurring as we grow. With an ever-increasing number of employees on the Dev & Product team, we've had to find out for ourselves how difficult it is to set up a sensible structure that brings out the maximum efficiency and performance in everyone, while also leading to a healthy working atmosphere.
Pascal von Briel, Co-Founder & CPO @ exporto GmbH