**Person A**: All right. Let's jump in. The first set of questions, we want to just learn more about your personal background there. And first, we'll directly be like, how long have you been working on platforms?

**Person B**: Yeah. I mean, it's hard to tell. I really started knowing about platform engineering back at KubeCon 2022 in Valencia. That's the very first time I really heard about that as a practice. But obviously, I mean, there is a lot of things that are common sense. If you take DevOps perspective, that was best practices. So I can't say that before 2022, I didn't do anything that could qualify as platform engineering, but obviously I was a little more structured and doing things as platform engineering best practices from that point in time.

**Person A**: Do you see a trend across the projects you're working on? What's the maximum lifetime of the platforms?

**Person B**: It's very hard to tell because as a consultant, obviously, I build an IDP or whatever I'm building, then I give back the key to the clients, make sure that they are self-sustaining, maintaining it, and I'm going to something else. It's hard to tell, okay, I have an IDP that has been running for three years, but I know that the previous client I started building an IDP—calling it an IDP after KubeCon 2022—and I know they are still using it. 
No, I mean, obviously, except if you start a company from scratch, there are things in place, and you can't just say, okay, we will take everything away and build the IDP, and everything that existed before is legacy, and everything building is the new thing, and you have to use that. Obviously, you have to start from where you are and build it incrementally. You can't say, okay, we will stop everything for six months, build an IDP, and then we will start using it. So yeah, it's always incremental. The first project I had was they were moving from Azure to AWS, and by—I mean, all the projects that were currently being developed in Azure that were starting from nothing knew that they would have at some point to tear down everything and rebuild it in AWS. And they were using very Azure-specific resources. I mean, but the infrastructure was very Azure oriented; everything was built out of containers, but they were using services that are—so yeah, it was okay. They are building containers, so let's spin up a Kubernetes cluster in AWS.
They are building the AWS cloud infrastructure, but we don't want to just say, okay, here is the cluster, build something up on it, because then we know that when we move from AKS to EKS, you will have to rewrite all the lower levels of the infrastructure. So we built a very minimal IDP so that they could create the application and refer to things that were not Azure specific. And when we deployed the equivalent in EKS, they would just move over—it was a value file that was kind of acting as a manifest—they would just move over everything and expect everything to work in EKS, and that's what happened. So I did not start saying whatever you are building, I will build something in EKS, and then when you will move everything over, right?
Starting by building something that they could use right away. And then when they were ready to move—I mean, when infrastructure was there—it actually was kind of funny because at some point, some of the engineers were not aware that we moved the infrastructure to AWS. Most of them were aware, but some, I don't know, missed emails. They were like, where are my pods? I can't see them. In other words, everything was running exactly the same. Everything was moved away, and nobody noticed. So that's a thing—yeah.

**Person A**: Because you used the IDP word, did your customer there have the understanding of—did they call it a platform before, or did that start with your work?

**Person B**: No, I didn't call it a platform at all. It was just calling it other service or the boilerplate and those kind of things. But the word IDP came later on. After I went back from KubeCon, and I put the names.

**Person A**: Perfect. All right. With splitting those different services, right, did you work as part of a designated platform team, self-identified platform team, or is it multiple platform teams? Is it a platform team at all?

**Person B**: Yeah, it was not even called a—we called it platform later on when—so I was part of the DevOps. My team was called DevOps, and we had a cloud team that was separate. So that's one of the reasons I couldn't build everything in AKS directly, that I had to wait for the cloud team to build their cluster in EKS in AWS. And at some point, we merged the two teams because we were really working very integrated. So it made sense to have us closer together. And at that point, we were called the platform team, but it was after, one year after we delivered, and we started using the IDPs.

**Person A**: Is that also an experience that is the same across other customers as well?

**Person B**: Yeah, so the project I'm in right now, we are not called platform at all. They have something different called platform though, which is sometimes a bit confusing. So I really refer to IDP instead of platform. The platform's the core of all the business application is written in this PHP thing, and they call it the platform, but it has nothing to do with results when it's just—they call it that way.

**Person A**: All right, and so even if we take the DevOps team that later became the platform team, what was the typical size of those teams you worked in?

**Person B**: So yeah, I haven't mentioned it, but I have been working mostly with small companies, so it's not like—it was a very small company. So DevOps team, really before merging everything, we were three people. Here, in the current mission, it's a bit worse, but we have been understaffed for quite some time. We were two guys, and one—the other guy left, and I'm alone right now. There's another guy coming in, I think, today or tomorrow. So we will be two. And the company has the intention to grow the team because we have been understaffed for quite some time. And we are serving—I can't, from my experience. I have a ratio of one DevOps for ten developers, usually. That's ballpark what I've been. Here we have, I mean, one DevOps right now, which is very low, for fifty developers. So it's very intense. The previous mission, we were—as I said, three DevOps, then we merged with the cloud team. We were eight in total of six teams. Yeah, some people came in and out, but six, seven to serve roughly—yeah, a lot of people getting in and out also, but thirty to forty, forty developers.

**Person A**: All right. That's an interesting photo definitely. So especially with the team that has five to six people in—which different roles do you usually find in those teams?

**Person B**: Yeah, it really depends. On the current mission, where I'm pretty much alone, obviously one of the reasons we have a small DevOps team is that developers tend to do everything by themselves and be autonomous in using what they do. So my activities are much different than previous mission. I mentioned everything was strictly controlled. It was a small team but in a company that was quoted at, I think it was to a Stock Exchange, whatever—they were quoted, so you follow all the regulation in—I mean, it was in the insurance industry, so it was a highly regulated environment. So obviously developers couldn't just go in AWS, spin up whatever in production, and that was not how it worked. So it was a lot of supporting the developers to be as far as possible autonomous and providing support on whatever we build them to do this. A bit of GitOps, although it was not that bad.
Here, it's the complete opposite. It's a startup; it's a mess, really. I mean, you can imagine a startup—the focus is not to have high control; it's just to live the next few months. And so yeah, people just have to go in AWS, spin up a new virtual machine, do whatever they have to do. So yeah, it ended up being a mess, but they are growing. And now we are in this phase where we are trying to—the right, so to say, scale up in a controlled manner. So actually, these are a bit different about a lot of communication, saying to people that they will lose some permissions, that they would have to work differently, and the IDP is key. It's really the keystone to this whole process because we are removing their ability to do stuff directly, but on the other hand, we provide them the means to stay self-reliant. So yeah, it's the right moment you can place the IDP. And by doing that, we also more and more reducing the footprint of the current infrastructure while building the IDP on something quite—I wouldn't say fresh, but something that we know later on we can remove what existed before and rebuild on something new with higher control. And so that, ideally, all the things that were existing before we'd tear down at some point.

**Person A**: But I mean, coming back to the question with are there specific roles? It sounds like there's not really role descriptions to the people in especially that team, right?

**Person B**: Yeah, in startup, you are doing so—I mean, if we speak of role here, I'm in charge of the entire cloud infrastructure. I'm not in charge of anything end user related. So we have VDIs and those kind of things; I'm not in charge of that. But I'm in charge of DBA, maintaining the Kubernetes cluster, maintaining the cloud infrastructure, providing permissions to users, permissions—we use IaC, so I'm also in charge of maintaining the IaC platform. And so yeah, I'm scattered around. So my day's pretty messy, that's jumping from completely unrelated stuff. But yeah, usually how it works in small organizations, and here it's—I think it's the extreme case.

**Person A**: Would you say that the organizations that you have seen so far, the platform teams, even if they are not identified as platform teams, do they have product owners or product managers?

**Person B**: I mean, as I said, we are a small, very small team. I'm driving, and I know the direction where I go. I know the objectives. So I'm thinking—the client gives priorities what has to be done on a business perspective. And I have to translate that in what's my next task, essentially, which was not the case in previous mission where things were a bit more structured, and we had a bit more exchanges with—there was a real PO.

**Person A**: So let's go away from the teams a bit and more into the direction of the platform itself. So how is the platform typically defined in the organizations you work on?

**Person B**: Yeah, as I said, so we have to start from where the company is and not try to build something that's complicated. And so in my opinion, it can vary. So I have built two IDPs that have some things in common. I have recommended in two other companies some direction during the IDP. They've started something that's nothing really comprehensive, and as a matter of fact, technically they are very different, but there are some aspects that I think we can retry in every of the missions I've been in.
First, you have to have one constant that you have to have some structure in all these DevOps, I can say. So people would just create a new project in GitHub, Azure DevOps, whatever they were using, and calling it a project, eventually creating some IaC, and without really good correlation over what—even very basic stuff—environments would differ. Like some wouldn't have directly code in prod. Some would have dev, staging, and prod. Some would just have something called test and UAT, and things are configured differently. So I think if—
When I say we start from there, this is something that is defining how you will kickstart your IDP. So you can't just say—you have to define what an environment is, what—I mean, then you have to define what an application is and how they gather together and give some naming. Some companies have naming, so the best is to just use the naming they have. Some just doesn't, and so in that case, I just kind of fall back on some default I have. So I called a group of application that acts as units, and then I have applications inside and components within the application. Does that application require database, or does it have—I don't know. Already these things like that are inside the application, these different components. And so yeah, usually I start from there, speak a bit with the client, and try to understand if that makes sense in their case because obviously they have been in the company much longer than I did. And that's it. And then how you implement those things—yeah, okay, so all this has to be represented one way or the other. So I try to have some manifests that would kind of declare the existence of certain systems or an application in the company, and that would create all the necessary resources to make developers' life easier. So I mean one—
One challenge that comes again and again is how do you manage secrets? So you have to have a strategy around that. And for example, here something I did at the very beginning was say, okay, a secret has to be set in AWS Secret Manager. That's the single source of truth for any secrets. So we have two structures: GitOps and secrets. Obviously, we don't have secrets in Git. So as soon as you create the system, it will create all the RBAC permissions for your application to read the secrets. And then we can configure that. So what I mean is that create a structure, you create something to enable developers to declare that they have a new whatever it is, and then based on that, you create all things that are necessary for things to happen seamlessly, if that makes sense. It's very clear in my mind. It's very hard to express it.

**Person A**: I mean, it's a very open question, but from—already got an idea from it. But do you see a clear purpose of the platforms?

**Person B**: Yeah, I mean, the purpose was there. We didn't want developers to just, as in the past, create projects and mess around and deploy and spend a lot of time in each and every project rewriting the pipelines, the Helm charts, and removing everything project. So we want to concentrate all the complexity in one project that we have all the IDP and make sure that they can leverage that in a very simple manner. And it doesn't matter if we have two, three, four times more complexity in that project. That would remove simpler complexity in all the current leaks across the organization. That was very much the intent. Also, we wanted to have a bit more visibility for the developers. I mean, that was one of the key expectations from the client. They wanted to start with the portal, having developers being able to go in the portal and see their application. And I tried to convince them in many meetings over that we were starting from the wrong end because how do you make so that the portal knows what is deployed and whatever? They want to check that. So we just spun up a portal and created a few self-service actions that were very meaningful at that time. I mean, I don't want to say the portal was not useful at all. We could create some service actions that allowed us to remove some permissions that they had.
So—but that's very the visible part. That's something that I could just say, okay, we have put that in place, and people—it's great, but I don't think it's really what made a difference up until now. And actually, my first mission, we did not have portal at all. Everything was very low level, but—and when I say we started from the wrong end, I think it's important to have all the systems and applications represented in—how to say that—expressive manner. And when I had that, I could build a portal on that and have the application represented. So now we can go in the portal, they can see the dashboards of the application, the logs, they can have a link to be brought to ArgoCD if anything is red there. They can have self-service actions to promote their image and those kind of things. So yeah, that was key. I think I'm constantly drifting from your questions.

**Person A**: That's fine.

**Person B**: Am I?

**Person A**: Yeah, that's normal. But all right, cool. The purpose is that, yeah.

**Person B**: But they are very open questions also, so sometimes it's hard to really be—yeah.

**Person A**: No, no. It's fine. That's why we do some synthesis afterwards to drill down, but that's all. So you already talked about developers a lot, right? Who is usually the customer of the platforms?

**Person B**: I mean, right now, it's mostly the developers. That's the people that will get the most benefits out of it. Obviously, there is an indirect benefit for the business, i.e., the end users, but it's indirect. So at least I'm much more involved with the developers than the end users. Previous mission was a bit different. I was much more involved with the end users, which is a bit weird when you think about it, but I also was more in the forefront of the deadlines and all the features that the developer had to deliver and for which they were expecting something from me.

**Person A**: All right, cool. So let's drill a bit down into the operations of the whole platform and interfaces and how you come up with capabilities and all that. Let's take the portal that we just talked about as one of the examples of capability you just released to your customers or to your users. You already talked a bit about it, but why exactly did you choose this capability—the portal?

**Person B**: Yeah, the portal, as I said, it was really not my focus. The client was very much expecting it. All right. Something that, I don't know, they have seen in a demo or something and thought it was magic. You could just throw a portal over whatever you have, and that's it. Yeah, I wouldn't have started with that, but once you have your stuff in place, the real value of the portal is that you can make it easy for the developers with some mundane tasks. Like you don't have to go and git, change a file, commit it, push it, and it's a bit more user friendly, if I can say. And you don't have to know all the syntax and things of the platform itself.

**Person A**: All right, so it's mainly because the customer requested it because they saw it somewhere.

**Person B**: At least that's the reason we started it. Then later on, we made it because of it but...

**Person A**: Okay, can you walk me through the whole process of working on this capability from deciding to work on it to the delivery of it?

**Person B**: Yeah, it was a recurring discussion—we need to have a portal. One of the key elements, they wanted to have a bootstrap a project. But I don't like the idea of bootstrapping a very contact with a lot of complexity in it. I wanted first to have something different, and then at some point, we had a use case where we wanted. We wanted developers to be able to run some tasks against the production environment without them having access to the production virtual machine—that part was in virtual machine. So it just ended up linked to GitHub, have some—it was kind of hardcore, it information on the instances that were running and created a self-service action out of it. So it was kind of mimicking what a portal should be, but that did the job. I mean, they were happy to have that, and a lot of great feedback, although I kind of cheated how it works versus how it was supposed to work. But yeah, the value was there. And that was the important part. Then, obviously, once the portal was there, it started using it for other purposes, and that's where things really got interesting.

**Person A**: So, how did you exactly know that that capability was successful? I mean that people used it.

**Person B**: Feedback from the users. Yeah, people used it. So yeah, one key element is that I could see people using it. One wanted was to be able to make a prediction—a copy of the production—that I saw very often database coming in and being destroyed because I pushed also them to destroy it related music. And little by little saw the self-service action being more and more used. So I think that's a success, and nowadays they're using it every day. So yeah, they use it every day because they have a bug in that where the service crashes. So instead of asking me to restart the server, I created the self-service action so they can do it themselves. And I can see that it crashes pretty often, but...

**Person B**: A bit funny.

**Person C**: So you said that you could see the self-service actions being used more and more. How did you see that being used?

**Person B**: There is a log in the portal that we can see all the self-service actions, which triggered them which one, time and date. So yeah.

**Person A**: So, you have some monitoring on some usage metrics.

**Person B**: It's just an audit log of all the...

**Person A**: Okay.

**Person B**: It's just part of the platform. I haven't done anything for that.

**Person A**: All usage, very important. Do you communicate the release of new capabilities and platform changes to your users? That they can use it.

**Person B**: Yeah. I did in the past communicate much more, but the thing is that—I mean, this is changing, but at the very beginning, it was affecting a very small team, so I was in the original every week and showing the new things they could use. Now, it's used a bit wider, but I'm very much a lot in one-to-one with the new teams that we are onboarding. And I'm not really publicizing anymore the new features, but I wanted to have kind of standard message with release notes and things. It's just that we haven't had a whole lot of new features in the IDP itself recently. But yeah. What was behind your question? I think it's key to publicize the new features that come in and give a bit more awareness to developers. Previous mission, I did that for each new release. It gives awareness and yeah, it keeps the IDP in people's mind.

**Person C**: What kind of forms of communication would you do? I think you mentioned demos?

**Person B**: Yeah, so up until now, I did that a lot in demos because it was just one team that was using it. Now we expanded to a second or third team, and we are planning a third one. But traditional—I had messages that I just pasted with information mark IDP, release note, or I don't know what it was called, but it points of new features, and that was sent to all the developers.

**Person A**: All right. So, we talked a lot about the portal now, and previously, we also talked a bit about the provisioning of EKS clusters, right? What other capabilities does the platform provide?

**Person B**: Yeah, there are those two key elements. As I said, it's a small startup, so it's not like we are planning—you are to have something huge—but essentially, the features we have is we have a standard way to build our application. Developers just have to provide the Dockerfile. Essentially, the IDP will—and just have one file that is static in GitHub. You just make the link with the standard workflow that will build, test, tag the image, push it to the ECR, and then deploy it to dev. No matter what, it's deployed that's in the membrane. So that's the build part.
Then we have a standard way to promote image. So something is working in dev, we can promote it to higher environments in a standard way. That's also provided. Then we have automated—I mean, we have a Helm chart, the standard generated Helm chart that's key, that would pick that image and deploy it in the cluster with documentation on all the values you can have with things that are specific for the company. For example, as I said, we use AWS Secrets; developers can refer to the AWS Secret and the key and so on and map that to your environment variable, and the IDP will do all the work to pull the secret value, put it in a secret—it actually in K8s—map it to the environments. All that is seamless to them. And there's documentation on how to do that.
So there is a lot of features around this Helm chart to make things make sense in our environment, and one idea is that every time we push something new, it will be bundled in there. And the last part is the way to promote image from one environment to the other. The portal gives you yes. And then we have all the logging stack—logging and monitoring. So when we deploy, we would have a whole lot of labels and, I mean, information attached to whatever deployed so that we can refer to that in the monitoring stack, and they can easily filter things and so on. There is also, from the portal, a direct link to the many things that they can see. They really don't have to make all the filters. They can, from the portal, go directly there.
There is also Argo CD for visualizing the state of everything that is running. That's pretty much the scope as of now. We are planning to extend to all the ETL tasks. The very integrity detail is still being worked on that. The idea would be... So when you have an application manifest, it looks like an API object, like a CRD. So we have the kind, it can be types. Right now, it can be simple applications, something we build internally, we release. It can be vendor application, so something that comes from Helm chart, from a vendor. And we think I will just add a new application, and that would have some specific Helm chart that could work. With the ETL platform, we have—as I said, all the nitty-gritty detail is still to be defined, but it's the same idea. Simple whatever, person would create a new ETL job.

**Person A**: Okay, I see. You talked a lot about Helm chart and CRDs and all that. How do users usually then access those capabilities? I mean, we have the portal on one side, but especially those more technical things like Helm chart—so do they usually interact with the platform for those?

**Person B**: Sorry, I'm not sure I understood the question. Can you repeat?

**Person A**: So how do users access the platform capabilities, such as the whole image management and all that? It's mainly through the portal, or do you also have other entry points to the platform?

**Person B**: No. They would have to—so in the application manifest, they would define basic information. I consider that they don't have to touch anything in the cloud platform itself. So the entry point will be—they will be able to visualize the application in the portal—the logs, metrics, and so on from the monitoring stack. Argo CD to have all the status of all the resources that have been deployed. From the portal, they can jump from one to the other. I don't consider developers have to go into AWS to see images and EKS cluster or those kind of things. I really want to have something that is, yeah, I won't say opaque, but abstracted. Then obviously there is still the possibility if need be to go in AWS to see if the image was pushed properly or those kind of things. Up to now it was not really necessary. I don't think people really need that. So yeah, there is the portal, monitoring stack, Argo CD, and GitHub, obviously, in the version control.

**Person A**: Do you have any platform-specific CLI or CLI plugin?

**Person B**: No, don't. That's something—okay, so that's something that has been back of my head for some time to ease up with strapping a project. I think it would make sense now. We could also have that either triggering via Git or things like that. There is just not really direct value that we could see.
So we've never really started that. Another thing that we considered is that—I consider—is switching from simple Helm chart to operator; the reason being that sometimes it's a bit tricky to work with what is outside of purely Kubernetes in those kind of things. But once again, I mean, all up until now we could have everything working, did not really need to make that jump. So at some point it will come for sure, but it's not the case yet.
And we were early because, I mean, that's one key element. I was very focused on having an MVP, so not trying to—I will build an IDP, I want an operator, I want this and I want that now, and then you deploy it and it fails and all that. I think—and also the time frame was quite tight. So MVP was really the focus. I think now we have an MVP and we can think about something a bit bigger.

**Person A**: Yeah, yeah, I understand it. Coming back to one thing you earlier—you said you're doing demos and support teams and the onboarding. What other kind of support do you provide using your platform?

**Person B**: So documentation is key. I expected to have to provide a whole lot of support and it went quite smooth. So obviously at the beginning I had some people asking questions and I could just refer to the documentation and say, okay, don't hesitate to come back to me if you have some specific question. But yeah, your question is answered there. And sometimes they just come and say, okay, I want to deploy a new application and what's up? What are the steps? And I just send them to the documentation. And there is a quick start guide, so I made it very simple. Interestingly, I had very few support requests; it was just a feature that was missing and it was in my backlog or just planned for it. And they asked for the time frame and I planned it. Previous mission was much more heavy because documentation was a bit less—I mean, I don't know, I had to provide a whole lot more. I think that the platform was less consistent at the time, the tooling was not as great as it is now. Yeah.

**Person A**: So documentation is the most important one.

**Person B**: Yeah, it's very key. And sometimes it's just come and there is the—I don't—actually all the questions I had up until—how do I deploy the—clear and send the documentation. And very rarely they had any trouble.

**Person A**: All right, cool. You already said interesting bit as well, so you said that sometimes it's just they request a feature that's missing. So your users can request new capabilities for the platform.

**Person B**: Yeah, yeah. That's key.

**Person A**: Okay. And so with especially your customers, your users and then end users requesting some missing features, and then your customers, which are the organizations, right, coming in and saying like the portal, I know there's this fancy that I want. How do you usually set your team's priorities with that money input?

**Person B**: Yeah, I mean, sometimes it's just the one that's about the loudest. Yeah. I mean, I have a team lead that is very mindful of using my time the right way. He sometimes overprotects me, but yeah, I think he's doing a great job of setting the priorities and just saying this is not important for now and just switch that. But very on the daily basis I'm just balancing the effort and reward, essentially. And also things that are outdated with an overview. I've been doing last week was very about, you should—now we are still in a very reaction mode. Like there is a need, we react on it and kickstart it. The IDP itself was kind of proactive, I mean, it was definitely proactive, and there's a bit more reaction. And I mean, one guy left and we are planning to just—I mean, maintaining what he built is a pain, so we are trying—we consider putting it in the IDP, but knowing it before, it would have made more sense to bring it in the IDP before he left. So yeah, we are more in reaction, but obviously I'm a lot to stay here.

**Person A**: All right. You already talked about this team lead that helps you a lot in shaping the priority. So you in general have stakeholders that are involved in shaping priorities for your platform.

**Person B**: Essentially all the developers' team. So we have four or five, depends how we look at it. And there are company priorities. So there is one big project that's the project that triggered the whole IDP initiative.

**Person B**: And so essentially my team lead aligns the requests from the developers with the company's priorities and sometimes just, yeah, says the numbers are down for some part of it. Yeah, I think that's how things are prioritized.

**Person A**: All right. How often does your team lead then revisit those priorities?

**Person B**: So we are not running sprints or—we have more of a Kanban that I'm maintaining. And yeah, we meet two, three times a week, discuss the things that have been completed and what comes next, new requests. It's usually more of an open discussion. I mean, we have obviously some basis, the things we have, our backlog and so on, but we don't go through the whole backlog each time. It's more than a discussion than something very formal.

**Person A**: So it's more continuous between. All right. How would another team or a platform user know what you're working on? Would they just look up the Kanban board, or is there...

**Person B**: So I don't think we are great at communication between the teams. That's a common issue in many of the clients I had. Everything is open, so they can come and look at it. I'm pretty sure nobody does, but I'm announcing new features when they come in, and when there is a request, I keep communicating with the person that made the request. I mean, when I started asking when it's done and if there are some questions, although right now, as I said, I haven't built new features for quite some time. It's more about bringing applications inside the IDP. And for that, I have constant communication because obviously you start for some more, don't want to break anything, and you have to bring that in the IDP. So, yeah.

**Person A**: All right, let's look a bit at feedback. Do you generally collect feedback from platform users?

**Person B**: Yeah, I don't really—yeah, I have feedback from me—how to use it and open discussion with them. I see what they're using, and when there are new applications coming in, I see the PRs, so I know that the new application has been dropped. So I know what they're using. I don't proactively send a survey or things like that, mainly for time constraint reasons. It's more gut feeling somehow. It's more gut feeling somehow.

**Person A**: I see. When was the last time you did a demo for your platform?

**Person B**: Last Friday. It was very small; it was not a demo of new features. It was more getting back to the basics, but he didn't really know. Three weeks ago when the last one was before the other collection, I think it went away. It was quite some time, but otherwise each—yeah.

**Person C**: Do the demos tend to be well attended? Are they kind of voluntary, or is it a company-wide...

**Person B**: No, it was everybody from the project that initiated the IDP initiative. Everybody was there and I demoed every week I was doing the new feature. There hasn't been new features for two sprints now, and given I'm alone in the team, I don't have time anymore to do those demos. But I did a new demo last week.

**Person A**: Okay. What do you do usually with this vague feedback, the gut feeling that you have, and especially what people say in demos? Do you start...

**Person B**: Each time I have a feedback, even if it's just informal, a question or something that prompts an idea to me, it's all the same. I add the idea in the backlog, put kind of priority, and I mean higher or lower in the list. Yeah, that's pretty much it. Then when the feature is released, just send a small message saying, okay, this thing that you needed, it's done. Or even if it's not needed from me, just inform whoever might be interested in that.

**Person A**: Okay. So we have two small blocks missing, and we just have—is it okay if we go three minutes over time, or do you have a hard...

**Person B**: Yeah, that's fine.

**Person A**: I'll just continue down with those blocks, but I've skipped them. So first we want to look at the platform success, which is a bit of a tricky part, but is there any specific business goals that are tied to your platform?

**Person B**: No, we don't really measure the outcome of the platform, although it would make a whole lot of sense. What I can perceive is two things. First, I see the number of application manifests growing, which means that there is adoption—they are not obliged to use application manifests. They could just all the way create their manifests—I mean Kubernetes manifests—and drop it in GitOps or whatever, and that's it. But they have started deploying stuff that they have undeployed all the way and deployed it in the IDP. So that's—the second sign is that they're autonomous. So I don't sometimes just see a review, new application manifests coming in, which means that they're autonomous.
It's not very strictly speaking a business objective. But that means that they can free up the time they would have spent building CI/CD deployment and so on, and focus on delivering business value.

**Person A**: So it's efficiency, developer experience, something in that direction. Okay.

**Person B**: Yeah.

**Person A**: We also talked about that—track that with the metrics there. Are those metrics also used to inform your prioritization, or is that just informal, interesting?

**Person B**: Not really. The prioritization comes from—I mean, except if there is something broken really and we need to work—there was something that happened at some point developers complained about the fact that secrets were not refreshed often enough because it's a polling mechanism; it's not event-driven. That's something that took me five minutes to reduce the polling interval. And I prioritized it—I mean, I didn't wait anything. I prioritized it as highest priority, but I would say that's the exception. Most of the time, as I said, it's like there is this new thing, chatbot or whatever, that needs to go out, and it becomes top priority. But that comes from my team lead rather than me proactively changing the priorities.

**Person A**: Perfect. And then, the last bit is about investment. That's always the trickiest one. So, how does your platform and the platform team generally get funded?

**Person B**: It's not really so usual. I spend time—let me think—there's two types of cost: the cost of engineering stuff and the cost of the tooling that you are using. I spend time where it's the most efficient to achieve the next objective of my teams, would you say? And sometimes I have to choose between going the long road—you can call it a long way very often—but up until now, it hasn't been challenged by the client, so things are fine. Then there is the question of the tooling that we are using, and it's just me proposing we need to use this tool because it will help me save time or be more efficient or bring more value for the developers—better user experience or developer experience. And it's just an open discussion: does that cost many thousands of euros, is it worth it or not? Do we have the cash for now or no? We have to wait because VC funding is pending.

**Person A**: Okay. Do you have any executive sponsors, C-level sponsors for your platform?

**Person B**: No. No, C-levels are very much focused on growing the company. As I said, it's a startup. We are very trying to scale up. There is another very big project that triggered the IDP initiative; it's the highest priority, and they're focused on that. The IDP is very much a consequence of that, and the VP of engineering—the one just below the CTO—I think he's sponsoring that highly.

**Person A**: Okay. That's it, thank you! Do you have any questions for us?

**Person B**: You're welcome.