GCP – The Modernization Imperative: Is your platform engineering project doomed to fail?

Recently in The Modernization Imperative (TMI), my colleague Richard Seroter shared about the importance of shifting down rather than shifting left — leveraging pre-built platform functionality to lighten the load for both your developers and operators. From my work advising engineering leaders on cloud modernization, I couldn’t agree more. However, if your organization is building its own platform (and by extension platform engineering team), then do yourself a favor and ask yourself a few questions before you begin. Take my word for it: failing to do so will ensure that your platform is a massive flop.

Creating internal technology platforms in the enterprise is all the rage these days, and for good reason: they allow IT specialists to be more independently productive, while maintaining centralized governance and security at the same time. Not only is the cloud itself a platform – it also presents the perfect opportunity to develop additional internal platforms on top of it, for example: a data platform with BigQuery, an ML/AI platform with Vertex AI, an API management platform with Apigee, or a multi-tenant container runtime platform with Google Kubernetes Engine. Platforms running on top of platforms!

To a CIO or an Enterprise Architect, the strategic importance of investing in a platform might seem obvious. There’s just one catch: nobody else in your enterprise cares about your platform. Just because you build it, doesn’t mean they’ll come.

You can force people to use your platform, of course, but then you’ll only achieve half of your mission: you’ll gain the centralized governance and security posture, but you’ll set your internal users back by forcing them to relearn, retool, and replatform something they didn’t ask for and (subjectively) didn’t need, and hence will resent before they even get started. If their experience is anything short of flawless, they will blame both the platform and you.

Can you encourage adoption, or even a wide-open embrace? Are new internal platforms always doomed to fail? Thankfully, no. 

There are just three essential questions you need to answer first to set yourself up for success: For whom are you building the platform? Who is going to build it? And, last but not least, how will you measure success?

Question 1: For whom are you building?

We’ve all heard the advice to “start with the user and work backwards.” In large enterprises, however, this can be harder than it sounds. Ultimately, the actual user of your internal platform is another employee in another department, but their needs are represented by their department head or their product owner. They, in turn, may interact with a “head of platform X” who prioritizes the feature backlog and delegates architecture design to an enterprise architect, who in turn gives guidance to the platform engineers on how to build it… What exactly does your user need again?

Here’s what should be happening: the platform engineers building your internal platform should be meeting regularly with the actual user, face to face, supported by a Product Manager who is part of their team. Everybody involved in creating or consuming the platform needs to fit into one room — or at least be visible on a single Meet/Zoom/Teams screen. This is for the same reason why the best platforms are often the ones people initially built for themselves – you can’t get any closer to your user when the user is you.

In case you don’t have the luxury of having all stakeholders in the same room, there is a powerful tool you can deploy to bridge the gap: user watch parties. User watch parties are the equivalent of a focus group, gathering your engineers together to watch the user in the room next door through a one-way mirror as they interact with the platform. In actuality, you’ll simply record their computer screen and their voice (with their permission of course). All you need to do is recruit five test users and give them the same two or three goals to complete, using either the legacy platform you aim to replace or the MVP version of the new platform you’re already building. Tell them to think out loud, and voice any assumptions they are making and any confusion they may be experiencing.

You’ll be amazed to witness how even the smartest and most savvy test user will take longer than you thought they would, and get stuck in places you didn’t think it was possible to get stuck. It’s tempting to dismiss these anecdotal observations as outliers or to think that clearer documentation and additional training will cure all ills, but the reality is that you are witnessing, in its unfiltered glory, the true challenge that a new platform faces: the need to delight your users and make their work lives easier.

User watch parties also have the benefit of aligning priorities within your engineering team because everybody just witnessed the exact same thing with their own eyes and ears. Whereas before each team member might have had their personal favorite feature that they wanted to build next, it’s now painfully obvious which existing feature is the most deserving of your team’s attention. 

Question 2: Who is going to build it?

Ideas are easy – execution is hard. If you don’t approach this question self-critically, the team to build your platform will be the one that proposed the idea. This can be a tough pill to swallow, but lest we forget: this isn’t about you, your platform engineers, your Head of Platforms, or your CIO – this is about your users. You must form a platform team that best addresses your users’ needs first, and your personal ambitions second. 

Next, what should the platform team look like? In a nutshell, the ideal platform team is dedicated, small, and cross-functional. Better to have three engineers work full-time on your new platform, than to have ten people work on it next to their many other daily priorities. Yes, this will require dedicated headcount, as well as a strong executive sponsor to give this team air cover in its nascent stages of development. It’s how every digital native company sets out to build their internal platforms, and so must you.

Building a platform is a learning challenge, not an execution challenge, so quick feedback loops and shared learning are paramount to the team’s success. They will only succeed if they sit in close proximity to each other (physically or virtually) and their dependencies towards other teams are kept to a minimum. This close proximity is also essential in order to avoid the “not my job” trap, in which each individual only accepts work that matches their expertise or job profile. A shared “show me how” mindset allows the team to default to the respective subject matter expert (SME) but expects everybody on the team to be capable of solving any technical challenge.

Finally, is there a chance you’ll need someone else’s blessing to use certain services, e.g. the CISO or your enterprise architect? If so, make them (or one of their delegates) a core part of the team — at least until their contribution is baked into the platform in the form of policy as code and architecture blueprints.

Question 3: How will you measure success?

Nobody gains from a platform that is delivered on scope, on time and on budget, but that isn’t widely adopted. To mitigate against this, don’t measure your platform team’s success in these kinds of project KPIs. Instead, look to product KPIs, which measure the platform’s usefulness, adoption and user satisfaction. 

There is no one correct way to measure a successful software product, but successful answers to these three questions demonstrate progress:

How long does it take the user to achieve their goal? (less = better)

How many users use the platform and how frequently? (more = better)

How satisfied are users and how likely are they to recommend the platform to other employees?

At Google, we like to use the H.E.A.R.T. framework for many of our consumer-facing products. We also use a modified framework that we call S.U.P.E.R. for some of our internal IT platforms:

Go to them

We’ve explained why close proximity to your internal users is paramount when building a platform and we showed how you can regain some of that lost proximity by facilitating user watch parties. We’ve also highlighted the importance of creating dedicated, small, cross-functional teams and how to incentivize them to build a compelling platform that makes your employees’ work lives easier, rather than merely delivering one IT project before they move on to the next.

We’ve only scratched the surface of what it means to successfully plan, build and run a compelling platform as a product. So much more could be said about the importance of user personas, user journey mapping, and the true role of the Product Manager, to name just a few areas. 

If you take away just one thing from this article let it be this: you do not know what your users need and want. You only have hypotheses, which you have yet to prove or disprove. Just because you build it, does not mean that they will come. You must go to them.