How a platform team should take requests from other teams

A platform team has an unusual problem with requests: its customers sit twenty metres away, know each engineer by name, and are blocked until they get an answer. So requests do not arrive in a queue. They arrive in a direct message, in a stand-up, in a pull request comment, and each one is small, reasonable and urgent to the person asking.

The same is true of any team other teams depend on: data, security, developer experience, infrastructure. What follows is an intake process sized for that situation, which is different from intake for a product team.

What makes a shared team's intake different

• The requesters are engineers. They arrive with a solution ("add a flag to the deploy tool"), not a need. The need behind it is often cheaper to meet another way.
• Every request is someone else's blocker. So every request is urgent, and urgency stops carrying information.
• The requesting teams cannot see each other. Each knows what it asked for. Nobody but the platform team knows the total, which is why the total is always more than fits.
• Half the work is not project work. Questions, access, a broken pipeline: support that has to be answered today and should never wait for a planning cycle.

Two doors, not one

The most useful single change is to separate what is support from what is a request for the platform to change.

Support is "this is broken" or "how do I". It goes to a rotation: one named engineer this week, one channel, answered the same day. It is sized as a standing line in the team's capacity, the same way keep-the-lights-on work is, and it is not planned item by item.

Requests for change are "the platform should do something it does not do". These go through the other door, get a decision, and compete for the capacity that is left.

Without the split, the rotation engineer builds features in the gaps and the roadmap is interrupted by questions. With it, a direct message has an obvious answer: "that's support, ask in the channel" or "that's a change, put it through the door".

What the door asks

Three things, and none of them is the solution:

1. What are you trying to do that you cannot do now?
2. What does it cost you while it stays this way: time per week, a blocked launch, a risk?
3. Is there a date it is tied to, and what happens on that date?

That is the same three-question intake form any team should use, and it matters more here. Asking for the need first is what lets the platform team answer "you can already do that with X" or "three teams have asked for the same thing differently". A request that names only a solution is a topic, not yet a request, and it goes back with one question the same day.

Decide in the open, on a rhythm

Once a week, the platform team goes through what came in and gives each request one of four answers: we will plan it, we need a short look first, not now (with a date we look again), or no (with the reason). The answer goes back to the requester in writing that day.

Publish the list. One page that every requesting team can read: what the platform team has committed to this quarter, what is parked and until when, what was declined and why. This does more than any prioritisation method, because it lets the requesting teams see each other. A team that reads that its request lost to a security deadline argues much less than one that was told "we're busy".

When two teams both need it first

The platform team should not be the one to choose between two product lines. It can say what each request costs and what fits; it cannot say which product matters more. When the capacity runs out between two requests from different teams, the order is set once, by someone above both teams, and the platform team works down it.

The alternative is that the choice is made anyway, by whichever requester is more persistent or better connected. That is the side channel, and a shared team is where it does the most damage, because each favour is paid for by a team that never finds out.

What not to build

• A long request form. Engineers will fill in a twelve-field form once, and then go back to direct messages.
• A priority field for the requester. Everything will be P1. Ask for the cost and the date; priority is the team's decision.
• An SLA on changes. Promise a decision within a week, not delivery. A delivery promise made before sizing is the thing intake exists to prevent.
• A ticket for every question. Support that takes five minutes should take five minutes.

If you use DeliverySheet

The product covers the second door, requests for change, and does not try to be a support desk. A request is captured as pasted text and enters the process only when it states the need plus who it affects or why now. Each one then gets one of four recorded decisions: plan it, run a time-boxed discovery, park it or decline it. A park needs a reason and either a review date or an explicit choice to park indefinitely; a decline needs a reason. Capacity is agreed per team when the work is planned. The published list is the workspace itself: requesters who are members can read the parked and declined demands with their reasons. Every member signs in with Google.