Rapid, curated, harvested innovation

In partnership with

Matthew Skelton recently spoke at Yorkshire DevOps, and - as someone who is quite familiar with Team Topologies as it relates to Platform - I was blown away by how much new stuff there was to look at. It has forced me to rethink much of the book regarding direction and what the Platform is about.

Organisations should take a team-first approach to Platforms. Platforms should be about empowering and augmenting teams—it's 'not just Kubernetes'.

Steam-aligned teams are incentivised to innovate in order to provide differentiation of the company from others n the market. Spotify is often cited as an example of how to structure an organisation. They have fully embraced DevOps and the teams are responsible for the whole value stream end to end. Working in this way allows the stream-aligned teams to operate quickly but leads to fragmentation.

The Platform team provides CI / CD. web tools, testing tools - anything which will improve developer productivity. Engineers can then focus on experimenting. One feature of Spotify is that they make lots of use of A/B Testing all provided by the Platform.

Matthew Skelton talks about gardening as a mental model - it follows 3 stages foraging, harvesting, recommoning which form a loop. As the teams make use of the innovation that has been harvested and recommoned as part of the Platform the teams can then innovate and build more effectively and 'grow' yet more innovation to be harvested.

This loop is similar to the ILC - "Innovate-Leverage-Commoditize" - which is used to good effect by companies such as AWS. Simon Wardley has a great overview of this process. Essentially it allows your business - or in our case the Platform team - to identify where the best opportunities are. The ILC process is simple - you monitor successful csutomers and copy what they do

They Innovate
You Leverage the success-indicating data
then Commoditise their services - Harvest them

Start by making a service that's easy to consume and then identify when the users have had success. As Wardley says "This data is a lighthouse" - you can see where your teams have innovated successfully and use this to steer your Platform.

One of the main changes which has to be made when a service is harvested and recommoned is that it should be like theirs but easier to use. You then get new users and so can start to innovate again.

AWS really is the best example of this ever since it was EC2 and S3. their customers create services on top of AWS. Eventually AWS releases a commoditised version of that service.

If basing a Platform off the ILC you need to follow the same process to make it work. You need to offer an initial commodity offering in that you need to offer a service which can be used by many of your users easily and can be adapted by many of them to meet their needs. It also has to be 'within your realm'. So AWS only pulls in IT infra products because that is what they sell. The majority of Platform Groupings will also have an IT focused Platform but they also might have a domain specific Platform - for example an insurance company might want to create a quote Platform that it then makes available to all of its teams.

One aspect which is often missed when building a Platform is that it's essential to see which of your stream-aligned teams are using which pieces of your Platform. This is because you need visibility of what they are building on top of your Platform so that you can consider whether to harvest it and recommon it.

There are established ways to avoid ILC if you are a company competing with an organisation which uses this type of tactic. As we are looking to model our Platform curation process on ILC these are thing which might make us not want to harvest and recommon a particular innovation from a stream-aligned team:

• Innovation is too quick - every time we try to harvest something the team has moved on before we have time.

• Constraints - an example might be that it is too complex or too costly

• Size - too niche and specialised

As a Platform team ILC points to a way to merge the innovations into the Platform. It also shows how we should set up the Platform in a general and easy way so that most people can use it. It must also be set up so customers can adapt it to fit their needs. These needs will allow stream-aligned teams to innovate on top of the Platform, ensuring that any innovations are visible and more easily harvested and re-commoned.

It's interesting that the more we build internally the more baggage we have. This is especially true if there is a complex process around getting anything done. This slows down the whole organisation. Also by building a lot of things internally we are limiting how teams can use the Platform and so we are reducing the opportunities for innovation.

The aim of the Platform is not:

• Big Platform

• Protect production

• Centralisation

• Reducing costs

In fact these are part of the Stability aspect of the org which we might call Central IT or Ops (shivers).

The Platform provides many things but at its core it provides a service - it is a curated experience for engineers. Part of that curation is choosing which things to harvest and recommon - Platforms can choose whether to harvest a service from a team. There may be things which make it difficult to do this.

The curation aspect is one way in which the Platform team reduce technology choices and automate processes to reduce distractions from the work itself. This is why Spotify use Backstage to provide creation templates and scaffolding for standard things like websites and microservices.

Innovations and new things are not even considered for harvesting and puling into the Platform until they have passed a level of test certification that means they have reached a level of stability.

By reducing decisions Spotify allows its developers to reduce their cognitive load. When the innovations are recommoned and then pushed back out to the other developers the engineers are able to safely move up the stack

Spotify’s Platform team offer multiple ways of achieving the same thing - this is often a really good sign of a high performing Platforms team - far from trying to dictate to devs what they should do or how they should work the Platform team offers different ways to achieve the same aim, often basing the different types of offering on the level of engagement necessary for the devs to achieve their aim. In most cases this is the same as saying on the level of bespokeness needed.

Helping engineers to move up the stack - towards production and towards their customers - is a really good way of allowing them to gain more knowledge about their customers and the domain while also providing them with a really firm foundation on which to build. It allows them to move in the right direction while maintaining a level of resilience and code quality because they know that the ways in which they are working have been signed off so they don't have to think about them again.

Golden paths are another way to help devs to move themselves and their products up the stack and are actually part of the Platform as they show devs how to work with the different products and services offered by ops while packaging those services up in a way that ia accessible.

Recommoning shows its value when we see that Platform provides a place for people to work on and use Common things - some things which start off with dev teams would provide more value if they were in the Platform and they were recommoned. ON the other hand some of the things which are tightly controlled by Central IT would be better being shared by the Platform team.

By making these innovations part of Platform the organisation can then provide them to other teams in a consistent way over the same interface as Platform has with each of the stream-aligned teams.

Jabe Bloom - who popularised the term recommoning as the thing Platforms are for - suggests that one of the ways in which you can make part of the system more stable is by more people using it. This may be one of the reasosn for the success of open source software - if more people are able to use it and change it then it will be better tested and made robust by the people using it. As it becomes more robust it becomes more attractive to the people who might use it and so the cycle contunes.

The use of the Platform being the thing that brings resilience to the Platform seems connected to Simon Wardleys moldable software and of Mike Peachey’s ideas around a system always being in motion in the Newtonian sense.

If we change what Platform provides then it will not be given all of the boring jobs and instead to become the cradle of innovation - or perhaps the nursery of innovation would be more appropriate.

The newsletter every professional should be reading

There’s a reason Morning Brew is the gold standard of business news—it’s the easiest and most enjoyable way to stay in the loop on all the headlines impacting your world.

Tech, finance, sales, marketing, and everything in between—we’ve got it all. Just the stuff that matters, served up in a fast, fun read.

Look—over 4 million professionals start their day with Morning Brew’s daily newsletter, and it only takes 5 minutes to read. Sign up for free and see for yourself!

Check it out