Multi-Persona Platforms Shape with Pankaj Gupta | Platform Engineering 2.0 Ep 3
Multi-Persona Platforms Expand the Audience
Multi-persona platforms are becoming a defining requirement for Platform Engineering 2.0. In episode three of The Platform Engineering Show, Alan Shimel and Pankaj Gupta of Broadcom discuss why platforms can no longer serve only application developers and platform engineers.
Gupta explains that Platform Engineering 1.0 focused heavily on developer productivity. Internal developer platforms helped developers reduce cognitive load, use self-service environments and move code toward production more efficiently. That remains important, but it is no longer enough.
More Teams Need the Platform
Platform Engineering 2.0 expands the platform audience to include data scientists, machine learning engineers, security teams, compliance teams, SREs, DevOps engineers and business leaders. Each group needs a different experience layer, abstraction model and set of controls.
Multi-persona platforms must support those needs without creating a separate toolchain for every team. The goal is to avoid a fragmented Tower of Babel where each function builds its own platform. A shared platform can provide consistency while still adapting to each persona’s workflow.
AI Agents Add Non-Human Users
The conversation also highlights the rise of non-human personas. AI agents are becoming active participants in software delivery. They may write code, trigger workflows, run tests or interact with platform APIs in ways that once belonged only to human users.
That shift creates new requirements for permissions, guardrails and accountability. AI agents need access to platform capabilities, but they also need clear limits. Platform teams must know which actions require human approval and which can safely run through policy-driven automation.
Platform ROI Needs a Broader View
The episode also questions whether traditional developer-centric metrics are enough. DORA metrics remain useful, but platform value increasingly depends on security, compliance, operational resilience and business alignment.
For enterprise leaders, the takeaway is direct. Multi-persona platforms will help organizations scale Platform Engineering 2.0 beyond developer productivity. The next generation of platforms must serve humans and AI agents through governed, role-aware and enterprise-ready experiences.
Transcript
0. This is episode three. The first two episodes have been great.
I encourage you to go check them out if you haven't had a chance to already. You don't necessarily need to, to understand what we're going to talk about here, but they're quick 10, 15-minute interviews. Or episodes.
So I highly encourage you to do it. My partner in crime on this whole series is my friend Pankaj Gupta from Broadcom. Pankaj, welcome back.
It's great to have you here for episode three. Thank you for having me. 0.
In episode two, we discussed that first pillar, which was AI native. In episode three today, we're going to discuss pillar number two, which is the multi-persona experience, and I don't know if persona's the right word, because it's not necessarily a person. Sometimes, but we call it multi-persona.
0, Pankaj. Right now, who's the platform actually for, and who's been left out? The primary audience for current platform for last few years has been the developer, end developer.
And that was a very critical need platform engineering solved for that, increasing the efficiency of a developer, removing the cognitive load from them, instantizing the processes for taking code to the production across various developer teams for them. Increasing the efficiency of developers by giving them the IDP platform, so they can, instead of opening the tickets, they can do a self-service involvement generation for that. It also help them to be responsible more for security, for taking care of a shift left requirement.
That's why the primary persona for that, and that's what they get measured on. The second persona who helps and uses the platform is platform engineering themselves, because they build the platform and offer to the developer organizations. So that's mostly in last history of platform engineering has been the primary persona, but now things are changing.
There will be more human personas as well as non-human personas also. And that, I think that's a key piece of it, the non-human persona. Look, I will just tell you, I'll add to that from where I sit.
When platform engineering first burst on the scene, there was the whole marketing, is platform engineering replacing DevOps? Is DevOps dead? No, DevOps was never dead, and it doesn't replace platform engineering.
But what I have seen happen is that DevOps engineers rely on the platform to get their job done, because what DevOps was missing prior to platform engineering was those guardrails, was that platform that allowed them to do CI/CD, that allowed them to work closely with the developers and do this. So, I think what happened is you're 100% correct. The platform was built primarily to allow developers.
And that is where they get measured on. The DORA metric is all about developer productivity, which is a gold standard for that, or how fast you deploy the code or agility. Those are the matrices, the way the platform's ROI is measured today.
So I remember when the DORA metrics came out with Gene and Jez and Dr. Nicole, and they envisioned a time where the developer did the release, and the developer almost became the DevOps engineer, if you will, right? I don't know if it's worked out that way.
I think when we look at DORA today, we need to look at the rise of the SRE. And we're going to talk about this as we go into the six different personas. But the rise of the SREs, the DevOps engineers, the rise of non-human players in here, QA, the security people.
0 is we all need a platform. We all need a platform. And better to have a singular platform than we each have our own platform, and it's a Tower of Babel or something.
But that brings us to moving on. 0, we talked about platform teams serving six different personas. Mm-hmm.
I think we need to define them. I mentioned a bunch of them, but let's clearly define them, Pankaj. I think the two we already covered, the application developer and the platform engineer itself.
Mm-hmm. But three new human personas we're already using or want to use more efficiently the platform for that. One is the data scientist.
Mm-hmm. A second one is engineering and the business leaders for that. Third one is the security and the compliance need.
Those are the three human personas. Fourth one is non-human personas. Of course, not the alien, but the AI agents.
But the bigger point before we go into each persona is that each of these personas will have unique platform needs for that. Each of these personas will require their own experience layer for that. Each of these personas will need their own abstraction.
They will require their own intelligence for that. So the task for platform engineer is to understand and manage the roadmap for each of these different personas' requirement for that. If we talk about the requirements today, let's just start with a very simple one.
The most burning one is the data scientist and the ML engineers. Their requirement is going to be more self-service GPU provisioning for that, model registries, and model servings for that. Their requirements is going to be more experience or experiment tracking for that.
These are the unique requirements these will have, and platform has to serve it. If you move to the second one, where a lot of investment or additional investment is just going to come from engineering and business leaders for that. Their requirement is going to be more FinOps transparency for that.
They will also look at the metrics to measure the ROI for that. They will also require a lot of predictability for the FinOps part of that, so they will have unique requirement. Security and compliance teams is going to expect that the agents work in very strong guardrails for that.
How I deploy the security in a more efficient way for that. Policy as a code for that. Today in platform engineering, the compliance is static or time-bound.
You run this compliance check every three months or a year, whatever the frequency. Why it can't be the continuous over here then? How the platform enables the auto remediation when the agents are become a very critical part of the citizens for the platform.
So those are the three human personas unique needs will be there. And same is true for the AI agents for that. AI agents will use the APIs from the platform for that.
They will also expect a lot of audit logging will be required for that. They will also require more scope or definition for that. 0 becomes so simple to understand.
It is the binding force. The personas are the binding force. And that's true in a lot of technology, it's true in a lot of businesses, Pankaj, is that you've got to start with the people it's serving, the audience it's serving, and then you build your foundation on top of that.
So when you look at the five pillars here, they're really built on top of the who's it for? Yeah. Now, look, you could quibble over the six different personas.
As I mentioned, DevOps, SREs, some of the ops people. Being a security person, to me, there's a difference between compliance and security, right? Yeah.
Compliance is sort of least common denominator kind of stuff. We're true security. And then when you add AI into the mix, it really-- Because you got things like Mythos.
Now, all of a sudden, we're finding vulnerabilities. Well, we got to fix these vulnerabilities. We have to remediate.
We have to mediate. And whose job is that? I need a platform for that.
Yeah. And it has to be this platform. I don't want a separate platform.
So now the remediation engineer is different than the security engineer, because generally the security person doesn't fix it. They find it, they notate it, et cetera. Even the data scientists, I've heard them say that it's not data scientists anymore, they're data engineers.
Everybody's an engineer today, right? Yeah. So I think that that winds up being a fluid.
These personas are not necessarily, they're fluid. This is how they exist today. We may see different ones come in and go out.
But the important thing is, and that makes the platform choice important, right? You need one platform that satisfies them all, that serves them all, and it's a different experience. And I think that's where the infrastructure is so critical for that, having the right infrastructure for that.
Yeah. Because this infrastructure is going to serve multiple personas, human and non-human personas. Absolutely.
I want to combine the last two pieces of this episode, as we're running low on time. We need a great platform, as you just said, I mentioned, that understands the difference between, let's say, a data engineer, data scientist, versus a developer, that understands the difference between a security person and an SRE, understands the difference between an agent and a human. How does the platform team wind up owning this whole thing?
Is it too much for any one person or any one team to own this for the entire organization? Yeah, it looks like a daunting task for that. But I think each organization or each IT organization has the priority where they have to focus, and that's the reason, the evolution.
Maybe for certain organization, data scientist, or as you say, data engineer, is the most important thing to serve today as a new persona for that. For some organizations who is, especially in FSI, they are building a lot of AI agents for that. That will be a very strong requirement for that.
Maybe if you are in a very regulatory or recently breached there, maybe the security and compliance is a very strong requirement. But platform has to serve all of them eventually for that. And that's where each platform engineering team has to use the platform or infrastructure as a product and build a roadmap that what, when, who they are going to serve in phases for that.
Agreed. Pankaj, that brings us to the end of episode three. This one went too quickly, it seems like.
We just thought, there's so much meat here on these bones. But again, I encourage everyone, go check out prior episode one and episode two. We will have episode four next week.
tv, on the Techstrong OTT app, on just about any screen you like to watch videos on, or the TechstrongTV YouTube channel. So you can check them all out there. Pankaj, my friend, thank you for coming on.
We'll see you next week for episode four, okay? Thank you.
