Why You Need a Dedicated Platform Team, with Pivotal’s Paula Kennedy

Episode 117 · 38:58 · SRT · archive.org · all Tanzu Talk

so this week we have paula kennedy um from our pivotal london office on and paula tell us a little bit about your role and how you've kind of ended up being someone who you know gave a talk say last year on platform as a product because that's kind of the that's the topic the thread we're going to be pulling on today um as domain said so my name is paula kennedy based out of london i've been at pivotal just over three years my current role is looking after our pivotal cloud foundry solutions team in europe so we have around 20 people based across europe who go out to help customers with how to essentially how to run install scale operate pivotal cloud foundry um i have a second job which i just took over recently as well which is looking after the education team in amir and actually the two roles fit very well together so we have more classical education which is how we enable customers at scale and then we have the pivotal cloud foundry solutions which is how we very closely work with customers platform teams to really enable them to think about platform as a product okay that's interesting to kind of that the complementary nature of sort of the the services and then the sort of at scale training um so the the big question for you is and we sort of we're talking about this before there there's there's a couple different questions sort of woven in together but it's really about not so much what the platform as a product is although i'm sure that'll come up more just the the how you get there um what does that look like and just given that a lot of

folks are who are end up being on that platform team right the platform engineers the product manager um or product owner like and you know are those the same person do they have to be or can there be someone else who's sort of functioning in that role um but they didn't start that way they usually started doing some other job and so those people kind of have to go on a bit of a journey to become that and they might be designated it and called it before they're really kind of thinking it yet you know like you have a new job congrats new title but like you're not really doing it for i don't know some number of months until you're like okay now i get it right now i get what my new job is so i just wanted to see if you could just given like you see so this happen again and again and again um what's the is there kind of a pattern to sort of what that looks like and how where folks are coming from um and then ultimately like you know what what along that path kind of helps folks be more successful right if they could learn anything from the stumbling blocks that other folks have gone through what would that be uh to go to go down this path okay so i guess to start off with i'd say our customers are all coming from different starting points in fact when when my team first engaged with a customer typically at the at the point of in the customer's journey they have selected pivotal cloud foundry as their platform of choice they understand that our pivotal mission is we want to transform how the world builds software so the customer will have some inkling of the fact that changes are coming but may not fully understand the level of change that we're looking to drive into customers so when the pivotal cloud foundry solutions team first engages we have a very idealized view of what a platform

team should look like and what a product owner should look like but quite often the customers are as you mentioned they may not be right at that place they may not have the people lined up they may not fully understand what work is involved what change of culture is involved what change of mindset is involved so it really is a journey when we start what we talk about with our customers is having a dedicated platform team that is balanced and that has a platform owner and so all of those things have very specific meanings when we talk about having a dedicated platform team what we see with our most successful customers is they have a small number of platform engineers a platform team only needs to be say two three four people it can be quite small and can support many multiple application developers so we talk about kind of a one platform operator to a 500 application developer i mean that's kind of a number that gets thrown around sometimes in pivotal but really the platform team can be quite small but that platform team is most highly effective when it's focused on running the platform so that can be quite a hard ask even for customers at the beginning they may have people that are lined up to be the platform team but they've got a hundred other things that they have to run as well and so um maybe they only have people that are available part-time or another pattern that we've seen quite often is customers might outsource their data center might outsource other parts of their infrastructure and might choose to outsource their platform team which in itself then can be challenging because you're trying to ask a big outsource company to change how they think about running this one small piece of software as part of a larger thing that they run on behalf of the customer and that's more challenging so like i say we typically look for a small dedicated team

and we look for that team to be balanced and what we mean by that is that it's got people in the team who've got infrastructure knowledge as well as people who are more used to applying software engineering practices to the platform and in addition to that we also look for a product manager into the team which is slightly different from kind of product owner or platform owner as we were talking about before so for pivotal a product manager again is very specific skill set but it's that person on the team who is unblocking the team making sure that they can make progress that is running a backlog that is prioritizing the backlog that is really driving the platform as a product mentality home within that platform team which might be slightly separate from a platform owner or kind of platform champion who might might have more kind of political power is able to reach out more broadly in the organization is able to unblock the team at a higher level and might have ownership of multiple different things but is also that um kind of overseer of of a wider program maybe not just the pcf but maybe other parts of the the business as well okay that's really helpful because you know i think some folks think about the product manager as the product owner um but and they also i you know if someone were to ask me to define just product management um prioritization would be like the first thing that i think of like prioritizing you know the road map which is sort of effectively what the backlog is but i really liked how you described like the first thing that you said was the person who's unblocking the team yeah um and so i think that that sort of speaks to

you know either that's just more what product managers are in general or on these platform teams what you can expect is that that is a big part of your job is is kind of performing that unblocking and that's related to this product owner is sort of blocking it unblocking maybe at a different level right and like more of a political level and you know resources level and whatnot not not so much at the technical level is that a fair kind of you know recap of that distinction that you just made yeah i think it's also about allocation of time so a product manager who's part of the platform team it's also that person's full-time job working on that platform with the team all day every day so they're unblocking like you suggested a kind of a more tactical level they're also prioritizing the backlog they're also in the stand-up in the retrospectives in the planning meetings they're all day every day part of the platform team whereas the platform owner or platform champion as i say might have a broader range of things that they are looking after and might only check in with the platform team on a less frequent schedule but it's still that that person that the platform uh team can go to to unblock them at a at a more senior level okay okay so and you mentioned that some of the some of the challenges that folks run into when they're kind of starting down this journey is you know say not not having dedicated folks or not having folks um you know internal to the the company itself if they're part of kind of an outsourced arrangement um what else in terms of you know let's let's imagine that those don't exist and you you actually have a dedicated team it's the the two to four people that you mentioned plus the the product manager

and you know now what happens you know does does that necessarily mean that they're kind of like up and running right away and sort of operating in that or but or what steps do they have to make at that point so i would always say they should call in the pivotal cloud foundry solutions team because that's what my team is um but our starting point honestly for for treating the platform as a product is i guess it's it sounds very straightforward but it's it's really having a product mindset and the starting point is understanding your users and building the thing that your users need so the very first thing that we try to do when we come and engage with a customer is to understand what's the first workload that you want to put onto the platform because if we can understand what the first application or the first 50 applications i mean it is a question of kind of start small and then iterate is what we try to focus on but as a as a platform team treating the platform as a product it's about putting the user right at the center of everything that that platform team does and then you need to understand exactly what the requirements are from the users and in this case the users would be the application developers so you need to understand what the requirements are then you need to build the smallest thing we talk about mvp being minimum viable platform in this case so you need to build the smallest thing to then give access to your application developers so they can use it then they can provide you feedback and then you can iterate so in pivotal we talk a lot about user-centered design we talk about lean and agile methodologies to be able to build the smallest thing get fast feedback and iterate and when it comes to the platform we are saying exactly the same things so we take all of

our labs methodology that we've built up over the last 30 years say and we're trying to take all of those practices into the platform because the end result that we're aiming for is to build the platform that the application developers want to use it meets their needs it gives them a wonderful developer experience and they are then excited to put their applications onto the platform so the starting point for the platform team has to be almost a change of mindset the platform team has to understand that they are there to serve the needs of the application developers instead of what we've seen more traditionally let's say of building what the platform team or the infrastructure team might think people need and then finding lots of other people don't put their applications or workloads on there because it just doesn't do exactly what people need it to do so the whole kind of build it and they will come model doesn't really work we're trying to do the opposite way around i know when labs is working on a new application they have those initial conversations with users to just determine what can we build that's going to be an mvp is it similar with the platform team gets some kind of feedback i mean how do they even make that decision about what the mvp is going to look like they should definitely talk to the developers i mean it feels it's very funny where we we've been to customers and we've spoken to platform teams and as domain mentioned earlier sometimes the customers are pulling in different people into their platform team but traditionally we've seen lots of uh infrastructure folks coming in let's say and then we might start off and say well let's go talk to some application developers which endangers like like horror in these people's eyes of like they actually have to go and talk to the application developers um which somehow seems terrifying but it's it's really a question of defining those user needs and one thing as you mentioned jeff in the in labs methodology we talk about the balance team of being design as well as product management as well as

engineering in our platform team we would love to also have designers in there and designers are typically the ones that would lead the um kind of user research and creation of personas and really helping to define that user-centered design when we have platform teams typically our customers is it's a hard ask for our customers to provide a product manager generally it's even a hard ask to ask them to provide a designer so typically what we would do is have the product manager take that role as well so for example when when the pcfs team would show up on a customer we would bring our product manager we would pair with the customer's product manager and then together we would go and interview users like you interview the application developers understand which application is going to land on the platform first figure out what the requirements are and then build the platform that meets those needs and then we iterate so we're we're not looking to just get one application landing on the platform we want all the applications on there but we start with one and then we get feedback and then we add the next one and get feedback and it's that iterative cycle that makes sure that you're building the right thing not that you spend six months building a platform announce it to the application developers and then find it doesn't meet anyone's needs yeah i think it's like i could i could imagine how someone would go down the path of well if we want all the applications then we've got to understand what all the requirements are and then it's like oh well there's just so many requirements maybe we should find the least common denominators and then you end up with the least common denominators that are not enough for anyone to use exactly i mean we have this this talk track within our team where we say going into production is not a binary state it's a continuum so we think about you identify the first workload and you build that minimum viable platform that has everything that it needs so maybe it only needs integration into one

database for example or maybe it doesn't for that one application maybe it doesn't need user authentication like you choose an app and you you create just enough of a platform that means that application can go all the way through to production and that's kind of step one and we think about it as uh circles which is funny because i'm i'm signing what the circles look like and now i can see what my sign language is showing but um you'd start with your core and the application lands and that's kind of production but that doesn't mean it's finished it means that you've now got the next ring of kind of requirements needed for the next 50 applications so you work out what the next workloads are you figure out what those requirements are and you add those features to the platform and then those 50 applications can go live and it's the it's sort of these building circles of you add more and more features but you add them into the road map and you prioritize them and as more features get added more workloads can land on the platform but you start small and then you iterate so now you mentioned that it's basically impossible to get a designer and so the product manager has to um often wear that hat now is that is it something that it doesn't seem to me like there's that many product managers kind of lying around inside a lot of enterprises particularly working on infrastructure software um that you can sort of oh yeah that person right so i imagine that the folks who end up as the product manager for this kind of internal platform had a very different job before uh so where do what kind of background do they end up usually having like the folks who end up being down the road successful product managers for this app platform it depends i guess is the standard answer um typically we see very some very technical product managers

who might come from an infrastructure background or possibly they've been a sys admin before and they would be people who are very much embedded in the team but very technical alongside their team we've also seen customers who have pulled in people with a project management background that's a fairly typical pattern that we see and those people again will come in and be part of that platform team all day every day and might not be as technically kind of skilled on the platform itself but have the ability to be able to seek the user requirements to run that um iteration process to get the feedback who then develop their technical skills along along the way but are coming from a a completely different background i mean we've also seen a kind of an anti-pattern i guess as we've seen some some cases where we have customers who bring in external contractors because as you say product management skills within platform teams are hard to come by so we've seen customers go externally as well which is fine but um our encouragement is always to try to grow those skills in-house and it's something that we would like to help with as well so so pivotal does offer product management training as a as an option so um it's something that we're really really keen to help customers with it's so critical we see the customers who are the most successful are those that have their own dedicated team with their own dedicated product manager and those are the ones that are able to prioritize able to meet users needs able to release features quickly i mean those are the most successful patterns we see kind of coming back to that like journey or progression of folks who are coming along so you know starting by you got to go talk to those developers right you got to interview them and that's you know work through your fears wherever

they may be coming from do you find like that the fear around like is it that they're afraid this is going to be a waste of their time are they just afraid of like having to sit there and have a conversation like i don't know if is it even is it fear really at all or i'm just curious if you've been able to sort of figure out like this is sort of the the psychological landscape of what's going on when you tell a team of you know would-be platform engineers guess what today we're going to go talk to some developers your customers it's really it's really funny i intend i attended a a pre-platform dojo workshop with a customer so so when my team gets involved we we do platform dojos which essentially is just our name for how we enable customers it's a the name of our engagement but i attended a pre-dojo workshop with a customer where we we really went deep with the platform team they had already identified their team we went deep with them on this is what we mean when we say platform as a product this is what it means to understand user requirements and build the right thing and we did a full day workshop and at the end of the workshop we did a retrospective which we love to do at pivot we love retros so we did a retrospective and one of the platform engineers gave feedback that said it all sounded very nice but it also sounded like a lot of marketing nonsense and it would never happen in real life which was really surprising um because somehow that person didn't believe us when we said no no we're actually going to talk to some application developers and we're actually going to understand their needs that's i think it's it's maybe not fear it's more just what people are used to let's say they're more used to having ticketing systems they're more used to maybe an application developer requests an

environment and then it goes into a queue and then the platform team might pick up that ticket and then might work on it it's somehow habit i guess more than actually fear um but what was really funny and that's with that same customer we then followed up with the start of the engagement and we did uh an inception meeting and for us we have a very um clear process for what we want a an inception to look like it's typically one to two days and we ask for the customer to really bring a lot of people together and often it's it's a chance for all different teams within a customer to come together where maybe they have never even been in the same room before so typically we would ask for the platform team to be present platform owner so the platform team which includes product manager we would also ask for the platform owner to be present so some senior stakeholders to come along and we would also ask for somebody from security maybe somebody from compliance and representatives from whichever application has been identified as the first app to land we want someone from the application team to be in the room so an inception meeting could have 15 to 20 people all together but in that inception one of the things we will go through is kind of a road map so we'll say how long does it take now from the application team having an idea to getting the idea into production let's map out the whole journey and let's work out all of the steps and then let's work out if you're using pivotal cloud foundry how many of those steps get taken away how many of them get shortened how many of them get automated and for an mvp how many steps does the application team care about and it was a really interesting exercise we did this exercise with this customer and the platform team went first and they wrote down all the steps to go from like code getting sent to them to it going live in production wrote down all the steps and then the application team came along and said well these are the ones we actually care

about and they just pulled down just a few of the post-it notes so a few of the things under the lines were like well which ones do you really care about and it turned out that the platform team traditionally would do a whole heap of kind of work that took a lot of time that wasn't delivering any value to the application team and i think after that inception you could suddenly see that for the platform team there was a kind of something resonated with them that made them think there might actually be some value in talking to the application team after all because it could cut out a whole lot of work that they were actually having to do that they didn't need to do to be able to deliver a kind of a sandbox play environment for the app developers to start testing immediately and giving feedback so in order to get the light bulb to go off you have to first get them in the same room do you think yeah i mean that's that's what happened in that one case yeah uh i would hope that when when when we're talking to our customers we can try to articulate it in a way that the customer understands the value but sometimes seeing is believing honestly so i think for for those folks who are thinking about or who are in a platform team or might be selected to form a platform team it might seem daunting to think everything's going to be different but it's also liberating to think that just by understanding what minimum platform looks like it could reduce hours of toil hours of wasted effort that isn't actually delivering any value and it allows the platform team to be more productive which then allows the application teams to be productive quicker which being a virtual circle everybody goes faster and it's a win-win for everybody okay so allowing the platform team to go faster

since that that's the team that kind of has to make this shift into the mindset so after something like an inception what happens next what what starts to change and what what do you think folks um should be trying to do at that stage and what might be some anti-patterns at that stage i think one one good pattern that we've really seen is when a platform team gets into the habit of seeking feedback and it's a it's again it's a hard mindset to to shift into but we've seen customers who have really been able to accelerate their um kind of standing up of the platform scaling of the platform because what they're doing is every week they might be running a lunch and learn for stakeholders or they might be running a demo for app teams and it's about being able to show a wide audience the capabilities of the platform that they've built as quickly as they can so it's about getting as fast feedback as possible and by doing these regular like say lunch and learns or brown bag sessions or demonstrations of the platform they get immediate feedback and they have the added added benefit of building some excitement internally so by publicizing the work that they're doing and by being able to deploy things quickly ask for feedback make changes quickly they they build up that internal desire for the application teams hopefully to want to get on that platform as fast as they possibly can so it's a really good pattern that we've seen that once a customer engagement starts we will try to encourage that almost from the first week let's build a thing and let's show people by the end of the first week

what have we built what does it look like let's get some feedback and then putting that pattern in place so that continuously happens and it's just normal behavior is a way that the like say the platform team can learn quickly and make changes quickly i think what we would consider an anti-pattern is the customer maybe starts off well goes and asks for requirements but then starts building and doesn't show anybody anything so delaying that feedback is is really an anti-pattern i would say okay is there any role of data and how that that reflects how the developers are actually using the platform because we know at times people think they know what they want but don't necessarily know what they want is there does data play a role there potentially i think it's going to depend on on on the applications themselves and the developers and what they're looking for uh quite often when a new technology is coming in like pivotal cloud foundry the application teams a lot of them won't know what those capabilities are so the starting point when we do demos for example is we have to show the capabilities of the platform so that the app developers know what they could change um another thing that we try and do on the education flipping hats for a second and putting my education hat on uh on the education side we have a couple of trainings which are more focused for application developers so we have the platform acceleration lab is a offering that we have and it's about training developers how to build cloud native applications and then we have a three-week course which is about training application architects and more senior application developers on maybe how to refactor applications and how to migrate applications so it could be the case that we need to give some

education to those application teams because they don't know what the platform capabilities are and maybe don't know what as you said maybe they don't know what they're asking for necessarily because they don't fully understand what new capabilities are available to them so at the same time as the platform team is going to ask those developers what do they do now what tools do they need what services do they need etc there is a corresponding education that needs to happen for those app teams that teaches them what the platform can do that might teach them more around how to build cloud native applications depending on where that customer is coming from or where those app teams are but if they aren't used to building you know if they're not used to kind of 12 factor applications that they're not considering some of the things we think about for cloud native applications there's a corresponding amount of education that should happen for those app teams as well um back to the kind of good patterns um and what you said about getting feedback the and you sort of address this in your answer because my question is like okay well what does that look like how do you get that feedback i mean my first instance like you know i think about can we get your feedback i think of like a survey you know and it's like which can be useful for certain things but you know seems like that's not the full breadth of feedback uh exercises that you can do and you mentioned like okay well doing like a brown bag lunch and learn or a workshop or just a demo um these are also ways of getting feedback and i think like broadening the kind of uh sort of your your mental vocabulary around ways that i get feedback is part of the solution i mean i for me i i wouldn't have thought of those things but it makes sense when you explain it now if you're in a kind of an organization that's like not used to

lunch and learns and internal workshops and internal demos you know how do you recommend folks get started with you know hey this we're starting this week we want to we want to give a demo by the end of the week um how do they do that in a low friction way to does it matter how many people they give that demo to if they're able to just grab a handful of folks or what do you what should they do to kind of start that process i think a key starting point is identifying the stakeholders so one of the exercises we would do in an inception meeting is we we would figure out the stakeholders but we group them so we'd have people who are core so that would be the platform team product owner product manager then we have interested so people who should be involved in lots and lots of the meetings but are not part of the core and then we might have informed stakeholders so people who are not paying that much of close attention but could be somebody from finance who's paying for the for the work or could be somebody from compliance who just needs to keep an eye and there's something again about starting small and then iterating so if you're a company that doesn't have a strong practice of internal demos internal lunch and learns for the platform team when they're getting started as a minimum they need to figure out who the key stakeholders are and have those folks attending at least a demo once a week and if there's an opportunity to record that and share it more broadly that's a good start if there's a way of inviting other people to attend remotely so using zoom or skype or you know webex whatever the tool of choice is then that's a good place to start i think it's it could be daunting to think i need to demo this i need to get the whole

company to show up in a room at lunchtime and yeah and have a look um again we're all about starting small so it's finding that that low friction way whether it's a dial-in whether it's just a small group of stakeholders to begin with um and then another way to think about most most internal teams hopefully would be having some regular like stand-ups for themselves for the teams maybe there's an internal all hands if you can't get people to come to your scheduled meeting trying to figure out if you can get a quick slot on other people's regular meetings asking for a 15 minute slot on a company all hands or a company town hall or a regional meeting whatever the the company schedule is to be able to then just go and show up and do a quick demo could be another way to start that process all right well i could keep keep going in terms of pulling the thread on the like and then what happens and then what happens um but i know that you know this uh this can't be the never-ending podcast um where do you recommend folks go to kind of just learn more about it obviously engaging your team in this process is hugely helpful and i've heard from many many customers that you know attribute their success to we did that dojo right we did the platform dojo we wouldn't have been able to get this off the ground if we hadn't done that um so it's a huge testimony to to what your team does but you know folks who are kind of just listeners and want to learn want to think about applying this stuff where do you recommend that they go to learn more any particular resources or any kind of just general resources how can they follow you well that's a great question so in terms of resources on our pivotal website we have a white paper that was co-authored by one of my colleagues in the u.s joe fitzgerald

and uh colin humphries who's based here in london who's in the r d team so they co-authored a white paper which actually is called platform as a product so i would recommend downloading that as a great resource just to to have a read through there's as you mentioned at the start there's a talk i did at cloud foundry summit last year which is also available on youtube which talks quite high level again it's not very detailed technically but it talks about some of the things i've mentioned today about how to treat the platform as a product what the team should look like some of the step-by-step practices that that team should have in place um definitely if customers are ready to go all in and have a engagement with pivotal they should engage my team or my colleagues around the globe because doing a dojo is a great way to get started for sure people can follow me on twitter if they feel like my twitter handle is paula l kennedy or one word that's probably the best ways okay well that's i think a good good set of stuff to get started with you got reading and watching and uh tweeting in there so you've covered you know like the holy trifecta so thank you so much this has been great i really i learned a lot about thinking on that that feedback process in particular and um putting that in perspective of how important that is in the overall journey to becoming a you know a product oriented team within your your kind of platform practice so thank you and looking forward to hopefully seeing you again soon thanks domaine thanks jeff

Tanzu Talk · 🍕 Get more pizza.