A platform team is judged on something nobody can see. When the platform is doing its job, releases go out on schedule, integrations hold under load, and the teams building on top of it ship what they promised to ship, and none of that appears anywhere in the organization as platform work. It appears as the other teams succeeding, which is precisely the outcome the platform was built to produce, and also the reason the platform team's own contribution is invisible by design rather than by accident.
That distinction matters more than it first sounds. Invisibility that happens by accident can be fixed with better reporting, a louder demo, a standing slot in the review. Invisibility that is structural survives all of that, because the structure keeps regenerating it. Every improvement a platform team makes is consumed by another team and shows up in that team's results, so the better the platform gets, the more completely its effects are attributed elsewhere. There is no version of doing the work well that produces a visible artifact of its own, which means the absence of visible credit is not a signal that anything has gone wrong. It is the expected output of success.
I watched what that does to a team over a long stretch, and it does two things that look entirely unrelated until you have seen them sitting next to each other.
Nobody ever stands up in a meeting and says platform work does not matter. What happens instead is quieter and more corrosive. It arrives as the roadmap review that spends forty minutes on features and ninety seconds on the platform underneath them, and as the recognition that lands on the team who shipped rather than the team who made shipping possible. Nothing in either of those is a statement, so there is nothing to rebut, and that is exactly what makes them hard to answer.
Engineers read that accurately. They are not fragile and they are not asking to be praised; they are paying attention to where the organization puts its attention, and they are drawing a correct inference from it. If the thing you built is discussed for ninety seconds and the thing built on top of it is discussed for forty minutes, you have learned something real about how your work is understood, and no amount of internal reassurance changes the observation, because the observation was not wrong.
The other consequence is that a platform team gradually becomes the destination for everything nobody else wants to own. Ambiguous integrations, aging components with no obvious home, the pieces of a request that do not map cleanly onto any product surface: all of it drifts toward the platform, and it drifts steadily rather than arriving in one visible decision you could push back on.
This is rarely malicious, and reading it as malice will send you after the wrong fix. Leadership genuinely does not have a working model of what a platform team does, so the assignment logic they are running is subtractive rather than positive. Anything that clearly belongs to an experience team goes to that team, and anything that does not clearly belong to an experience team looks like it might belong to you, because you are the team whose boundaries nobody can describe. Over a couple of years that produces a pile of work you never chose, cannot point at, and are nonetheless accountable for when any of it breaks.
I treated the morale half as an internal problem, which is to say a problem to be solved with the team, inside the team. Reiterating their value to them directly. Picking one genuinely high-value piece of work and getting in there alongside them, all the way to the finish line, so the work was shared rather than delegated. Both of those were real and both of them worked, and both of them kept not lasting. Morale would rebuild over a few weeks and then decay back over a quarter or two, and it decayed whether or not the team was doing good work, which should have told me sooner what it was actually tracking.
The reason internal morale work decays is that it is an intervention against an outside condition that has not changed. Inside the team, the value of the platform is obvious; everyone there can see the dependencies, the incidents that did not happen, the release that went out clean because someone spent two weeks on something nobody else noticed. Reminding people of what they already know raises the temperature briefly, and then the next roadmap review happens, and the outside signal reasserts itself, because the outside signal is generated continuously and my reassurance was generated once.
What made it hold was the part I used to treat as an afterthought. At the end of something we had just delivered, I put the work in front of leadership in the terms they use to describe what the business got, rather than the terms we had used to build it, so that the recognition coming back down described what my team had actually done instead of thanking them for working hard. That translation is unglamorous and it is genuinely work, because the two vocabularies are not the same vocabulary and nobody above you is going to do the conversion for you.
The difference it made was out of proportion to the effort, and the reason is that specific beats warm, every time, with engineers. Warm recognition tells a team that somebody upstairs feels positively toward them, which is pleasant and carries almost no information. Specific recognition tells a team that somebody upstairs knows what they built, and therefore that the work has an accurate representation in a room the team is not in. That second thing is what actually holds, because it is evidence about the organization rather than a sentiment about the team.
Which is the part I would want someone to take from this. Morale on a platform team sits largely outside the team. It tracks whether the organization above it has any working model of what the team does, and it decays whenever that model is missing, no matter how well the team is treated internally by the person leading it.
And the same missing model is what quietly makes you the dumping ground. Both symptoms come from one absence. When nobody above you can describe what the platform team owns, there is nothing for recognition to attach to and nothing for unowned work to be excluded from, so credit flows past you and work flows toward you, for the same reason. That is why getting ownership named and visible fixes both halves at once, and why treating them as two separate problems, which is what I did for a long time, means working hard on each of them and resolving neither.
Building that model is the leader's job rather than the team's, and it belongs to the leader for a structural reason rather than a hierarchical one. The team cannot do it. Asking engineers to explain their own value upward converts the problem into more invisible labor for the people already carrying it, and it does not work anyway, because a team advocating for itself is heard as a team advocating for itself. The translation only lands when it comes from the person whose job is understood to be judgment about where effort should go.
It is also work that never finishes, which I would rather say plainly than dress up. Leadership turns over, priorities move, the model you built decays like anything else nobody is obliged to maintain, and you rebuild it after every reorg. What changes, once you have understood which half of the problem is load-bearing, is that you stop spending the effort in the room where it dissipates and start spending it in the room where it persists.