← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
BONUS The Platform-as-Product Revolution: How to Turn Your Biggest Cost Center Into Your Secret Weapon | Alvaro Lorente
00:37:45
BONUS: The Platform-as-Product Revolution: How to Turn Your Biggest Cost Center Into Your Secret Weapon With Alvaro Lorente In this BONUS episode we explore a topic that's creating a lot of discussion—and sometimes confusion—in the software...
Loading summary
Transcript74 lines
- [00:04]
A
Hey there, agile adventurer, just a quick question.
- [00:07]
B
What if, for the price of a.
- [00:09]
A
Fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame war free and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's this Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership, that's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast.
- [01:12]
B
Hello everybody. Welcome to a very special bonus episode. For this bonus episode, we have with us Alvaro Lorente. Alvaro, welcome to the show.
- [01:22]
C
Thank you for the invitation, Vasco.
- [01:24]
B
Absolutely. So Alvaro is with us to talk about a very interesting topic, platform teams versus DevOps versus value delivery teams. We'll talk about that in a second. Let me just tell you a little bit about Alvaro. He's currently a director of engineering in Voxel, an Amadeus company in Europe. At least many people will know Amadeus because they handle all the travel, airline booking and so on, which is a software. And he is a software engineer by training that has grown in the people path, experimenting with a bit of everything from product development, startup, open source and more. And he likes the idea of a jack of all trades and helps, tries to help wherever needed. And in this episode, as I introduced, we're going to talk about something that has a lot of discussion around it, but sometimes still causes confusion in the software community. That is platform teams versus DevOps versus product teams. So let's start with your origin story, Alvaro. So you used to work in what we might call value delivery teams or product teams, and now you work with platform teams. When you think about these two aspects, I mean, that must have been a big transition for you, right? So how was that transition for you? And what was the culture in that platform team when you arrived?
- [02:52]
C
So actually that's an interesting question. So like you were saying, I thought I've worked quite a lot on delivery teams, trying to just bring features out of the door and, and that's actually great because you work with the clients and you actually are trying to bring new value to the company and that's actually how the company makes money. And for me, I've always been like, I introduced myself, I've been a developer, I've worked actually in a little bit of everything. So I've been doing also all the platform things in the cloud. So this idea of T shape development and that's what actually bring me the interest on platform teams and actually trying to understand how and why do they exist. So for me, platform teams actually exist to facilitate the delivery of value in a scalable way for the rest of the teams. Not by going into a corner and just doing whatever they want, but by solving the problems that actually teams have on their day to day. So we're not reinventing the wheel everywhere. When we talk about culture itself, where I arrive, it's also an interesting thing because it's the transformation that most of the companies normally have of having silos and people that do specific things. The company was quite advanced in every other aspect, the T shape development people, multidisciplinary teams that do tdd, TVD and more. But actually the infrastructure team was a little bit left behind. It was the typical team before I arrived. And historically let me bring back a little bit of the history of the transformation of this team. Probably one year, two years ago, the teams was just a ticket expenser, to put it. So they receive a ticket, they create a new machine, or they create the new database and just send it to the team that has their problems of being actually a bottleneck. Teams got annoyed by that. So the first transformation is let's do DevOps because this thing is cool. So let's actually put a person that is a DevOps engineer in every team. That actually just didn't change a lot actually. What changes shifted the idea of having a ticket to an external team, to actually having a ticket on a person that was shared in between one or more teams.
- [05:40]
B
So what you're saying is that as part of the transformation, one step usually is to have someone called the DevOps engineer who replaces a whole team somewhere else, which would be the whatever platform team and the way of working still remains the Same, where the DevOps engineer is still very much siloed away from the actual feature delivery teams. Is that what you mean?
- [06:07]
C
I don't think it's a good practice, but this is what actually happened. I think that is an intermediate step that you might do or not, but it still keeps you on the idea that DevOps is a role or that the person that takes care of the platform or infrastructure or operates is more a role and not actually a culture that the teams need to actually own their systems themselves. So still keeps your silos on the track of everything. So I don't think this is correct. The idea of DevOps should be DevOps is a culture and not that DevOps is a role itself in the teams. Put it on. Does that make sense?
- [06:52]
B
Yeah, yeah, makes sense. So, so when, when you arrived, you started to say, okay, there's this very big disconnect between value delivery or feature delivery teams and platform team that was kind of the, the JIRA wall in the middle as you were describing. And then the next step was, okay, let's take this platform team and split it up into multiple individual DevOps engineers who now work with different feature teams, but still in this JIRA ticketing queue kind of way.
- [07:22]
D
Right.
- [07:23]
B
That's where it went next.
- [07:25]
C
I arrived just after that space where they were actually sent each of them into one or multiple teams. So I did the transformation in between DevOps being that role. That solves actually tickets to actually trying to create the platform team. That actually solves value for the teams to put it on.
- [07:48]
B
So how did then the next step come up? Because I imagine that at least from the feature delivery team's perspective, having a DevOps engineer kind of assigned, allocated to their work kind of felt good, right? Because they were slightly closer, they could talk to the person. So what triggered the next step? What triggered the need to create a platform team?
- [08:14]
C
So that's correct. So having somebody near actually helped them. It's different to have an external team trying to solve things than having it on your own team. The thing is, it was still a bottleneck because either that person goes on vacation, that person actually takes some time off, or you normally don't have the capability of hire one people for each team. So we have cases where one DevOps was sharing between three or four team. So that still made it a problem. The transformation came because the teams actually wanted autonomy. How do you actually provide autonomy to the teams? It's actually by enabling them. So what we actually started working on is what we call the DevOps body. So it's providing at least one person on the team with the correct knowledge and permissions to actually start doing the same work as a DevOps. We did it with one DevOps or two DevOps body because we are in environments where you need to pass pci, DSS or other certifications that are complex. So you cannot actually say, hey, I give the entire team autonomy. This is why that conversation in between security and the teams need to happen so we can find a common, common space. So recapping the idea was to have people inside the teams starting to get the knowledge of infrastructure. I don't want to call it DevOps because DevOps is not a role for me. It's a culture itself that actually they can operate and create their own system platforms and maintain them with the intention that the team grows and grows their own autonomy. And then we can pull the entire set of experts to actually facilitate that knowledge on the long run. So making tools simpler so they don't have that mental constraint or complexity that teams actually are scared about. Normally about infrastructure or platform teams are not only about infrastructure, they're about probably complex problems that need expert knowledge.
- [10:42]
B
Absolutely. Okay, so we have now three steps, right? The separate team, then the DevOps as a role instead of a culture, then the idea of that knowledge, that experience being inside all of the teams. With the concept of the DevOps body. What happened next?
- [11:01]
C
So what happened next is we consolidated the platform team and from having that platform team, the intention is to convert it actually into also a kind of delivery team. So normally when you find a platform team, it's only technical people. Let's think about what's the next thing to do. And we just push it to the teams. But the intention was to treat it as a product. So the first thing is to actually bring somebody that takes the role of a po, for example, that can actually understand our clients, because the clients in reality of this team that make them be productive or useful for the company is the rest of the delivery teams themselves. So if we treat it as a product, we need to actually bring somebody that takes care of that product side itself.
- [11:53]
B
So what I hear now is that, okay, so at some point you discovered rate, but this platform team needs to be treated the same way as all other feature delivery teams are treated. But why did that thought come to your mind? Because if I think about many of the clients that I've worked with, I can certainly see the need at some point to kind of develop the platform further. Some might call it refactoring or re engineering or a rewrite project, whatever that is, or adding some new and therefore heavy in terms of heavy lift functionality into the platform, then they put a team together to do that, but then they disband it. Again. Companies typically don't look at a platform as a product long term. They might look at it as a short term investment for certain things and then they move on. But what I'm Hearing from you is that it wasn't like that, that you really started to understand the need to have platform as a product. How did that thought develop?
- [12:58]
C
That's an interesting question. I've been hearing about this for some time. Also being used to delivery teams and trying to bring value to clients was something that actually made sense. So I don't think it's my idea. I think that there's a lot of people in the environment that have already talked about this. So I even not so long ago I went to O'Reilly session to put it. So that was called the value of product thinking for platform teams. So definitely I'm not the first person thinking about this. Camille for near has talked about this probably also extensively. But the idea is you have delivery teams that have continuity and they have continuous needs. A platform team is just the team that is actually serving those to make their work more effective, simpler, and that actually makes it also more valuable. It also saves money for the rest of the company. So if you think about that, it's not as one shot thing, it's something that is a continuous improvement situation for the entire company unless all the teams are happy and that moment might arrive at some point. But then you need to also maintain the systems that you have created for the rest of the teams.
- [14:28]
B
What I'm hearing from you is that there's significant advantage in some context to have platform as a product, specifically in terms of serving the feature delivery teams with needs that are, I'm guessing you didn't say it, but I'm guessing similar across teams and that also it has advantages in terms of managing costs, managing long term maintenance and so on of a component that actually serves all of those teams. So it sounds to me that you're saying that setting up and maintaining a platform team where the platform is the product is a little bit like a scaling strategy, right? Like serving many teams with less cost than you would do otherwise.
- [15:13]
C
Right. So there might be moments where you don't need a platform team at the beginning of a startup. You might not, probably not even probably you won't need a platform team because you're just trying to find your product market fit. But as you scale your needs, scale your amount of teams, scale what you're actually doing, you will find common problems that some teams might solve it one way, some teams might solve it a different way. And what you're actually entering is a place where you can actually not share knowledge. There are silos, there's probably on things that are not aligned in the company. So it Helps to actually saying to the teams, hey, you don't need to care about this. Let us know what are your pains. We're going to try to solve it. At the end when you actually find or try to buy a SaaS or something else. Like if we're talking about observability, let's say a Grafana or something like that, it's not because you cannot actually do it, it's because it's simpler and reduces your complexity to actually externalize that need. And actually having a platform team is actually externalizing those needs, but inside the company.
- [16:31]
B
And that externalizing that you said kind of giving that away to the platform team can help us scale if we have multiple teams that have similar needs for their specific feature delivery. And you mentioned one observability, a couple of others come up immediately like reliability, performance, like all of the ilities.
- [16:58]
D
Right.
- [16:59]
B
Like you start thinking about it. Okay, There's a bunch of things here that we could probably benefit from and it would make sense to think that the platform team can help develop those, I guess we could call them performance characteristics so that other teams can take advantage of it. I mean, security is one that comes to mind immediately.
- [17:22]
C
Correct. But those actually need to be first needs from the teams. They cannot actually be decided by the platform team. And that's exactly why you actually need to treat it as, as a product. Because if not, you're probably solving a problem that nobody has. You're going to push it into people that don't really care about it. So your adoption and anything is going to actually be not useful at all.
- [17:51]
B
And the other aspect you mentioned is also the developer experience.
- [17:57]
D
Right.
- [17:57]
B
Because a platform team can create or destroy developer experience for the other teams and treat, treating it like a product helps to create that focus.
- [18:07]
D
Right?
- [18:08]
B
That you have concrete customers, that you're serving those customers.
- [18:11]
D
Right?
- [18:12]
C
Correct. And those are our customers. If they don't buy our product, we don't have a why to exist. So we're also trying to find the market fit. So I've been talking this with the team. This is something that we need to also try to improve on like everybody. But what are our KPIs, what are we caring about to improve? Adoption can be one thing, but it's also customer satisfaction. How people feel that it's affecting their day to day, is it reducing their complexity? What are we actually improving on their life? For me, customer satisfaction inside the teams is also something that is going to tell you quite a lot if your platform team is doing good or not.
- [19:02]
B
Okay. Let's dive deeper into that because I think that's a very interesting aspect of the platform team, considering what they're delivering as a product. What does that mean in practice?
- [19:14]
D
Right.
- [19:14]
B
Like, so in the platform teams that you work with, what are the things you want to see in place for you to believe that, yes, this platform team really is taking the platform as a product idea seriously.
- [19:29]
C
So for me, there's one thing that is really important, is like talk to the clients. So we had quite a few sessions with the delivery teams to know what are their main pains, what are they struggling with, what do they like and what do they not like from the platform. So it's a cliche, but you need to listen to your clients. So for me, that's one of the main things that will make a platform team successful. I would say that the other thing is if you're doing this, you don't have so much problem with adoption. But a lot of platform teams tend to create things and just push adoption into teams. This normally is a common pitfall because teams either don't need that or they feel that they are being pushed to use a tool that they actually didn't ask for. There's always an excuse to not adopt something. Again, I think that this goes back to the KPIs. Adoption can be a fake KPI if you're pushing things. So you need to make sure that the teams actually need your product and are happy with your product, to put it. So I think that those will be the main things that I can see. Also, one thing is, even if it's internal product, make sure that it has quality. I've seen that in our team, especially at the beginning, and in other teams from platform, it's internal things. We don't care so much about the client. And if they're bugs, hey, okay, open me a ticket or let's talk about it. We tend not to be so thorough as if we were pushing to external clients that pay for the product. So quality should also be an important thing to take care on the platform.
- [21:29]
B
Yeah, immediately when you say that, a couple of specific and critical processes come to mind. One is the ability to collect feedback. You already mentioned that. Then the other is to have a process to handle incoming requests, whether they're bugs or features or anything. Because we would have that in a real product to have a support structure. This could be a rotating person that is kind of the support person for the customer teams during that process. And then of course, one thing that you already mentioned, which is the product owner or product manager for the platform. But this is often ignored. I mean, many product leaders will not feel any attraction to working with the product team because it's not, you know, there's not a lot of emphasis on user experience, talking to sales, talking to marketing and so on. So how can we make the case for investing in product talent in core technology teams like platform teams?
- [22:27]
C
Yeah, so basically when we talk about how do we convince product or convince the organization to invest the product talent and things like that, again we are talking about what is the product a common language and the product common language normally is money and how do we actually are affecting the KPIs of the company. Normally every company wants to be as much profitable as possible. And this is also true in a platform team. So if you are trying to simplify the development experience and making sure that the teams are able to deliver, you're actually saving money. You're actually saving hours of development. That can be calculated. If your feature is making developers 5% more productive, that means that the average cost of your developers is a 5% less to producer. So there's always money to be improved there. Or if you have a stability issue normally around the company and you have 10 incidents per month or something like that, then what you're saving using your platform team to improve that, you were actually talking also before, it will save you money on clients that you might lose and also tickets that customer care is going to be taken care of. So the complexity normally of technical things is how do you translate them to money? Because that's a common language that we actually need to talk. So that's how in rolling back, that's how you actually convince product companies or even the business entirely why they need to actually invest in platform.
- [24:35]
B
So basically what you're saying is that there's work that needs to be done, for example, incident handling or improving the performance of certain parts of the platform or whatever, that work still needs to be handled. But when we have a product team for the platform, meaning product management as well as development and testing, what we're doing is that we are scaling that, we're making that more efficient, if you will.
- [24:59]
D
Right.
- [25:01]
B
We're reducing, for example, reducing cognitive load or the amount of work that it takes to add a specific feature, or we're speeding up the response to incidents that happen when we're live and so on. Okay, so that's the sale to the management.
- [25:17]
D
Right.
- [25:18]
B
Like we need to have this product team. And of course you could say, hey, but it's still the same. People quote Unquote, we just move them to this platform team. But it isn't like that. There's always some more work that comes in with that also because we want to develop the platform further. And how about product leaders? So the engineering manager will probably get it right. We're talking about efficiency, we're talking about speed of handling the incidents, maybe better security, all of those things. Engineering management will get it. But how about the cpo, the chief product owner? How do we get them on board to understand that they need to invest in that platform team?
- [26:00]
C
Going back to this. So it's basically, if you are able as an engineering manager at the beginning of this, conversion of a platform team into an internal product team is to actually be able to talk the same language that you cpo. That is going to be actually the money that they are going to be saving that is going to actually add to, to the final margins of the company. So if you're able to rely or send this message to the CPO, then hey, okay, we're spending 3 million on developers, to put it. So if we improve the development experience with this set of features that they're asking, then we're going to be saving 5% of those 3 million. That's something that the business can actually understand. They will not understand. They will not understand features per se, but they will understand money. So with this you can actually bring the product talent into the team to continue that evolution of that conversation. On where are we actually improving? How are we actually improving the, the savings of the company and how are we improving the health of the company itself? Yeah.
- [27:25]
B
One other aspect that I would add is that there's already a lot of engineers who want to start transitioning to a more product oriented position and this would be a perfect place to start that learning.
- [27:37]
D
Right.
- [27:37]
B
Because it forces us to take on a lot of the product skills like listening to customers, doing competitor analysis, experimentation and so on, and applying it to an area where engineers feel very comfortable with, which is a platform.
- [27:55]
D
Right.
- [27:55]
B
So I would say also from a perspective of talking to the CPO as well as the cto, the chief Technology officer, is that this is a great career path for those engineers who have this intention to develop over time to becoming more product oriented, to actually have that understanding.
- [28:12]
D
Right.
- [28:12]
B
Like to really work as a product person even though they're handling technical decisions and a lot of architecture and so on.
- [28:23]
C
Actually, the fun fact is that one of the technical product managers of one of the teams that I have right now is that conversion that you actually talk about. It was a DBA with a lot.
- [28:35]
B
Of.
- [28:38]
C
Intention to actually grow their career into this product side. And that was a good match to actually start growing into this new career itself.
- [28:51]
B
All right, so let's say we're convinced, right? Like the cto, the engineering manager, the CPO are convinced and they've decided, okay, we're going to stand up a platform team. We have enough product teams that need support, so it makes sense to start that platform team. We see the benefits, we see the career growth, we see the investment paying off in cost savings and speed to market. What are the two to three things that you think the cto, the engineering manager must focus on when starting, when standing up a platform team?
- [29:28]
C
Yeah, so I think I might have mentioned them a little bit around before, but if we enumerate them correctly, I'm going to probably start with. The first one is don't just start working on what you think on your brain is going to help. You need to actually talk to your clients and actually listen to their needs. Just don't start working. That's a common pitfall. I fall on it once, twice how many times you actually want to mention it. But sometimes with the pressure, you are asked to just start delivering the same. Like in a delivery team, take your time to actually do your work. The second one I will say like is that adoption is not a mandate. If you are mandating something, then the person that you are actually mandating over, they're not actually willing to use your product. It's like when you buy a SaaS, you are willing to use the product because you're already thinking on paying about it. The same should happen with platform. So if you're mandating something, you have a problem itself. So you need to actually the teams to want to adopt your product. And last one I will probably get back to. The quality thing is making sure that even if it's internal product and there's not a final external client that is going to be using needs to be quality. It needs to be a quality product because if not, it's going to affect the reputation of your team the same that it will affect the reputation of a company if it was an external product. And if your platform team reputation is affected, that will mean that over time, even whatever product you use take out that actually helps the team, they will not trust that your product has the quality that they need to deliver.
- [31:34]
B
I would add one to this and I'm curious to hear your thoughts because you've been doing this for a while. The one that I would ADD is think of establishing a platform product team inside your organization. A little bit like a change process.
- [31:52]
D
Right.
- [31:52]
B
It's not that you're just creating a team and then magically everything will start working. You're creating the team that's maybe step one or two, but then you need to create the communication, the stakeholder management, the regular communication forums, how the platform team comes into the annual planning. Because don't forget, they're going to enable a lot of new things that are coming up in the next 12 months. So kind of take it as a change process. It takes time to go from actually having the team to having it well integrated, communication structures in place and so on. And for that I would say then bring with it a person that has that role of a change agent. It could be the engineering manager for that team. It could be a scrum master or an agile coach that is working with that team. But take it as a change process as well. What do you think about that?
- [32:42]
C
I definitely agree with you. So it's a change process because if we go back to the beginning, this is how do you create change? How do you change something to become a culture? A culture doesn't create itself on a day to another like something that is born out of nowhere. So it needs to be something that grows inside the team, that grows inside the company. So that needs its own responsibility and somebody that can actually make that happen. Definitely agree with you.
- [33:15]
B
Yeah, absolutely. Because it's always a culture problem, no matter how we look at it. Or in other words, as Jerry Weinberg says, no matter how we start looking at it, eventually we find out it's always a people problem.
- [33:28]
C
Yeah, definitely.
- [33:29]
B
So is there a book, an article or a video, a resource that you can recommend for teams wanting to improve their understanding and also to get their heads around this process of setting up a platform team?
- [33:45]
C
Very good question. I think that following people like Camille Fournier that has actually written a book on platform teams is a good starting point. There's a lot of resources probably in the O'Reilly platform like the one that I mentioned about the value of product thinking in platform teams. And I would say if you are able to experiment, it's not a resource. But being able to experiment is also something that helps to bring continuous improvement to things.
- [34:18]
B
Yeah, absolutely. We learn by experimentation. So get experiments going in your team for sure.
- [34:25]
C
And not one size fits all. Not all gardening sessions are going to be exactly the same and not every people is the same. So experimenting is always a good thing.
- [34:35]
B
Awesome. Alvaro. It's been A pleasure. Thank you very much for being with us here today on the podcast. If people want to contact you, get to know a little bit more about you and the work that you're doing, where could they go?
- [34:48]
C
I'm normally on LinkedIn, so my user is my name, Alvaro Laurente Dev and I have a newsletter that I try to write as common as I can that is actually called Leads Horizon. So yeah, feel free to also send me a message or whatever you find in social media.
- [35:09]
B
Absolutely. If you're working with product teams, do connect with Alvaro and chat with him on LinkedIn. I'm sure he's happy to help you and share some ideas and resources. Alvaro, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.
- [35:25]
C
Thank you very much.
- [35:25]
A
Pasco Alright, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you. The members who wanted more than just inspiration. They wanted real tools and real connection to people who are practical practicing agile. Every day we're talking access to over 700 hours of agile gold, CTO level strategy talks, Summit keynotes, live workshops, E courses, Deep Dive interviews, books, and if you're into no estimates, we got the pioneers of no Estimates in those Deep dive interviews as well. Agile Business Intelligence, Creating Product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners. Plus a private Slack community which is free of all of that AI slop you see everywhere. And of course without the flame wars. It's a community of practitioners that that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the details@scrummastertoolbox.org membership because listening is great.
- [37:11]
B
It's important.
- [37:13]
A
But doing it together, that's next level.
- [37:16]
B
I'll see you in the community. Slack we really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes, Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.