Platform as a Product with Bryan Ross

Episode 234 · Tue, 16 Aug 2022 07:03:00 +0200 · 1:02:19 · SRT · archive.org · all Tanzu Talk

Today, what I thought would be nice to talk about, there's almost, we'll find out how you feel about this, but I think there's like this great resurgence in a topic. It has lots of names nowadays. You can think of it, we've always called it platform as a product. I think people call it platform engineering sometimes. You know, I think DevOps has come to mean a pretty specific thing and everyone tries to call themselves SRE people, but all the thought leaders still, I think, will say you can't call yourself SRE. So it hasn't passed through that needle of the orthodoxy has gotten tired of telling people they're doing it wrong. I don't know if that's true, but it's a fun little story that I just told. It might be totally cool and it's fine. It's like, I don't know, to go down that rat hole, it's like, you know, people get all worked up about SLOs versus SLAs. And I always think like, I don't know, maybe we should clear that up if it gets confusing about things. A tool that's confusing to use is maybe not too great. Wow. I'm really going off on a tangent here. But so I thought, you know, we were, we were talking and I'll let you introduce yourself soon. And I think, you know, you have a lot of experience with this idea of, of platform as a, as a product or platform engineering. So I thought it'd be nice to kind of get a, a new perspective on, on what that is there. Not new, but get an additional one, especially someone who's, uh, who's got some experience and has been talking with a lot of people. But before that, why don't you introduce yourself guest? Absolutely. So thank you first of all, for having me on the show. Um, it's for the nice of you. So my name is Brian Ross. Uh, I recently joined VMware, uh, in May there and I work in the Tanzu value advisory. So we go out and give exec, um, advisement and engagement to some of VMware's top customers. Before that though, I was at Sky TV, uh, where I was responsible for the technology products department. Um, and we built platform as a product. Um, so we had IaaS services, CAS services,

PaaS services, and all of it was really just based around trying to give developers at Sky the ability to get whatever great idea they've got in their head out into production. Um, and Sky being in the media sector, everything's about speed and agility. So doing that with the least amount of friction is, is the most important. Um, so yeah, platform as a product to me is, is vital. I think the, um, the interesting part for me is that it's not just about the technology. It's kind of about people and culture and understanding some of the, uh, philosophy behind it and some of the, the psychological factors in terms of encouraging people to do what you're doing and helping you along there rather than doing their own thing. So, so give us a, uh, um, I mean, I guess as long as you want, what's the old saying? It should be as, as, uh, as long as necessary, but like, so what, what, what is, and, and kind of, you know, uh, I guess maybe differentiating from like not platform operation, a platform as a product, like, like what, what does it mean? And, you know, you listed, you listed kind of a stack of technologies, which I think is an equally valuable part of the concept, but, and, but there's also, as you said, the processes, the way of working, uh, around it. Um, but yeah, I, I mean, what, what did the, the concept end up meaning in, in practice, uh, as, as you were doing it and talking with other people doing it? Well, don't even give me permission to ramble. Um, that's, uh, there you go. Um, so I think for me, it's, so I was very lucky in many respects. I, my past career has all been around managed services and consultancy. So being in front of cupboards has been a major part of my role. And it's the bit that I really like, it's helping people get the best in technology. I think from that, um, the big thing for me is that it's, it's almost like running a company within a company. So you stop really thinking about some of your, your colleagues as being

your colleagues. And instead you think of them as customers. And that I think is the first big transition. So if you're working in a team and you look at you, the people that you're serving as customers, then the mindset and everything that follows from that is very special. Whereas, you know, the classical operations team would be, you know, the IT department probably hidden in a basement somewhere. Um, you know, you would, you would only interface with them through, through tickets and service now or, or some other platform. Um, so I think when we look at platform as a product, what we're really talking about is how we go about selling what it is we've got internally, but I think as well, that, that, um, changes as well, how we develop things. So the first one is really just how we engage. Let's talk about that very quickly. Um, so you have your technology platform. That's fantastic, but who's going to use it? I think you need to consider all things that go around that product. So that might be marketing. How are you going to tell everyone in your company what a great job you're doing? Um, you know, we've all got very bad internal, you know, websites and things. How are you going to make your standout? So, so for me, it was, it was a $5 bootstrap template, very graphical, very low on content, but something that felt like a hosting provider. You know, if you're going online and shopping about for providers, it's the type of thing you might see there. So very sales oriented sales in itself, you know, going out and asking people what the problems they've got are, um, working around your internal users and business units and not trying to overly sell them on what you've got, but really understanding where their pains are and trying to build your product around that. You've then got the technology part, building the platform. And I think that I'm dismayed at the number of businesses out there that are building something like a platform in complete isolation. Usually it's the infrastructure team. They'll put something together. They haven't actually gone out and asked developers if this is what they want, or is it solving the right problem? Um, I think it was one of, uh, one of your talks where you were

talking about, you know, we look at process automation a lot of the time and improvement, and we talk about making that box better, faster, whatever, but we don't really look at the interlinks between the boxes. What happens in the handover? And I think that's one of the critical parts. It's the, where's all the friction? And then around there, you've got things like your, um, your support and the policies that guide it. So again, if someone's got a problem with it, how do they contact you? And, you know, spoiler alert, I don't think raising a ticket for everything is the right answer. I think, you know, you want something a bit more human. So, um, that might be a Slack channel that might be, um, weekly drop-ins that could be monthly innovation sessions where you get into an auditorium, invite as many people as you can, and just talk about what you're doing with the platform. It might be community events where you're doing something fun just to try and get all your users, customers together into one space. So, you know, how you go about approaching the, like what you are and the value you bring, I think that's really important. So you cannot produce a platform without customers. If you do that, then you're not adding value to the business. And then the second part of it, I think is just about how you, the mindset of the financing of it, which is always the big enterprise, right? Traditionally, what happens is we're still stuck in somewhat in a waterfall method where you have a great idea, you go to finance, you get some money for it, and then you have a project that might run for six months, 12 months, 18 months. You promise some really big outcomes, and then you work hard to deliver against the outcomes that you set at the very beginning. And then there's an expectation at the end of the project that something is finished. And of course, if you're running a company and selling products, you're never finished. And I think that's the other critical part. You're working with your finance team to explain that we're not building a project here, we're not completing a piece of work. We're going to build a product that's going to continue to grow with the business and grow with its user base. So yeah, those two things I think is platform is a product to me. And I think

it's probably quite different and hopefully quite refreshing and people saying that, yeah, that's what we should be doing, right? Sounds great. It sounds like common sense to me as well. Like if you, you know, if your department isn't adding value back to the business, then you're not selling something. Like you don't, I think IT was always traditionally the cost center. And I think that's the thing that we want to try and turn around with platform as a product. We want to be able to demonstrate our value and perhaps maybe even sell those things to our internal customers for a cost. So there is a real value attached to it as well. Well, well, first of all, uh, you're, you're a very well organized in your rambling. So, so excellent job there. I could all, I could almost see and feel the bullet points and the, uh, the, the McKinsey title slides as we were moving through it. So that's, that's great. Uh, yeah. So, you know, there there's, there's, I think there's several there's, I mean, obviously each of those items I think will be fun to dig into. And I think let, let me, let me run by you as, as I talk about this topic with people. I mean, I'm, I'm always in this weird role of like, I don't actually do anything firsthand. So I just, uh, collect, uh, comments from smart people. I've got that cliche disclaimer about stuff, but whatever. Um, like, like when, when I was, when I was thinking through platform as a product stuff recently, like you hit on it at the end, there is, I think, tell me, tell me what you think of this. I'm going to state it as if it were true. And then, and then we can discuss it is that when, so when you're talking about platform as a product, the kind of the audience that you're primarily talking with are like operations and infrastructure people, because that's, that's what you're talking about is infrastructure that developers use. And I don't know, just a footnote, a major assumption that I think we skip over is like, well, we don't skip over it because you mentioned developers as customers, but all of this is for running applications. Right. And, and, and the shorthand, you know, it's good to stop oneself from disclaiming over and over again, because then the footnotes become

the primary text. But like, um, like what, as a shorthand, what we say is developers. And that actually means like, you know, all of the people involved in deciding what features are in an app that is helping a business run, but whatever, we'll say developers. Uh, so like essentially, like if there aren't developers involved, you probably don't care or need to know, care about platform as a product, because as you said, they are the ultimate customers that you're servicing, which brings me back to the, the idea I've been trying to develop, which is like, so traditional, I'll just call them operations, people like traditional operations. Like I think over the past, I've lost track of how long ago this is, but over the past 20 years, they, their, their, their view, philosophic viewpoint, if such a word can be applied to work has been, I provide a service, right? Like my job is to provide a, uh, basically like uptime and availability, like, you know, whatever the services, whether it's networking or running your application or storage that's available or performance, like my customer. And this is where it gets a little like too metaphoric. My customer are metrics, right? So my job is to make sure that these metrics are in an acceptable and a green state, right? And this is where people get all upset about SLAs and stuff like that. But I, I, you know, as with most things that we seek to change, it probably was a great idea at the time, right? To, to, cause, cause you know, my, my version of this story, like having worked at BMC software a long time ago is like, you would be shocked nowadays with the, the reliability we have nowadays and how terrible reliability was in, in the 2000s, right? Like stuff was just going down all the time. So it was almost like if you were in operations, it would be a career's worth of work just to make sure the email server stayed up enough,

right? Or to make sure that the application you had stayed up enough. And so that was a totally valid thing to focus on just those metrics. And so that seems like the first sort of laying it out, that I've been thinking of is like, all right, operations people, your customer forever, for good reason, has been metrics, just uptime and availability. And now as you're going into, it seems like the reason we talk about this much is like as an operations person, and you mentioned it, right? Like the shift you need to go through, and this is the product part, is that now your customer are those developers. And of course, it has to work, right? Like, like the software has to stay up and be available. But that is, because we've done so much work there, now we can move on to a different problem, right? Like now, it's, I hesitate to say the word easier, but now it is less difficult to, to like ensure availability. And so we can do more, right? And that more is that we can start thinking about how we make the process of running applications of developers better. And, and that's why, that's why this conversation is important, because there is a big mindset shift that I think people aren't quite aware of, when, when they're thinking about doing platform as a product. And, and it's important, because if you don't, if you're not aware of like, you're, you're trying to change that habit and that mindset, then you'll just kind of fall back to satisfying that, like, you've got to kind of be walked through thinking that, I don't know. So what is that? Is that? Is that a storyline I can start using? Does that, does that, as we say, back in my neck of the woods, hold water? Does it work out? Yeah, I, I think there's a lot of truth in there. Um, I think it's maybe important as well to highlight that, um, you know, we talk about operations and sometimes there's like almost a negative connotation to that, but I think it's important. The thing that you've drawn out there is that it's not, um, it's not a blame factor in any way against operations, people not doing the

right thing. I think you, you're absolutely right in that the, the priorities for them have changed. And I think that anyone in a role just now where they are running a big platform and they feel as if they are hidden in that basement, metaphorical basement, perhaps, um, now is the right time to, to really start to think about engaging with users, with customers and changing that mindset. Um, I think there's a lot of value that comes from that, not only for your department or your team, but I think personally as well, like I, the reason I enjoy working customers, customers so much is, is because you get to see the fruits of your labor. Um, and in Sky, I think there was a, there's always a huge part where you, you almost had to, you know, put your head up now and again to remember the end result of what you're, what you're working towards. It's not really about uptime. It's not about which server choices we make or how hot that CPU is running or how great the data center is organized. What we're really looking at is, is tele still working? Is broadband still working? Can people contact us when they want to, right? And I think the, it was always great in my team. We were based in Scotland, as you might tell from the accent, but it was great going down to London where you'd actually be right next to the recording studios, for example. And I always made a point of getting my team down there in real life. So they could see and touch the business that, that is really the, the front part, you know, rather than just the, the backend servers and the, the day-to-day worries. Um, so I think the, uh, the other part for operations as well is, is, as you say, things have changed for them. And I think the, when you were talking about, they provide a service, I think there's some operations team that's perhaps they, they provide knowledge and, and that's the, the skill that I think that they've, they've really got. And they definitely do have, and you know, I won't get started on a DevOps ramble about how that's been changing and trying to bring teams together, but they've got a lot of knowledge and skills and running things and running big things and managing, you know, disparate states.

Right, right. But I think the thing that's changed as businesses now, we need a better way of surfacing that. Previously, it was SLOs, SLAs. It was all measured and uptime. Whereas now that knowledge and that expertise is bubbling more to the surface. It's how can people leverage that? And I think that there's, um, I think businesses that are really able to get the most out of their people in that way and give them the opportunity. I think that can be a real, um, differentiator in terms of scale. If you've got a business that's doing really well, you're not going to get any faster unless the engine can keep running cleanly, right? That's, that's right down to oil and your choices there, right? It's all the little bits that are going to come together to make that big change. And I think if you're a large business and you're doing great things, if, if the engine is running dry and it's creaking, then you're not going to be able to expand, you're going to have a bad time. So, so maybe let's see, let's, let's try to, uh, I mean, I will do this as, as the, uh, the host here, but maybe let's try to organize this, this conversation. So if you're so well organized, maybe you have a better idea, but, but maybe we can, let's, we can work from the top of this concept of like developers as customers and then kind of like move towards like, what does this imply as far as the, uh, implies a weird word. What, what, what does this mean as, as far as the, the day-to-day work that, that operations people do, the platform engineers? And then I think it would be good to end up with like, well, then, you know, what's the technology supporting this, right? Like I assume we're not running windows 2000, uh, when we're doing this. So there, you know, this is one of my personal pet peeves is like, everyone's always like, Oh, technology is easy. It's people that hard. And I'm always like, are you, are you sure about that? Cause I'm pretty sure technology is difficult, but one of them might be more difficult than the other, but technology is definitely very difficult. Uh, but, um, so you, so yeah, I mean to, to that end or, or, or following up on

the, what I was just saying, I guess it wasn't so much a suggestion as a statement, uh, but like since, since you, you have done this and been on teams of it, like, what is it like to shift to thinking of developers as customers? Like, what does that, what does that mean? And, and, and what are, what are the different habits and kind of workflows that people change? Like you've highlighted, I mean, just to throw out one thing, right? Like, uh, well, previously for most ops people, the primary interface out of the basement, so to speak, uh, is basically a ticketing desk, right? Like there's other ones, but that's probably the most frequent way that you interact with, with other people and kind of get a sense of what's going on. Um, but what does it start looking like in a, in a, in a platform as a product mentality? Well, I think the, the most interesting thing is when we use the word customer, I think because it's such a, a well-known term, it automatically in everyone's heads, they should be thinking of a few key parts. So the first part is if you have customers, then you have customer service. And that's, there's a big jump there straight away. That is the idea that, well, we have someone that's asking us a question and there's a few ways we can answer that question. Now the traditional way might be, sorry, this is the wrong type of ticket. You'll need to raise ticket 472 for this, um, or no, this ticket requires management approval. You'll need to go back through another couple of steps. Whereas if you are focused on a customer, your response is going to be different. It's going to be, thanks. Thanks so much for getting in touch. There's actually a different form to do this, but let me raise that for you. And I've cut and pasted the details for you, but next get it direct by going to here. Right. Wouldn't that be nice in life? If people are like, you've done something wrong and all I have to do is, is cut and paste to correct it. So I have done that. And you know, if you think about it, you go to the supermarket and you, you, first of all, you find someone who's identifiable as staff. They are there

and they are present. They are there to help, right? You don't have to walk all the way to the front of the store to wait in a queue to find someone from customer service so that you can ask them where the sugar is. And instead you'll find someone nearby on the aisles because they're, they're there and present. And when you ask them where the sugar is, they're, they're probably going to guide you exactly to where it is. And then they might advise you on what kind of sugar you want. Right. And that's the big difference with customer service versus a ticketing system. And the better you are at customer service, then I think the more engaged your user base is going to be. Unsurprisingly, if you're nice to people, they're more likely to come back and ask either for more help or just be more nicer to you when they're looking for something. Yeah. You know, I think just to, to just go on that a little bit, I mean, one, like even worse to, to your, your, your metaphor there is if you were looking for the sugar, if you were required to write down on a slip of paper that you needed some help and go put it in a box somewhere. And then just like something. Yeah. Yeah. And, and like, I mean, I think, I think, I think I, again, like, like you've gotten me really interested in like going from high level concepts to like what that, what that means from shifting from one way you think to another, that kind of determines like just your actions and your habits. And like, I think your sugar one is a good example there of to, to a certain extent, like in a traditional way of doing service, you see your job as like solving in the best possible way of solving problems that the person is asking for in a ticket. Right. So the problem there could be like, uh, what I need, where is the sugar? And, and so you could, a good answer would be like, like, it's on aisle six, you know, next to the coffee, whatever. Right. But like, as you're getting to, but you also, without it being too like highfalutin of like, you know, I always get annoyed by strategy. Things are like, we're not actually a company that has a bunch of trucks that delivers packages to you. We're a dream maker, right? Like, it's just like, Whoa, you've gotten way too

high up the stack. Like you actually are a company that has trucks that delivers packages to my door. That's what you do. Right. You know, like whatever, but there, there is a certain level you can go up where you're aware that like, well, when they do get to that road, there's going to be 15 types of sugar. And I should make sure that they know that they are able to be successful at what they're doing. Right. Like, do they want fine grain sugar? Do they want sugar-free sugar? Like, so it might behoove me to at least go over there and be like, we've got 15 types of sugar. Do you know, do you know that you know which one you want? Right. And so even, even that level is like, that starts to get to more of a product management standpoint where in order to solve the first person's problem, you have to ensure, I mean, this is tricky without being pedantic and a bit of a jerk, but you've got to be like, do you know the criteria by which you're selecting things so that you are solving the problem? And even doing that, like, I mean, I feel like that is a 30% of what it means to think in product and customer terms is just making sure people are aware of, uh, of how they're solving their problem. And I think the, the, the differences in when you look at from a customer service perspective, you're no longer trying to catch them out. You know, you're no longer trying to show that they don't know what they're doing or what some of the traditional things would be, but instead it's, it's honestly, you're trying to help. You're like, well, what's your making? And some of it is honest curiosity. Like, what are you going to do with the sugar? Are you building, making a cake? Are you having a birthday party? That's amazing. Do you know we've got birthday cards in an aisle seven? Do you need anything else? Is there something else I can help? Can I get an invite? Um, you know, the bunch of stuff there that, and I think that again, none of this is rocket science. I think this is simple human interaction. And I think that's what for me bringing customers back into the equation really does is it humanizes everything we're doing. There's a reason why we're working on this SSL certificate. Okay. We need to get it

renewed right now because it's about to expire. Well, obviously now it's an urgent thing because you missed your date. That's terrible, but I'm, I'm not gonna, I'm here to help you. All right. You're in a hurry. No worries. We've got an express aisle. Let me work that through for you. I understand that you're in a rush. Okay. We'll get this done next time. It would be great though, if you could tell in advance from it. Yeah. Service that will monitor it for you. And that way we can tell you when you're about to run out sugar or you can call us and we'll, uh, we'll have someone reserved for you. That's, that's, that's a good, that's a good de-sugarified example, so to speak. Uh, a little more literal example is cause I'm sure it happens all the time. Right. And, and like the, the simple, the, the ticket-based way would be to like, well, the problem they're trying to solve is they need to renew a certificate. So I will tell them how to do that. Or the advanced level is I will do it for them. Right. And that, that would be nice, but the even, but more of the, the product centric way of doing it would be to say like, well, we've got to solve the immediate problem. So we'll do that. And as you were going over the, the problem that they're really trying to solve is that they want things to be secure. And that implies a whole way of them operating and things that they're going to be doing. And so we should make sure that they're successful at that. Right. Like not just when they come to us and ask for something, like we should help them out and maybe get an invite to the party. Uh, and so like instead what we should, we should solve the problem and also like see if they will let us help them make sure one, this doesn't happen again, but that they are doing things in, I don't know that they're doing, I don't, I can't find the words, but that, that they know the activities they should be doing to ongoing, make sure they're being secure. Right. Almost like kind of help them out in, in, in solving the problems that they had. I don't know. I kind of lost the thread there, but it does seem like there's a good shift in just like, oh, we've renewed the certificate for you, or here's a form to go fill out and you can renew it versus like, yeah, let me get involved a little bit and help you out to make sure that you're set up correctly with that.

I think that's it. So if you mix a little bit of curiosity and honest curiosity, we're not, again, we're not trying to berate them for the fact they haven't got an SL certificate renewed on time. Instead, we're saying, oh, you're doing something secure. What, what websites this for? Because again, that's one of the important things, right? It could be an internal, you know, um, CICD pipeline that we're working on, or it could be the company's main website, you know, and it's really important to maybe understand that. And then you can get involved in that conversation. And again, if you are approaching things from a position of trying to help, I think that many people react well to that. And so throughout this process, you're building personal relationships too. Um, you know, so to take this into something that's more real, if you've got a ticketing system, the problem is it goes into the IT department and it's just this black box and worse still, you might get a response that comes back signed. Thank you. The IT department, you know, nothing personal about it at all. Right. Whereas if it's a Slack channel or a Teams chat or whatever medium you choose, all of a sudden becomes individuals just talking. And again, I'm, I'm a really big fan of trying to, to encourage those by any means, especially if you can get people face to face, especially if new customers, users in one room too, to talk about their own experiences. Bearing in mind that from a platform perspective, not all of it's going to be positive, but how you react to that's going to be the main thing going great. We've got five customers that have all got the same problem here. This is clearly a big priority for us. We are going to replan the next six months and we're going to fix that problem for all five of you. Is there any way else in the room that has having this problem or a problem like that, you know? So, so that, that's, that's, that's another layer down of, of the practical stuff to, to discuss, right? Is like, I mean, you, you just said, this is what you do. So I know the answer to this, this, this rhetorical question, but like, man, it seems like that's a lot of work and, and in the sense of like, you know, for, from a, from an operations person's person's perspective, one of the

reasons you have a help desk is to, uh, so you're not overwhelmed and so that you can keep track of what the requests are and like, be able to respond with them instead of losing track of stuff. And like, you know, it seems like if you move everything to like Slack, you're just opening yourself up to chaos, right? Like to all these requests coming in and you can't really prioritize it and track it. And you know, who's going to, you know, there's, there's all sorts of practical things that helped us as like assign it to a person, you know, figure out if it's, it's been, uh, ignored for too long, give someone a reference when they want to check on it. Like there's great practical things. And so like, what does it actually mean if you move to like more of a conversational way of doing things? Like, how do you make that work? I assume you don't just have a Slack channel and you're like, see you there, everyone. That's a really, really good point. And you're absolutely right. We, there's going to be the right tool or the right medium for that type of conversation. Um, and again, trying to hold it back from technology, talk too much and make some real world examples. Right now, most businesses are looking at digital journeys for their customers. And you know, there's two sides to that. One is that it's better for the customer. If you can pick up your phone, you can, you can get the answers you want. You can make the changes to your account that you need to do. And you can do all of that asynchronously without, without having to get involved with, with a deep and meaningful or, or delay. That's great. The other sub part for the, for the business is that if you've automated that process, you perhaps need less people involved in running through that manual step of verifying the customer and then making the change. I think the same thing is true for technology teams. Like you need to have the right medium at the right time. So I think the tools like Slack or teams is a really good front door. Um, so if you have a question about how to use the product or, um, what the product is, or you have a technical issue,

if it's really simple, then go ahead and answer it straight away in Slack or teams. If it's a request for work or a change that has to happen, then there's a better place to track that than Slack more than likely. Um, so in an ideal world, it would be automated. You'd have self-service for all the things that your customers want to do. That's not always going to be the case for anything that's not automated. I think you then want to, to have that ticking system. And again, how you go about raising the tickets may be part of it saying, well, I can't answer that here. So what I've done is that I've put that in the queue. Um, I've raised a ticket. Here's your reference number. An engineer will be in touch with you over the next couple of hours or days, depending on what, what the problem is. And again, this is where the classic thing is, well, is this dev or is it prod? Is this urgent for you or not? And if you say it is urgent, can you explain why, what's the business impact? Um, and that will help you through having a conversation to raise the right ticket first time. Um, and don't get me wrong. I don't think you can run an entire business this way. I think it's, it's down to specific parts. And I think a platform is something that can be heavily automated because your goal is to say, should be that everything that a customer wants to do to engage with that platform should be automatable. So if you look at the likes of our hyperscalers or Amazons or Googles or Microsofts, it's not very common that you have to phone up Microsoft, Amazon, or Google to ask them to do something on their public cloud, right? So a platform in your on-prem bearing line might be hybrid as well, should be kind of similar. If you've done your job, right, is that you should have a self-service for most of this. So it's, so that that's, that's good. Cause it's, it's like, well, I mean, for many reasons, but like, it's making me think that if, if, if you were to try to be specific for the reason to be concise, uh, like the change that you have is usually traditionally the, the, the we'll say tickets, traditionally tickets are not only the primary, but maybe the only interface to the

basement, right? Like the only way of interacting the only town square, if you will. And then it's not so much that we're suggesting changing that it's that you add an additional, you somehow separate out when are we doing basically like knowledge sharing, like answering questions about like how something works, general knowledge sharing. And that's something that you can do in more of a whatever you may be using a Slack channel somewhere. And it seems like you have to manage, manage, you have to set expectations on either side of the question answer thing where somehow the people answering the questions, they have to understand that it's more like going on the internet and going to like, you know, stack exchange or whatever, and asking a question. Right. Which it's kind of like that shift that everyone had to go through in the two thousands to realize that like Wikipedia was actually better. Right. Like, like everyone was like, what do you mean anyone can come in and edit? Like, it seems totally unreliable and crazy. And like, and, and then it turned out that like back when there were great concepts, like the wisdom of crowds before that was ruined by the crowds actually coming, the mobs, so to speak. Maybe there's, there's a distinction between a crowd and a mob. Uh, but, um, what you realize is that it was the, the, the nature of that medium was actually better for sharing knowledge. And similarly, if you set that expectation that like, if I just have a question about how something works, or even if I'm trying to, I have a problem that I'm, I'm getting around to, it probably will be better for me to have almost the no promises that I will get a response that is inherent in, in like a, a chat channel. And so if you can kind of separate out that bulk of things from, from a, uh, a help desk thing, uh, then that allows you to when a help desk with the help desk, it's more, or a ticket, it's more, here are almost sort of specific actions that need to be taken, right. Versus, or, or like a crisis, like you were saying.

And it seems like if, if, if, if you can separate things out like that, then it becomes better for everyone instead of filtering everything through that, uh, that ticketing system. Yeah. And there's a, there's two really interesting things that you touched on. Um, so without doubt, just, just to clarify, if there's a production incident, Slack is not the right place to tell people like that. Right. Right. You know, there should be other, there should be a more progressive on-call and everything else. Right. As you say, the, the different mediums should come with almost an SLA, but let's not be too specific about it, about what's the expectation on response. Um, and then coming back to this idea of, of people in a town square, the nicest thing that, that I saw in my time building these platforms out was the community that you end up gluing together around these products. Hmm. So if you are operating in the open and transparency, people are asking questions and you're answering them. Well, first of all, now it's searchable in Slack. So that's, that's a great place to start with. Anyway, it's not a one-to-one anymore. You can actually possibly find the answer to your question already. The other thing is it's not just your team that's in that Slack channel. It's all of your other users too. So, um, so in Sky, some of our platforms would have a thousand people in that channel and we would have advocates who, who for whatever reason, when someone asks a question, if they know the answer, they'll answer the question. It doesn't need to be an engineer from the platform team. So a lot of the interactions are actually just customer to customer. Um, and I think that becomes really powerful. And again, if you're, if you're smart, just like in a business, if you've got someone that's an advocate for your product, I almost said influencer there, but I'm going to hold myself back. But if you've got an advocate for your product, then you're going to encourage that. Right. So, um, I've seen in other

businesses where they have, um, almost a loyalty program whereby if you are shown as knowledgeable, or you pass some kind of test or, or there's some bar that they've set, if you can show that you're at this level, you'll get a badge next to your name or you'll free resources on that cloud platform for your own test and development purposes. Or we will give you the opportunity to, to lead a talk at one of the conferences about how you're using the platform and how you're getting the best from it and what it means for the business. So I think the, when we start working with people, we need to remember as well that we're really, what we're trying to do is build a community around that. And a portion of your, your audience is going to turn out to be advocates. Don't go wrong. You'll also have some people in that audience that perhaps don't like your product as much. They're going to, they're going to complain about it. And again, customer service wise, you should have two Slack channels. You should have one, which is public facing for everyone that you're, you're working with. And you should have your private Slack channel with just your team members in it. And that's where you complain about your noisy customer. That's where you've been playing about this question again. That's where you, you go, Oh, Oh, that is nasty. That's terrible. What can we do about that? I don't know. You know, you work out all of that in the back room, you know, let me go and have a chat with someone in the, in backstone and see if we've got one. That type of thing should have that back channel so that in terms of customer, it's a really nice, clean environment. They're seeing the best of you all times. Um, you need your, uh, you need your group therapy, uh, to just maintain a morale. Well, customer service is hard, right? Putting a smile and being nice to everyone all the time is hard work, but there's a reason why there's an industry and, um, and training and expertise in that thing. It is a skill. So I, I, I mean that, that, that topic is great. Like that would be, uh, uh, that's a whole, uh, the whole, whole other area, a whole area there to, uh, sink

down into, but, but I want to move to something else that you brought up, which is, um, the, you mentioned this and I, this is one of my favorite topics in this area is basically like the marketing that goes on with things. Right. And, and, uh, I'll, I'll use your word, uh, you know, you need to build up influencers and, and even advocates, uh, that are doing that and marketing around it. And, and like, talk about your experience with that, like the amount of internal marketing and community building and even brand, uh, that, that in your experience you think is necessary for the, for this, this approach. So you've, you've, I think you touched on all the big keywords there. Um, so I think first and foremost, understand what it is you're actually trying to build and be able to articulate what problem it's going to solve. And that can bring this back to, back to technology that cannot be, we're building Kubernetes platform because that's not solving a problem. That's, that's just a technology. Um, so what is, you're really trying to solve? I think the next thing is find your first customer. Don't go ahead and build a platform, find your first customer, someone ideally that you've done business with already that they have this problem. You're going to help them solve. Now, bearing in mind, there's a lot of trust there. You haven't built a platform yet. They've still got a problem they're challenged with, but try and build a partnership where you promise to be really responsive and help them build. Um, I think that's really powerful for a couple of reasons. I think the first one is when you're having your chat with your finance team, you can now draw this back to a business benefit. We're not just building technology out. We're doing this, this part of the business can make more revenue. Um, also, as soon as you're successful, we'll just assume that you've been successful. Um, but as soon as you're successful, you've now got your first advocate. So you take that customer on a roadshow, you talk about the, the challenges. And I think being open and transparent is an important thing. So for example, you know, I've been at the, uh, VM world now VMware Explorer with those, those type of Ted esque talks where you're telling a story about striving, about challenge

and about eventual success. Those would work. Right. And I think that if it's a real person that's, that's used your platform, I think that's really important. Um, and then you get your second customer and you do the same thing. You build this up over layers. Um, branding, I think isn't, I think it branding's good. Um, I, I think it's difficult naming things. I think we could all agree is, is always the hard part, but I think there's a lot of value in giving your product a name and giving your product a logo and making it identifiable. And especially where there's a lot of technologies and a lot of teams and a lot of acronyms, having something that people can talk about. So it's not the, it's not the, the, um, the, the, the BFG team. It's something else, right? You've got a product that, that you're, that you're trying to launch naming that product. But that's, that's the tricky bit. I can't help you there. I've made some terrible, terrible things on that, on that campaign. Yeah. I would say, stay away from, from clever. What you think is clever acronyms. Don't do, don't do that. Um, once you have a product, I think that you then have a brand. That means you can then build a website. You can then, um, you can work on how you get that name out there. One of the most successful things that, that, that I did was, um, and I don't think it was my idea. I think it was someone else, the team. So let's just be honest, but I can't remember who it was. And it was laptop stickers. And they were joking, I think at the time, because we're talking about brand and building this and, uh, no laptop stickers. We're like, well, we can, we can get those printed. So we got our logo, which was effectively a little, little cloud shape as you'd expect. And we got a bunch of these laptop stickers printed and we gave them out at the meetings that we did. And then slowly but surely these stickers started appearing on people's laptops. And it's, it was nice. I think there's two parts. I think one is as a group identity, almost there's free advertising.

What's that? Well, that's interesting. But the other part is that when you have a brand, especially for a small team, that's maybe starting a brand helps you initially pull your engineers together. So you're building something, you can name the thing that you're building and you can take pride in that because a brand and a product can be perhaps different from the norm. Um, so, you know, you're at all young startups, you know, like, as you said, we are, we're not a delivery company. We're a lifestyle company. You can, you can do that in the initial to, to give people the dream. You know, we're not an IT department. We are in a cloud team that seems to optimize all of the things. We're not going to be a ticket in space. We're not going to do things by hand. Anything that comes with a lot of things. Obviously you're not. You'll run out very quickly. But you can, you can build a brand for individuals from your team as well as people outside. Um, yeah, I think that branding and naming and marketing is important. Um, in terms of how you go about getting the name out, you know, you know, you know, you can build a brand. individuals in your team as well as people outside. I think that branding and naming and marketing is important. In terms of how you go about getting the name out there, you need to have people in your team that are able to sell. Many IT departments, but you need to go out and believe in what you're selling and believe in the value that what you're doing in the company that it brings. And have that conversation, be comfortable saying, well, you know, are we having a birthday party? Are we making a cake? Great. Have you tried this? There's a great recipe on our website. You know, having that enthusiasm to find out where people's problems are and really dig in and then just take any opportunity you can. If someone, if a team's having a stand up, reach out, use your network. Can I come along for 10 minutes and introduce what my team's been doing, what we're working on? If your company has an internal website, contact them. Can I put a news article in to talk about this new thing we're trying to build? You know, I'd love to talk about what we're doing. Even better, why not try and do things in a new way? If your internal website's very text-oriented, start doing some videos. Do interviews with your engineers. You know, put something together that stands out.

But whatever you do, I think the important thing is to work at the open. Let people see what you're doing and try and get people excited about what this might mean and try not to get too stuck in the tech. Try and focus on people and business value. Yeah, no, that's great. And I think, you know, that's exactly what I've seen in other organizations over the years is, I mean, all of the seemingly trivial, tactical things you went over, like just all the way down to like, well, you're going to need a logo. Right? Like, and all of those things come from, it's been a long time since I've read, you know, I had my little phase of reading identity and brand management. But I think, and you pointed this out, right? Especially technical people, it's easy for them to be cynical about marketing and brand and stuff because there are many examples of how marketing is just used to like sell commodity things that like, you know, like this soap, this dish soap isn't actually going to change your life. Right? Like, it's just going to wash your dishes. Like, and so like, you kind of build up that cynical husk around things. However, you hit upon something that is important for brand, which is, I think, if you have a successful brand, it helps build a community of people who are more willing to like, go above and beyond to make the group successful. Right? Like they have an identity that's built into it and it becomes in not a conniving or a cynical way. It's, it starts to become part of who they are. And like, you know, if most people are in a halfway decent, healthy state, they want to improve their themselves. Improve is the wrong word, but they want things to go well. And so if they extend that to the group that they identify with, because there's a brand, that means going back to like your Slack thing, right? Like you'll have those people who aren't responsible for helping answer questions, just help out and answer questions. And so when they see people in the same way you see on the internet, there's people who are loyal to the brand of like Java or Go. And so when they see people in that community who have questions, they help out with it proactively, which I think that is a practical, powerful, effective brand in like the IT world.

And why it's worth like, I don't know, going to Fiverr and getting a logo or, or, or, or whatever. I think that's important as well. Although logos and name choices, I think are good and identity, by the way, I think that's the critical word. It's not really a brand. Exactly. You're trying to build an identity and a community, um, and which will then build an ecosystem. That's a whole different subject. When you start covering a portfolio of products, you have different problems, but we won't, we'll begin to that. Um, but yeah, don't let those things be barriers. I think that, um, as you say, if you need a logo, you don't need to, to go to extensive levels to, to get the best possible logo, Fiverr or some other website, build something yourself. There's a whole bunch of free things online available to make something and naming as well. Just, um, again, just, you just need to choose one at some stage. And if you choose a bad one, which you will, uh, just, you need to just double down on that. You, that's, that's your name now. And for better or for worse, that's what it's going to be called. Exactly. You can all have a laugh about it when you're, when you're, uh, when you're on stage talking about it at some, uh, global event. Well, that, well, that, that can be part of it. It's kind of charming to be a little like, uh, I re I realized that like, you know, glow global agile cloud is a little cheesy, but you know, it is right. Like that's part of the charm of it. Well, well, before, before we close out, um, I get, we won't really get to the tech part. Maybe one day we'll, we'll get to that. But I think, um, you know, you raised up something that is still always a mystery to me or not a mystery. I'm not satisfied with the answers I've gotten so far. So it's, it's always good to get more, um, proof that I should be satisfied, which is like, like, what's the deal with finance? Like why people always raise up that it's a problem. And I, uh, you, you, you highlighted what the problem is and what everyone always tells me. And it's one of those things where it seems like so obvious that it's a problem that I don't quite understood why I understand why it's not solved yet.

And, and what I hear and tell, tell me, tell me the details of this, but what I hear when I ask people this question is, well, the way the finance department works is there's two things that become a problem. One, the first one is that you make a promise that you're going to deliver on in 12 months and it becomes an issue if you don't deliver on that promise. And that doesn't, so that's your first primary problem in this kind of environment, because the trick is that you don't really know what the result is going to be in 12 months. If you're being honest with yourself, like, and, and I see this happen over and over again with platform things where like to put it in, in like a, a negative way, like you kind of only achieve 50% of what you thought you would. If you're lucky and so like, or even less. So that becomes your first problem is like, you are going to have a meeting with finance in 12 months where you say we delivered 50% of less of what we promised. So that's an issue. And then I think the other thing that people raise up is that because you're talking in a 12 month window, I mean, these are kind of spaces of the same thing is you kind of have to over promise to get a big pool of money. And when you end up over promising, I'm sure this never happened in places you work, but I hear this has happened in other places is you just kind of sort of make stuff up in order to, in order to achieve a business case. You're like, well, what if we ended up modernizing these five critical applications and therefore we drive efficiency and we get $2 million more like pounds. And so therefore we can make the business case, right? And, and then, and then once finance approves it, you're kind of in a situation of like, oh boy, how are we going to do that? So I, I don't know. That's, that's kind of like the dump of the answers that I've gotten, but like, what, like, what are the things that, that you encounter when like finance is a problem for this? So I think you've described how probably 99% of enterprises run.

You have an annual financing, um, system, you, you have to get big money promised to you at the beginning of the year, and then you have to deliver big at the end of the year. And in the middle, it's probably the finance that's catching up with you. It's probably just a project manager or program manager making sure that you are on track. Um, and of course, that's where I think, uh, where the lies come in, which is, well, what are we on track for exactly? Because you're not really tracking your, your goals that you're planning on meeting. You're tracking your progress towards building the thing with the assumption, right? Once you build the thing that will deliver the big goals, right? Um, especially if you're building a product or you're building software or something like that, or if it's a migration, you might have a whole bunch of work to do up front. Um, finance without doubt is a, is an entire thing by itself. And I will not, uh, try to present myself as any form of expert. Um, but I think the best thing you can ever do is to phone up someone in your finance team and ask for a chat about how does finance work here? What are the problems that you have finance? What are the, what, what are the, the things that go wrong for you? What, what do projects do that make your life difficult in finance? You know, you're not asking for money. You're just asking for knowledge. Um, the other great thing that you can do as well is that a lot of people in finance who are working as part of an IT company don't really understand a lot about IT. Much like a lot of people work in IT don't understand a lot about CapEx, OPEX and, and all this kind of stuff. So have a knowledge share session. Say, look, would, would you be interested in us catching up on a regular basis? I'll, I'll try and answer some of your cloudy questions and maybe you can answer some of my financing questions. Um, so understanding how finance structured in your business, I think is the first step. Understanding where others cause people pain. And again, there's a common theme here, right? It's not really about technology or the finance.

It's about the people behind it. Because if you can make friends with a finance person and you are seen to be a project or program that is, um, low hassle, you know, you've not caused any problems. There's no big red flags on you. Then that's a really good sign. And understanding what good looks like from a finance perspective, because really what you want to do is you definitely want to achieve your project outcomes, whatever they may be. But more importantly, you want to achieve the financial outcomes. There has to be, as you said, that balance. We're making the assumption that we have to make big promises to get big money. So they all cancel out, right? Well, maybe we have to do that. Maybe there's another way. Um, so for example, maybe you have a chat with finance about your, your business case. You structure it differently. You say, well, actually, I'm not going to ask you for 5 million. I'm going to ask you for 500K this quarter. And then I think next quarter, we'll probably look like this. And then this will be this. And then we'll add these numbers up. Um, but my plan is to deliver this value in the first quarter, this value in the second. Bear in mind, we, this will probably change as we go. We'll have a replanning at the end of each. And we want you, by the way, involved in that process alongside our customers, et cetera. And you give them the option of saying, well, look, we're going to spend this money. But if you, for whatever reason, need to hold back money, or you need to stop the money entirely, we've still delivered some value. Because finance is mostly about managing risk. We are putting money into the project in the hope that you'll deliver value. But finance has a whole bunch of problems on their side about how they go up managing the finance, the company. Like the worst thing in my, that I've learned from, from my time with finance people is that running over budget is actually more manageable than running under budget. Right, right, right. Yeah. You see, right? But if you're over budget, there's things that you can do to try and control that going forwards. And it might be that you've gone over budget for understandable things. And now we need to find more money.

Well, that's problematic, but we might maybe need to cut the scope back. But if you get to October, and you know, you're, you're pushing into Q4. And at that point, you haven't spent enough of your money. Well, all of a sudden, what you've done is two things. One is obviously you've under delivered on what you're planning on doing. But the other thing is that is money that could have been used by someone else to deliver more value. But you held on to it. And you didn't, you didn't talk about it early enough. So finance now have two problems. They've got a pot of money, which means their graph at the end of the year is going the wrong direction for better or for worse. Bear in mind that stock shareholders want repeatability, not necessarily just big numbers. If you forecast a number, you kind of need to hit the forecast. If you go way over the forecast, you're in trouble as well. Because if I was a shareholder, I would have got more shares if I knew the number was going to do that, right? So I think from a finance perspective, you need just to understand what the challenges are for them and try and meet those. And I think as well, managing your risk along the way. And I think this is where agile and app modernization can really help because we're not talking about waterfall. We don't need to wait all the way to the end of the project to get value. Why don't we do a minimum viable product to begin with, get that out, prove the case, go back to finance and say, we built a basic version of it. We've got 10 users already. We're delivering this business value to the company. And so we now want the next tranche of money to expand the site. We're going to do X, Y, and Z. So I think just having a conversation and understanding that like IT people hidden in the basement, finance are real human beings too. And it's taking that same mentality that the operations people do with developers, which is make sure you understand what the needs of your customers, the finance people are, right? And how they think and, and like what their deal is. And then, and then once you do that, you also have to make sure it goes the other way. You've got your shifting left and right. You know, you lose, you're just shifting all over the place.

And, and, and that is, you know, like how, how can you help them achieve their goals better? And, and, you know, I think to use one word or one phrase to, to summarize everything we were saying about finance or most of it is like the job of finance is to make sure money is spent responsibly, which means it means at least two things. One, well, I mean, of course you want to prevent corruption and stuff like that. But like, but the, the two non-crime related things that means is, is like, and, and the second you, you, you highlighted, I think is, is often forgotten, but one that people are spending money, you know, in a good way, right? Like responsibly, there's a reason to spend the money and it results in an improvement. But, you know, I think, I think as an individual in, in individual, as they say, kitchen table finance, you don't think about this aspect, but it's that you're not missing out on an opportunity to make more money, which is your underspending part, right? Like to some, if, if you don't actually use all of your budget, what that means is that again, someone else didn't get that budget where you might've been able to make even more money. And that is a problem in itself because then, I mean, really for all the visions, vision statements and stuff, and, and, you know, giving back to the world and being a good person that most corporations have, their real goal is just to make more money constantly. Right. And, and so like, if you're, if you're failing at that number one goal or not failing, but if you are not meeting the potential of that number one goal, then that can be damaging, which is hard to like wrap your head around because it's like, you, you didn't do something and you saved money and that was bad. But anyhow, I think, I think that's a good overview of like starting to understand why finance is a problem for all sorts of like agile type of thinking IT. Cause it just like, there's not a good matching up of those interfaces there. Well, this has been great. I mean, I think, I think, uh, uh, we've covered many topics. I think that are, you know, I'm always interested in talking about these things when like intuitively a statement makes sense, like finance is a problem and it's always fun to kind of like dig down

and define why that is. And then what not only like tactically operationally, what needs to change to fix it, but how people should understand what's going on differently, the mindset in order to, uh, to make it better, which, which I, I think we accomplished here. Well, in a, in a, in a very non-creepy way, if people wanted to kind of like catch up with and like, see what, see what you're up to out in the world, would you have anything you would point them to? Um, so, uh, you'll, you'll find me on the, on the Twitters, et cetera. If you've got any questions, please do reach out. Um, I, you'll, I'm also planning on writing some blog articles on the Tanzu blog. Um, so, um, hopefully you'll see some content from you there. Um, but yeah, I would say that the, the big thing really is, is just look at your business and trying to be as helpful as possible and understand that everyone is just trying to do best they can, but they've got their own challenges. And the more you can understand those, that the better that you can, you can help, the more you help people, the more they'll trust you, the more they trust you, the more friends you'll have. And then all of a sudden all this becomes a lot, lot easier. Yeah. It's easier to be successful with a smile. It seems like, especially sustainably successful. Well, just as a reminder, if you've listened this far, you're probably highly interested in, uh, Brian mentioned earlier, we have, we have our conference VMware Explorer coming up in the U S it's going to be August 29th and 1st, pretty soon here. Uh, and I'll be there. Are you going to be there, Brian? I, I, I, I forget. I am hoping to come along to a VMware Explorer in Barcelona. Ah, yes. Well, that's the second one. That's the second one. So I've broken my track record for, for, for VM world, now VMware Explorer, um, uh, over, you know, due to COVID, et cetera. But yeah, I'm really looking forward to getting back and again, meeting people and, and, uh, again, the corridor chats and some of the, uh, the great presentations there. And, and so that's the other one is we also have, uh, the, the Europe one in Barcelona, which is November 7th to 10th. And, uh, I think we also have some Asia ones, which I am not apprised of. I should, I should get there, but, uh, now's a good chance to like, check out the catalog

and, and register for that one. I think the catalog for the Europe one hopefully will be up. I don't know, sometime soon. So you can start to decide about that. But if you go to cote.io slash explore, you can find, uh, links to that. And then I've got a little, uh, a little video where I'm like, this is great. You should come check it out. If you like, if you like videos and stuff like that. Uh, and as, as always, if you want to, uh, you know, get the show notes for this and check out other ones, you can go to tonsutalk.com. That's where we have all of this sort of stuff, little short videos, longer ones. You can figure out how to subscribe to the podcast. And I don't know, we got all sorts of links to free stuff and things like that. Well, thanks for being on. It was great. And, uh, with that, we'll see everyone next time. Bye-bye. Thanks so much. Bye.

Tanzu Talk · 🍕 Get more pizza.