Leadership of Critical Change
Designing Exceptional Services
Digital Organisation Optimisation
Driving Engineering Excellence
Service Ops Modernisation
Unlocking the Cloud
There are many articles that outline the what of Platform Engineering; however, there are few that offer tips on how and little to explain why. Through our experiences establishing and operating Platform Engineering teams at highly regulated, global enterprises, here are some tips for platform success.
Define your why.
Of course, while we should not dismiss the importance of understanding what a “platform” means, given your context, having observed organisations that simply renamed their ‘Infrastructure Team’ as ‘’Platform Team’, with no change to function, role, or purpose, we recommend that you begin by defining “why do we need a platform?”
Articulate the answer in a way that resonates across engineering teams and their leadership - i.e. those that will consume your platform - and formulate a 30-second elevator pitch that allows you to sell the value the Platform Team will provide to your organisation.
It is useful to frame its purpose and set out the scope for what problems the Platform Team intends to solve (and those it will not) - if you are struggling where to start, consider utilising the VMOST framework and begin by defining vision and mission statements.
Recognise organisational tensions and find the sweet spot.
Whether you are building a platform for 50, 500, or 5000 engineers, there will be a constant tension and ebb-and-flow between the need for organisational consistency and standardisation of practice versus a desire from engineering teams to have the autonomy and freedom to innovate, experiment, evolve, and drive self-improvement.
If the platform offering doesn’t meet their needs, is slow or has no support, then expect vocal pushback and a desire for a federated or decentralised model - that risks achieving the benefits of a Platform Team.
As leaders, use this natural and constant tension as a beacon for how well you are meeting user needs.
Lower the barrier and make it easy to consume.
The extent to which the Platform Team can get out of the way is key to reducing the tension, and engineering teams are more likely to adopt a platform when the experience is slick and compelling.
Offer teams access to immediate results through self-service, rather than via ticketing and an operational fulfilment model that may take days or weeks - even if you turn requests around in hours, that will still likely disrupt delivery flow, cause context switching, and introduce inefficiencies in your organisation.
Core to successful consumption is making the platform user-friendly - i.e. it should be obvious how it works - invest time upfront in service and user experience design, and where necessary augment with providing users with practical knowledge acquired through tutorials and how-to guides, alongside theoretical knowledge, explanations, and reference information.
Support your Platform.
Ensure you understand the operational requirements of your platform - for example, if engineering teams use it at all hours, then it should be available and supported 24/7. Treat your platform just as you would a product or service being offered to an external, paying customer - that includes setting service level objectives, establishing monitoring and alerting, and architecting your platform for operability.
If your platform is available globally, yet you only provide support in a single timezone then do not expect positive feedback and high levels of adoption from outside of that timezone - for example, if the platform is regularly unavailable at a time when one geography performs all their production deployments.
Measure and set goals.
Establish business metrics around platform adoption and set yourselves clear targets that informs your strategy and roadmap - this requires you to understand your user base, segmenting them into cohorts (such as those that are the ‘not built here’ sceptics, or have specific niche needs) and creating an approach for how you work with each group.
If you are working globally, recognise there are cultural and regional variance in attitudes and ways of working - what lands well in one geography may not be successful in another.
Manage your Platform “as a Product”.
By treating your platform “as a product” you will maximise its value to engineering teams and optimise the way your organisation builds, tests, deploys and operates software solutions - that is because you will be listening and delivering to their real needs, what blocks and frustrates them daily, and creating a platform that serves the needs of the entire engineering community.
Managing “as a Product” also counters the desire to mandate usage of the platform - which creates an environment where the Platform Team builds out features they think users want without actually engaging closely with the engineers.
Start by dedicating one of your Product Managers to engage the internal community via forums, user surveys, published roadmaps, and through open discussion to listen to their pain points and build out a backlog that meets those requirements.
