The best platform teams are almost invisible

I want a team that can operate without me

As a leader, I want my team to work confidently without depending on me. They should understand where we're going, why we've made certain decisions and what they can decide for themselves. If everything stops when I'm unavailable, I've left too much dependent on me.

That takes trust. It also takes time spent explaining, listening and sharing knowledge. I want people to challenge an approach when they see a better one. I want them to teach what they know so someone else can do it too. That gives them room to learn something new themselves.

I apply the same thinking to a platform team. Its expertise should help other teams become more capable. Good documentation, sensible defaults and reliable automation let people do more for themselves without having to learn everything we know.

Suppose a team needs another environment using a pattern we've already agreed. If someone has to raise a ticket and wait for us to repeat the same setup, I'd ask what is stopping them from doing it themselves. Could we give them a supported way to create it, with the right access, logging, ownership and cost information already included?

They still need to understand their application and their responsibilities. But they shouldn't have to rediscover all the infrastructure decisions we've already made.

Removing that dependency is a useful result. The team can get on with its work, and we have more time to improve the platform. I also like putting solutions in place that give us a good foundation to build on. I want each piece of work to make the next one easier, without trying to design for every possibility upfront.

Being needed for every request would make us busy, but it wouldn't convince me we'd built a good service.

There are still good reasons to need us

I want platform engineers involved in new ideas, difficult problems and decisions that affect other teams. That's where their experience matters. A conversation early on can save everyone a lot of trouble later.

Independence can go too far. Giving people a complicated tool and expecting them to work everything out themselves just moves the effort onto them. If they now need to become infrastructure specialists to deploy their service, we should question what we've built.

Some work is unusual enough that helping someone directly makes more sense than automating it. And when something breaks, people need to know who to call and trust that they'll get help. A platform team should be easy to reach.

The distinction I care about is why we're involved. Working through something new together is valuable. Having to fix the same problem or approve the same routine request every week should make us ask what needs to change.

I want common services and standards where they help, with room to discuss requirements that don't fit. If the answer to every unusual request is simply "we don't support that", people will eventually find their own way. Shadow IT and shadow platform engineering can be signs that the supported service isn't meeting the need. Before blaming people for working around us, I want to understand why they felt they had to.

That's why I've argued that the safest route has to be the easiest one. We need to make the supported option good enough that people want to use it.

Almost invisible still takes investment

When a platform works well, it's easy to miss how much work keeps it that way. Someone is maintaining it, fixing vulnerabilities, testing changes, planning capacity and making sure it can recover when things go wrong.

Fewer requests for help don't mean that work has disappeared. They may mean the investment is working. Cutting the team's capacity because nobody is complaining risks undoing the very thing that made the service successful.

Security and operations need to be part of that investment together. If we're paying to identify risks, we also need people with the time and skills to fix them. I want those teams planning together so the security requirements are practical to implement and maintain.

The same applies to automation. I'm a big believer in Infrastructure as Code, but it takes people, training and ongoing care to get it right. For a small company, that can be a significant commitment. I want to know what we're getting back for the effort.

If we're doing the same work repeatedly, I'd want us to look at automating it. If we're still figuring out what we need, doing some of it manually can be sensible, provided we understand the risk and record the changes. Just because we can put something into code doesn't mean we've made it easier to operate.

I'll explore that judgement further in the next article, Infrastructure as Code: when it is the right choice. Here, my concern is whether what we've built helps people get their work done or gives them another system to struggle with.

Show me whether it's helping

I want to know whether teams can develop and operate services smoothly using what we provide. How much ordinary work can they complete without waiting for us? Where do they get stuck? What keeps coming back?

We should look at waiting time, repeated requests and how much work teams can complete themselves, alongside reliability, recovery and cost. Then talk to the people using the platform. A falling ticket count could mean we've made their lives easier. It could also mean they've given up asking.

Platform leaders need to be able to explain the value too. Which services depend on us? What work have we saved other teams from having to do? What has improved, and what still needs investment? Almost invisible to someone doing their daily job shouldn't mean invisible to the people deciding where the company spends its money.

In my article on AI-native engineering, I asked what happens to the rest of delivery when implementation gets faster. This is part of the answer. We need platforms and teams that can support that pace without every change joining another queue.

I'd be pleased to hear a team say they rarely need to think about us because the service works and they know what to do. I'd be less pleased to hear how grateful they are that we're always available to carry out the same task for them. I'd want us to help them get past needing us for that.