You just wrote _exactly_ what I and others implored the new VP (for who knows what friends-hiring-friends reason) to make reality in the little company I just escaped. The idea of platform engineering NOT requiring other highly technical experts to stop their productive jobs to track weekly vicissitudes in helm/k8s configurations and blog posts was foreign to them. The company is in a downward spiral, but can't grasp why decimating productivity throughout engineering might be related. cartoons about dumpster fires come to mind (not joking) when I think of engineering there.

I hear you. Not passing judgment one way or the other as I don't know the details, but it sounds like your former team fell into the trap of allowing engineering teams to kick subpar outputs over the proverbial fence to one another.

The way you ultimately solve this is by aligning incentives, eg "platform engineers get fat bonuses/promotions when the products built on top of their platform kick ass."

well said

I get a bit frustrated by this view solely because internally, folks aren't _just_ your customer. They are your co-workers, and the same thing for them. Their co-workers are providing the platform.

The extra bit of empathy makes all the difference, because without fantastic personal communication, 'platform' could be a waste of time for everyone involved.

I think this is a good idea. You should treat the consumers of your services as customers, regardless of whether or not it's an actual end-user.

Exactly. Once you view other teams as your customers, it helps you focus on things like quality, satisfaction, and adding value in a very clarifying way.

And honestly other eng teams kind of are your customers. They may not pay you directly, but they also help to build your product and the company that cuts your (and everyone's) paycheck.

Regarding treating the other eng. teams as customers, I fully agree. I know it's not something everyone does (Been there, argued that), but when you treat them that way and when you deal with their problems (Service xyz requests are too slow, feature xyz would really solve our problems ...) you will, in the end, help the customers.

If my coworkers need my services, then that's because they are developing something that a customer needs. I think of it like a dependency-tree. As long as you trust your company to not have multiple teams develop something that will never see the light of day, or something the user doesn't want or need, then this mindset is absolutely a good one (Sadly been there, done that too).

Yup, it isn't perfect but provided that everyone is largely seeking the same goal (company success) it tends to get you to better outcomes.

Btw this can be true of other departments as well – for example, SaaS product marketing is often an entity that exists to serve internal "customers." Product management can be envisioned this way as well.

Good way to put it, but I feel its incomplete without adding

>And being able to effectively and quickly incorporate feedback from consuming teams into the product.

Without that, you can have a quality platform team pushing out good products, but if it doesn't align with what other teams need or you don't expose good override hooks, then the end effect is the teams will fragment into doing what works best for them.

Problem is, the other teams can't go somewhere else if the service sucks.

Yes they can. There's a name for that: shadow IT. All of a sudden you realize that the annoying engineers have stopped annoying you not because they become better people, but because they got the credit card of some VP and got their own platform on AWS.

Is it really "shadow IT" if they got approval from the VP with credit card attached? Seems like they're officially accredited to do the work.

Sure is, the VP is VP of Marketing and he puts the expenses under media research or something, and they put the whole company CRM data into Mongo or Elastic on AWS with no auth, open to the whole internet to see. And sadly that's more daily news than fiction.

This.

The things I've seen built with Excel and Access.

That's why the analogy is more akin to a local governmental services.

100%. This is why it's leadership's job to align incentives such that teams are motivated / rewarded for providing other teams with a high-quality service.

yes good product management is key even though your customers may not have a choice

Yup, for sure. Having PMs who understand infrastructure and distributed systems can be a secret weapon for high-scale businesses, especially in enterprise SaaS where competition is more directly head-to-head.