Don’t just rename your Infrastructure Team to Platform Team

How many times have you seen a suggestion to change the name of a team and have the senior leadership team expect that alone will solve all your organisational problems. 

It happens more than you think. Let’s just consider how many people had their role title changed to Site Reliability Engineer overnight; how many Business Analysts became Product Owners; it doesn’t make the slightest bit of difference, unless organisationally you understand the problem you are trying to solve and in parallel adjust the wider team design, team collaboration modes and the ways they interact (or more forcefully stated when theyshould not interact), their processes, remit, and how they fit inside the wider operational model.

The latest technology buzz is Platform Engineer and Platform Teams. And rightly so, establishing Digital Platforms run by a dedicated Platform Team is an effective solution to the complexities of modern engineering environments. But I urge everyone: understand why before jumping in.

Lately, I’ve read numerousblog posts around Infrastructure Teams being renamed as Platform Teams. No-one really explained why. And the how didn’t always land either.

As Leaders we seek to nurture an environment that leads to greater throughout of higher quality work that is delivered sooner and safer. Managing the cognitive load of the product team and ensuring there are effective team interactions are two techniques (popularised by the amazing Team Topologies book)in optimising the digital operating model for fast flowand can lead to the identification and formation of Platform Teams. 

Abstracting away the gritty complexities faced in operating in modern, often highlyregulated, engineering environments helps minimise the context-switching and reduce the mental capacitydemanded of the engineering team that can greatly impact on their ability to deliver value sooner and safer; and by extension makes for a happier engineering team and improved staff retention.

Examples of such complexities includes the runningof CI/CD, build and test platforms; the provision and management of infrastructure, even if implemented through infrastructure-as-codedeveloper by the product team; maintaining compliance to an ever-evolving world of security controls and requirements; common underpinning services such as those supporting IAM or SSO capabilities; running Kubernetes clusters; and many more such cases.

Outcomes of such a move can also include realising the benefits of economies of scale from consolidating similar functions, both directly and indirectly (for example, in future internal audits); consistent, secure, and managed internal toolkits; maintainability and extensibility when needs change in the future, applied once rather than many; and so on.

Done effectively, such conscious decisions around team design and their interactions an organisation can be more efficient; have fewer, more-manageable dependencies; and drive greater value and improved time-to-market.

But be aware of unintended consequences, or implementations that may reduce or inhibit flow.

For example, avoid replacing the current team autonomy withticket-based silos as the alternative. Likewise, avoid simply renaming the Infrastructure Team to a Platform Team without also mapping and eliminating the pre-existing waste in the process time.

A practical example. How many organisations have an Infrastructure Team whose remit is to provision a VM or some compute, storage, or similar resources – let’s say your Product Team needs a new test environment. All well and good so far – let’s assume there may be valid reasons that the team cannot spin up resource themselves. The problem often inherent in such team designs is the Infrastructure Team’s ways-of-working; look at yourselves and ask, how many of our internal teams take work in via a ticketing system that leads into a managed queue where the Product Team must wait for hours, days, or even weeks to see it fulfilled.

Strive towards your Platform Team being seen but not heard, as my father may have said, by which they:

• should add or facilitatethe addition of value, but they shouldnot be a value inhibitor.
• should not unduly appear on a Value Stream Map.
• should not be a bottleneck – we should not see them as waste that needs to be eliminated.

They can achieve this by ensuring their offering is available through self-service (plus CLIs and APIs – meet the product team where they are and what they need) and automation– and as a net result, there is no ticket queue as the intake for engineers to request work from the Platform Team.

In conclusion, renaming an Infrastructure Team as a Platform Team is a positive direction but ask yourselves why and avoid the anti-patterns when implementing thehow – i.e.focus on the collaboration mode instead ofmerely changing the team’s name – and by asking these questions may also help identify other opportunities to offer internal developer platforms