This is Shi Hi, this is Shy Mittal at Pfizer. Um Welcome to the session and about how we and Pfizer uh have moved from a project driven platform engineering approach to a product engineering approach focusing more on our customers, which are developers, internal developers.So we're gonna start this off with. Hello. Uh Hold on and I might not be able to see um all the hands, but I would like to know how many and we, we could just do this as an exercise. Raise your hand if you're a developer uh in your organization and you rely on tools, platforms maintained by another team within your company to develop deploy, run monitory applications. I I'm not sure I can see all the hands um being raised, but I'm assuming there are quite a few here. So if that's the case, if you are one of those developers, let me ask you if this looks familiar if this sounds familiar to you. And one of the, the one that uh is most uh when I was most surprised by or found the most interesting is uh feedback from developers and, and our organization there lies there is a team that actually does some manage one of the platforms that they had been trying to go engineer themselves.

They were very surprised. So not only were they running into issues trying to use some of the platforms we have, but they, some development teams didn't even know we existed or we could do, we did some of the work for them. And that was an aha moment for not only the development teams but folks within platform engineering. Um So I I don't know how many of you are familiar with team topologies, but one of the th this has been a framework we, we've been studying for quite a while and have kind of been trying to understand map out how this applies to us. That's why. So um the, the, the few constructs I'll just go over quickly because they're important to understand uh how, where we are and how we've shaped. Our journey is the concept of these yellow lines which are teams that are generating uh basically your development team, product development teams or they're called steam uh stream aligned teams. They're generating value, value stream goes back to that. Um And they are uh they are the ones driving business value outcomes.

And there are teams that are the, the blue team here, which is actually a platform team trying to, to do things so that these uh to add value to these streamline teams so that those teams can move fast and take care of higher order problems than the lower order problems. Like, hey, I want to create a VM for my application. I want to uh figure out how to monitor my database. Uh Th those kinds of things can be handled up and down here rather than up into these uh individual teams. Because there's a and the, the theory is all about reducing cognitive load on those streamline teams that have to not only address end user pro problems or market changes, but now also have to figure out how to do things at a lower level in, in the infrastructure. So that's kind of the concept around platform uh teams and stream aligned. And then there are other teams, the, you know, complex subsystem teams and enablement teams that I don't get into. We don't have time for that. Um But the their interaction models, what do you offer as a service? Where do you spend time um actually sitting down and facilitating some of the work that these streamline teams are doing? And so the the the collaboration models that we have focused on are essentially how much starting with more facilitation moving towards as a service. So this is where the shift from project to project starts to happen.

Um So kind of starting, you know, if you, if you if you Google platform as a product, there are lots of commentary that comes up. And I think this, this is the one that resonates the most. With me and my teams, it platforms with a product mindset, focus on higher order uh in solving those common denominator issues so that the development teams can focus. Internal development teams can focus on higher order problems to solve. Because that's, that's where we get revenue.

That's, that's what makes the business money. So we, we need to focus on let those teams focus on those concerns that then those lower order concerns that I talked about earlier. So I again, this is another representation of what I think we just talked about in the apologies focus on is this is where the Pfizer platform team sits. We have view a DEV teams, but we also have SRE teams that are focused on keeping the lights on making sure uh those platforms forms are in uh being set up in production for high availability, reliability um from an application site. Uh not from the platform side, but an application side, we're deploying those applications to be highly available, highly reliable and managing the day to day operations around that. They are also relying on the platform team to take those under pinnings and make them highly available, highly reliable, secure.

And so I taking that next uh to what, what is the platform engineering team? And at this point, you're asking what is, what platforms are you talking about? Well, we we in platform engineering focus on making sure that the most used technologies are made available to our developers in a cost effective, robust, incredibly secure uh and flexible manner. And those platforms could be uh I'm very, I, I'll just talk about a few. We have uh a cloud infrastructure team, we have uh our uh on prem private cloud infrastructure team. We have container platform teams, api management teams, even streaming platform team. And so we have many of these shared platforms that many development teams use that we see value in managing uh the iterate and managing and iterating on uh continuously and bringing that product mindset. So I, I've been talking about this product mindset, right? And what is, what is it that I'm actually getting to is the the thought about focusing on developer experience. So when we initially talked about that at Pfizer, it was, it was are words, what, what does it actually mean? What, what does this mean for developers? What does it mean for uh the engineering teams themselves? Uh Do I really need to change what I do from a day to day basis? And that's that caused the, caused us to step back and say, well, where are we and how do we move into that model?

And where we were at that point? This is about 3 to 4 years back. We were in a project mode, a development team would come to uh uh you know, infrastructure teams and say I, I'm building this capability. Uh I building this product, I need uh to expose API si need uh infrastructure. I need V MS for my uh on my da the data centers or I need to use this cloud uh capability or public cloud uh provider. And we would have people engage with that business unit team on a in a project level. So project would get spun, a project manager assigned uh people from the infrastructure team start to work with the development teams on all of those aspects that they are looking to for, for us to help with. The problem is at some point, it's not scalable. We don't have no, no, no platform team had enough resources to give to all projects. So we end up becoming a bottleneck. But also we don't see the, the effect that the solutions being effective because they are scoped at the project level. So if we created a new way to an automation for uh using a cloud service, but that may be scope to that project may not be visible across the enterprise.

And, and I say that with a bit of um you know, great assault here because there there is still a platform engineering team in play and they are sharing information across and there were lots of efforts to bring people across those platform engineering teams to to start talking about what they were working on.

But it was always hey, we did this and we, we were thinking of doing this but not concrete enough in terms of, here's the timeline, here's what the features that will be. And here are the teams that are depending on it uh from a business point of view or internal platform teams that were dependent on other platform teams. So it was very much uh uh just a normal, you know, organic information sharing. Um very quickly realized that since we are having a bit of a problem with E one platform engineering uh person or engineer looking at 20 projects uh that they are participating in and really multitasking or context switching so often, but also just burn out, right? So kind of went to the next stage, which kind of makes sense from a change perspective to be smaller step is let's let's build a single work track, let's at least make all the work visible and start reviewing that as a team as a as project product, uh a platform team rather than a project team.

And this, this is where this took us a while uh about 3 to 6 months uh depending on which platform engineering team we were talking about. But it also helped um kind of elevate some of the roles they were seeing. Oh, somebody needed to talk about what we should be, what are the, what are the capabilities we're actually building across all these projects? And do we need, do we need a product owner, product manager? Um And so we started having those conversations and that's where we we actually recognized, we needed a product owner, we needed somebody to uh uh front in the conversation of what we should be building. And that got us to the next stage where we started publishing Road Maps and actually started doing quarterly planning. What are the requests that have come in for this platform? You know, let's talk about even streaming or our cloud platform. What, what are the requests that we're getting and how do we uh take that prior? Uh not, not even just prioritize initially, let's collect them in an idea portal and then start defining the, you know, what, what is this feature? Get them into a road map which we think makes sense what we can do based on what we know at this point and what they ask and start communicating that road map and that, that actually started uh helping us with what are our identity also?

What are we doing? What is it that we're creating quarter after quarter that leads us to the next thing? Oh, we're creating this, what is the impact we are having? How are we doing with the uh with on the operational metrics around uh running this platform? Um You know, are there, are we spending too much time in uh troubleshooting and operational issues or are we actually working on creating new features? Because at some point, if you're not spending too much time, you know, firefighting, you don't have that much capacity to actually work to feature work sounds familiar to other developers, but it wasn't as evident to all of the to all of us at this point. And so we kind of shifted toward understanding what our capacity was to work, do feature work, what our sizing, what is, how much is this feature in story points. And, and so that kind of led to a better uh viewpoint on prioritization. Also, uh we, we realized that to, for us to uh have a better, have better feedback from our uh consumers or customers which are developers, we needed to get out and talk to them more. So that resulted in things like office hours or platform engineering. A lot of newsletters are publishing to say what were we working on what and what impact we were having and as well as just evangelism through any community, we created a developed, we have a developer community which is 2000 plus people strong that and growing every day to talk about what we're building on.

Here's the next phase we are stepping into now, we're realizing we have all these platforms, but the developer sees them as one black box or not black box, but one thing and they want to be able to use that platform to build their application. So they're not seeing multiple platforms, they're seeing one platform and that help kind of starting to focus us on what is the user journey across these different, define a developer trying to migrate my application into public cloud in a public cloud provider. What are the things that I might have to do? And that touches many platforms today within the platform engineering. So we've, we've done the work on defining user personas which is more than developers operations um as well as it's not the same. All developers are not the same.

There's some that are working on public cloud migration. There are some that are working on just deploying and on prem application uh mainframe uh applications. They're the different problems that they have. So we've, we've kind of defined the ones that we think are the more uh are the little customers of our pla our platform. We are mapping with you the journeys and identifying pain points and then starting to think about how do we take an api first approach to our platform? How do we make this touch less? So you, you as a developer don't have to uh talk to so many people, you are able to go to a a portal, look at all the platform API S, wire them into your pipelines in your uh in your applications and start using them. And we gather more, more metrics on usage and effectiveness from there on. So this is the, this is the stage we are at right now and um I know I'm almost at the end of my time at this. Uh So th this, this has been really exciting for uh our, our teams that it's, it's a lot of change for a lot of teams which were focused on basically making sure the platform was engineered in a way that was secure and operational and we manage the operational metrics around it.

But how this is our shift to managing the developer experience. And basically, that's the main thing how we are shifting from engineering focus to developer experience, focus it through, through this entire journey. I know there'll be a few questions and I'm I'm looking forward to hearing about those.

Oh coordinators. I don't know if we switched to questions now or later.