The Internal Platform Has Customers Too

Imagine a company introducing a tool to make work easier. There is a launch announcement, a training session, and a deadline to start using it. Then someone asks a colleague how to get something done. The answer begins: “First, ignore the manual.”

You do not need to work in technology to recognize the problem. Think of an expense system that still requires a separate spreadsheet, or a purchasing portal followed by emails asking someone to move the request along. The tool records the work. The people using it supply the missing pieces.

In software, an internal platform brings together shared tools and services so teams can build, test, and run applications without assembling everything themselves. It might provide a place to test a change, a way to publish it, or help working out why something failed. All of that is useful. But a platform can be technically sound while still making an ordinary task unnecessarily difficult.

So the question is who answers for that difficulty. Calling the people who use a platform “customers” should commit its owners to understanding their work and improving it. Sharing an employer does not make their time free.

The person approving the tool may never have to use it

Consider a developer trying to test a change before customers see it. The developer uses the platform, the team pays the cost of learning it and changing its workflow, and a director may have approved the investment. A security team may set requirements that everyone must follow. Each sees a different part of the same decision.

That is why I find it useful to distinguish the user doing the task, the internal customer depending on the service, and the people funding or setting conditions for it. Those roles can overlap. What matters is whether the people bearing the daily cost have a say, especially when the person declaring the platform a success never has to use it.

Some teams can choose an alternative. Others must use the company standard. A required platform can still be a good one, but its usage figures tell us little about preference. Where choice is limited, users need a way to influence priorities, a reason when a request is turned down, and a known route for needs the standard cannot meet. Asking for feedback means little if nobody answers.

The commitment includes the first attempt to use the platform, the help available when something breaks, and the effort required when it changes. The people who fund it must fund that work too. Approving the build while leaving support and migration to whoever has spare time is a promise the platform team cannot reliably keep.

Being available is only the beginning

A feature can be finished from its builder’s perspective and still be unusable for the person who needs it. Perhaps the instructions assume knowledge they do not have. Perhaps the feature has a name only its creators recognize. Perhaps getting access requires finding the right person in a chat channel. None of those problems appears in a successful technical demo.

Return to the developer who needs a place to test a change. I would measure the time from the first attempt to a working test, including the search for instructions, permissions, waiting, and help. Starting the clock after access is approved makes the platform look faster by excluding part of the user’s experience.

There is a technical name for the attention that all these details consume: cognitive load. In this context, it includes what a team has to learn and keep track of just to get its work done. A platform earns its place when it removes some of that burden. A long feature list does not tell us whether it has.

One useful approach is a supported default path, sometimes called a paved road: a prepared way to do a common task, with security checks, visibility into failures, and recovery built in. The point is practical: a team can use it without becoming an expert in every system behind it.

That promise has to hold up in practice. If every routine request still waits for someone to complete it manually, the form has improved how work enters the queue. The queue is still there. Calling that step self-service does not shorten the wait.

Some work should require a person’s judgment. An unusual access request or a risky change may need review. Make that boundary visible: what needs approval, who decides, and when a response is due. The problem is a routine task advertised as automatic that turns into a search for someone willing to help.

Listen to the problem before agreeing to the request

Treating colleagues as customers does not mean building whatever they ask for. Their request deserves attention because it tells you something about the work they are trying to do. The solution they propose still needs a hard look. A shared platform cannot remain manageable if every team receives its own version of everything.

Suppose several teams need to generate a report every night. They ask for different scheduling tools, but their underlying needs may be the same: run on time, report a failure, and allow a safe retry. A common service could cover those needs. If one report has a strict deadline or handles information requiring different protection, that difference is worth understanding before anyone dismisses it as resistance to standardization.

A useful refusal explains the boundary: this belongs with your application; we cannot support this variation; this would weaken a guarantee other teams rely on. It also leaves a workable next step. Saying no is part of running a shared service. Leaving a real need with nowhere to go is a decision with a cost, and someone should own it.

To understand whether the platform is helping, I would look at these signals together:

• Choice and continued use. Do teams choose the platform where alternatives exist, and keep using it for relevant work? Staying may also reflect the cost of leaving, so ask why.
• Time to a useful result. How long does a real task take, including waiting and assistance? Compare similar tasks before and after adoption, including repeat use.
• Work done elsewhere. What do teams still handle in a spreadsheet, a separate tool, or a private conversation? Find out which need that extra work serves.
• Recurring exceptions. Are different teams requesting the same missing feature, or does the platform serve needs too different for one default? Those call for different decisions.
• Repeated requests for help. Where do people get stuck? The cause could be unclear instructions, a confusing design, missing access, or a task the platform cannot support.

These signals belong alongside reliability, security, and cost. A pleasant interface cannot compensate for a service that loses work. Equally, a service can stay online all month while its users spend hours waiting for permission to do anything. Both count.

Start small: watch someone outside the platform team complete a routine task without coaching them through every step. Record where they stop, whom they contact, and what they do outside the tool. Improve one recurring obstacle and observe the task again. That gives a team a concrete problem to fix and a way to check whether the fix helped.

Making it mandatory does not settle the question

A company can have sound reasons for requiring a shared platform: consistent protection of information, supportability, or the expense of maintaining several overlapping systems. Those reasons deserve to be spelled out, and they should still hold up after an honest count of what adoption costs.

If teams still need parallel tools to finish the job, count that work. The organization may be paying to maintain the platform and to compensate for its gaps. Moving those costs into other departments does not make them disappear. The same applies to the time needed for training and migration: someone must make room for it among existing commitments.

A workaround is worth investigating, but it is not automatically the better solution. It may skip a necessary control, depend on one person, or create maintenance work later. Compare what each route actually requires and protects. The aim is a shared path people can rely on, with justified exceptions where it cannot meet the need.

That responsibility continues when an old feature must be retired, whether because a better option exists or because the old one can no longer be supported safely. Identify the teams that depend on it, explain what replaces it, and agree on a transition they can carry out. A retirement date without migration support leaves the cost with people who may have had no say in the decision.

When people cannot leave a service, its owners have fewer reasons to assume silence means satisfaction. They have to go looking for the friction. In the opening scene, the colleague explaining how things really work is doing that job informally. A platform team should want to hear the rest of that conversation.

Source notes

These sources ground the discussion of internal platforms and cognitive load. The workplace scenes and report example are hypothetical. The questions, distinctions between roles, and recommendations are the author’s practical interpretation, not findings from a study.

• Internal platforms as products. The CNCF App Delivery Technical Advisory Group’s Platforms White Paper describes user-focused platform design, self-service, and assessment through user experience and delivery outcomes.
• Shared services and cognitive load. Matthew Skelton and Manuel Pais’s Team Topologies connects platform work with helping other teams deliver. Its official key concepts explain platform teams and the limits on how much complexity teams can handle.