Foundational platform engineering practices: customers vs. stakeholders

When we talk about who really uses an engineering platform within the organization, it’s key to notice the differences. Some folks, like software developers and engineers, might use just about every feature almost every day. Others might only have a subset of the platform’s features they use regularly. Then there are those who only use the platform occasionally or in specific situations, whether they’re using many features or just a few.

Remember, the real customers are the ones who actually use the product. When deciding who to focus on first, start with the impact and value they bring to the organization. The same goes for choosing which features to add or beef up—think about who will use them, how often, and the overall value they’ll bring.

But then there are also plenty of influencers. These are people who aren’t actual users, but — thanks to their roles as leaders or decision-makers in other parts of the company — have a big say in shaping or nudging the platform’s requirements. They’re invested in the outcome and influence things from the sidelines—they’re not the customers. They are the stakeholders. 

Think about the automotive industry as an example. Car companies start life building only a certain kind of vehicle. Initial success comes from offering a single category, such as a high-end performance sedan. Ferrari is an excellent example of this. Ferrari built their first passenger sedans in 1947 and stuck to building only sedans, not trucks, SUVs, or long-haul buses. Eventually, in 2022, they came out with their Purosangue line which ventured into the SUV market. Ferrari was able to maintain their premium fast car brand first due to the prioritization and optimization of what was perceived to be the most significant potential customer pool for their core product. 

There are also many non-customer interested parties. Take state and federal governments, for example—they have a laundry list of requirements ranging from safety to taxation to insurance. Imagine if Ferrari decided to prioritize these government demands above all when designing their cars. They’d end up with a vehicle that probably nobody would want to buy. If the government set requirements so strict that they left no room for creativity or flexibility in car design, automakers would likely move their sales to markets free from those constraints. 

When you cater to stakeholders at the expense of your actual customers, you risk losing those customers. In the context of engineering platforms, this means you could miss the mark on your platform’s goals, rather than deliver the intended value, and see the proliferation of workaround solutions. Can you say “shadow IT”? 

In the figure below, you can see how the four different components – non customer interested parties, actual customers, traditional IT stakeholders and the engineering platform – relate to each other.

Many enterprise stakeholders, including finance, security, legal, and project management, will expect to have a say in the platform’s delivery. Traditional IT stakeholders may expect to own the technology capabilities found within an engineering platform through the siloes of networking, storage, computing, operating systems, middleware, Active Directory, and the like. 

If the expectation is that the legacy silos can remain and behave in legacy ways — while somehow wrapping an engineering platform around them — you will not succeed. If that were possible, adding the DevOps team would have been the solution. But it’s not about creating a wrapper; it’s about introducing a whole new way of working.

For an engineering platform to achieve its potential, everyone involved needs to agree on how we think about and deliver products. All stakeholders must align around the model of product thinking and product delivery. We will explain how his alignment happens through a simple scenario below.

What is the starting point for these stakeholders in this new product model? 

The most basic way to summarize this way of working is that Stakeholders must provide either: 

• A service interface (API) to the capabilities they own that enables all internal customers who need the capability to obtain it in a self-serve and self-directed manner (e.g., as much of the service as they need, whenever they need it) 
• Or well-defined outcome standards to which all impacted teams within the enterprise can self-solution

Take penetration testing as an example of a service interface. Typically, this falls under the Security Team’s umbrella. 

To fulfill the service interface requirement, the Security Team needs to set up a self-serve system. This way, any developer in the organization can grab the credentials they need, run scans on the endpoints they’re working on, and meet the security requirements—all without having to sync up or even talk directly with the Security Team. 

One might argue that this is a less-than-ideal outcome if the developer does not care about secure code. However, in reality, the developer is not only educated about why writing secure code is required, but also learns they can do it in the easiest manner possible. 

In practice, a security scan will become part of the platform’s reusable pipeline code library. No matter how the security scan service interface ends up being used, offering it as a self-serve option ensures the security team meets the requirements. Plus, this feature can be easily integrated into the engineering platform, or any internal product that needs it. 

The consistent application of this practice is one of the main reasons building an engineering platform on a cloud infrastructure provider, such as AWS or Google Cloud, is almost a requirement. Every service they offer is accessible via an API and designed to support independent, multi-tenant user patterns. While modern private data center vendors — such as VMware and Cisco — do offer products with comprehensive APIs, and there are open source solutions like OpenStack for creating private clouds, many enterprises struggle to implement these in a way that supports this level of usability due to their traditional IT operating models.

The second bullet above, well-defined outcome standards, is equally important. It is not typically the case that all stakeholders will have the resources or expertise to provide a service interface to their domain. 

In that case, they provide a well-defined and testable set of outcome requirements. A good example would be a security stakeholder defining corporate standards as:

1. Requiring a single source of truth for internal authentication and 
2. The internal product security standard is Oauth2 

An internal identity domain team could independently select and implement the single-source authentication service and provide self-service API access for teams building anything that requires internal authentication. But, if the existing solutions did not fit their product goals, an internal product team could self-solve an authorization technology and implementation so long as it meets the Oauth2 standard. 

So long as stakeholders follow one or both of these approaches, other internal teams are never blocked waiting for the stakeholder to perform work on their behalf nor do they have to create high-friction solutions for their customers.

When you’ve assembled a fresh platform engineering team, it’s smart to sketch out and maintain a stakeholder map from the start. Track all the stakeholders who impact the platform so you can identify situations where a stakeholder’s current or planned solutions or processes will not work with the Platform. 

Use a diagram like the one shown below to determine where the various stakeholders currently stand regarding their influence and alignment.

A Stakeholder Map like the one above can be used to evaluate a stakeholder’s influence over the backlog against their alignment to platform objectives. Ideally, high-influence stakeholders should be highly aligned to ensure platform success.

First consideration — how much influence does the stakeholder have or want to have over the engineering platform? In the example diagram, the VP of HR is neutral in aligning with the platform’s goals and has meager influence, as you might expect. 

The CEO is highly influential, though typically delegates their responsibility to others and attempts to reduce their direct influence beyond the broader corporate strategies.

In both situations, the neutral alignment may have no negative impact. However, the CTO is highly influential and much more likely to be directly involved in setting operating models or budgets that directly influence an Engineering Platform. Good questions to consider:

• Are they highly aligned, providing the platform engineering team with API access or outcome requirements? 
• Or are they unaligned, requiring the platform team to open tickets for needed configuration or conforming to existing operating models, whether they fit the needs of the engineering platform or not?

People can disagree for all sorts of reasons. It could be due to a real difference in strategy, or maybe someone just needs a little more time or resources to get in sync with the overall vision. An accurate and maintained stakeholder map is a highly effective way of tracking delivery risk from internal stakeholders and processes.

Quadrant 1 (Q1), of course, is where to focus. For each stakeholder in Q1, list their objections or constraints. Find the source of the constraints. Sometimes, a constraint imposed by one stakeholder results from a constraint placed on them by another stakeholder. At some point, a solution will be needed for each of these issues. Failing to do so will result in a miss in some aspect of the product vision. Each miss is a reduction of value, whether small or large. Enough misses, and the entire investment is at risk.

It’s really important to spot and keep an eye on any misalignments early on. This can really save you from a lot of criticism later on, especially when you’re diving into something as complex as deploying an engineering platform.

Introducing this platform means embracing a whole new way of thinking and working, which can sometimes bump up against the existing culture and processes. Making it clear what’s changing and how much change is happening helps prevent people from wrongly blaming the goals when things don’t pan out as expected. 

Being upfront and transparent about these mismatches early on is crucial to sidestep any later criticisms of adopting a product-centric mindset in such a tough project. To paraphrase G.K. Chesterton: It’s not that engineering platforms have been tried and found wanting. It is that they have been found hard and not tried.