You know, the one of the ideas that I think is nicely percolated in the I wonder if that's based on Latin. I should look up percolation. Doesn't that seem like I wonder where that comes from. But over in the past year, in the Latin America, percolate, I think it's from the coffee language, you know, that you want your drip percolation coffee. I was reading some, you know, the old Tinker, Taylor, Soldier, Constant Gardener, and someone wanted coffee from a percolator. And that was that was an odd sort of specification. I guess shaken, not stirred, but from a percolated. Yes. Anyhow, in the past year, related to percolation news, in so much as it shares the first letter, I think in the platform world, there's been a stronger idea, kind of a pulling forward of a notion that's existed for a while, you know, since back in the platform as a service, the cloud foundry days. And that is thinking about your platform as a product. Right. And I haven't watched them all. But in the most recent, like, you know, huge multiple bucket smorgasbord of platform con. I think there were a couple of talks on this and always, always, you know, you got the team topology people who show up with this. And you got you got Paula Kennedy, who we used to work with, bringing that in some other people, always good. But I think there's an aspect of like product. Like, it's fun to play around with, like, so what does that mean product? Right. And there's and this is especially great because I don't know about you, Ben, but I find the one, not the only, but one of the most enjoyable. If you were to draw a diagram and on, let's say, let's say the vertical axis, that would be the Y axis up and down. That was that was fun. And then the horizontal axis, the X axis, that was ease of executing as in doing, not the other executing. I think I think for you and I, having worked in software for so long at a vendor, perhaps talking about what a software product is, is way up in the in the upper right.
2:08Because we just talk about ourselves, like what what what we basically do. It's very easy. And I think I think that is that is other than the the diagram that I just went over, your two by two there. I think it's it's actually very beneficial to the platform world because it means that you don't have to, like, reinvent stuff. And also, as I'm fond of pointing out, it means that all of these vendors and by vendor, I mean, cloud providers, you know, people who want to sell you IT stuff. They're always looking for an excuse to talk with you. Right. As long as you're talking, you might be buying. And so like what you can do is you can ask them about that and get a whole bunch of like free advice. Right. And so it's great. There's this it's not like, you know, it's not like, oh, like not ALM. That's an older thing. The LLMs, the AI stuff is like this brand new thing. We've got to spend a lot of time to understand how to apply. It's like, nope, if you want to figure out what as a product means, we've known about that forever. You can just do it now. I think I think the first thing that I one of the things I like to talk about a lot is the idea of marketing your platform. Right. Again, and this is why I went to that whole spiel of vendor stuff is like any vendor knows that if you have a product or a platform, it's very important. Number number one task is to tell people that exists. That's always good. And then and then the after that, if you want to achieve momentum and get usage, you basically just apply basic marketing knowledge. Right. And that is, you know, talking about I mean, I mean, tell you I'm going to go over, but you tell me what you think basic marketing things are. Right. For for people who aren't practiced in marketing. But, you know, the basics are basically like the basics are basically the the the rudimentary things are you have to tell people what what your product does. Explain to explain to them how it helps them solve problems and do things better. The value props. Right. And then the third major category is essentially like telling them why you're the best choice amongst all the competition.
4:16Right. Doing some some competitive marketing. And I think that all of these apply if you're running an internal developer platform and you're trying to promote it. What what what's what's your take on that, Ben? I mean, you you've worked with people who are. Using platforms going from zero to to a lot. And, you know, now now you work on this side of doing it, like when you think about like marketing a platform for internal use, we don't want to give up the secrets of how we're so successful marketing our platforms. But for internal use as an organization, like what's the marketing thing that you you've seen people do well and poorly? Well, and I know I know where it always starts. I think the point where, you know, you've got a product is when you start thinking about giving it a name. The naming part is the fun part. Right. It's like at that point, you know, you've got a product because you've got to think of a name and you want your name to be excellent. In every way, you know, has to be cool and serious at the same time. Yes, yes. And, you know, meaningful and vague so that you can copyright it. And, you know, all these things all have to apply at the same time. You know, Tanzu is a great brand, you know, the kind of the kind of word didn't really exist, you know, before we sort of cooked it up to describe describe our, you know, our brand and how it and then it's been, you know, used across a whole bunch of different products. So I think I think, you know, you've got a product when you start talking about names for it. And the naming part is very exciting because, you know, you can have little competitions and try and figure out what you want to what you want to put on your T-shirts. You know, what should your T-shirts say? Right. Yeah, you bring up a good point that I skipped over, and that is brand, right? And having the brand part of it, which is like, and, well, first of all, first of all, they introduce another, you know, to underline what you're doing, what you're saying there.
6:16Like my teammate, Deshaun, he has this funny way of doing it is whenever he's talking with people or introducing platforms, I mean, you know, Deshaun's demeanor, so you can almost envision him saying this as he'll say, like, well, do you have a T-shirt yet? Right. And, you know, what he's the, I guess, pun intended, the thread that he's pulling out there is that a manifestation of the brand, meaning that you have done a brand is often a T-shirt, right? And what do we know about developers that love T-shirts? It's just like, that's, it's, and here's a little insider marketing thing. People at vendors hate T-shirts, and they hate T-shirts, not you and me, because we benefit from them. They hate T-shirts because, one, they're expensive, and two, they're complicated because you're always like, all right, if we get the T-shirts, how many XS, how many S, how many medium, how many large, how many X, you know, you got to do the size division. Then you're also like, is this conference in America or is it in the rest of the world? Because that determines your shirt size. Like, do we, how many, do we get unisex shirts or do we get like, you know, like, like women shirts? Like, and what's the split that we have? So first you've got that, and then they're also expensive per unit, and then you have to ship them. And if you're shipping them across borders, oh my God, all sorts of problems, right? Over the years, I've been in numerous situations, not that many, but enough where like someone was like, I don't know, there's somewhere in UK customs, maybe we'll never see them again. And they'll just be like boxes of T-shirts. And then, you know, it's great if it's within the same borders. But, and then once you're done with the conference, you often have a lot of leftover T-shirts that are all like, you know, excess or triple X large. And then you've got to ship those back. And so this is why, however, you know, the point being that it's, you know, marketing has a lot of effort that goes into it. And if you, you know, of more magnitude than the T-shirts there. But you're right, brand, very important to have a name. And I think one of the other little overly clever, but I think practical things that I've been told multiple times over the years by people who do platforms is one of the most important things about a brand, as you're getting to, is not only that you're coming up with your own name, as you were saying, but it's important to also have your own name for what this platform effort is, what this digital transformation effort is.
8:41To distinguish it from having to be orthodoxed, whatever methodology you're using, right? So the example of that is, I remember I was in, I guess, during a SpringOne at some point when we had, I forget his name, but there was a colonel from the Air Force who came to talk about the work that they were doing. And he had talked about this actually on the keynote and in the session as well, I think. But he was saying, like, you got to be really careful. You don't ever want to call something you're doing agile. Because the moment you call it agile, what's going to happen is everyone's going to pick their favorite agile book, and then they're going to tell you why you're doing it wrong. And you're going to spend way too much time talking about, like, yes, we're not following the crystal method, like, or no, we're not following the 1989 edition of Extreme Programming. Or, yes, I didn't realize about release trains and safe, and on and on and on, right? And instead, his point, which I've heard over and over again, was that, and I believe this, which is like, yeah, those books are supersets of, he wasn't saying this explicitly, but those guidelines, those practices are supersets of what you're going to end up doing. And the reason they're supersets is because how you apply it is going to be unique to the constraints and the opportunities of your organization, right? Like, there's just going to be things. Like, maybe you can adopt all of the practices, and maybe you can't, right? And I think we've seen that over the years, where, like, you know, whenever there's, like, a DevOps engineering group, or probably also, like, a site reliability engineer, an SRE group, I'm sure there's numerous people who are like, well, according to Chapter 7 of the Google SRE book, we are not following those practices, so therefore, your entire existence is invalidated, right? It's the old, my hair is a bird situation. So I think a brand, it's good to detract it. Is that the right word? It's good to disassociate it from, like, the Bible of the methodology you're trying to follow.
10:45Yeah, and also, you know, your platform is custom to you, right? Exactly. That's what you're saying, isn't it? It's your choices of what are important based on your context, which is different for every organization out there, you know? Yeah. So, yeah, it's your brand and your actual platform, your actual product. They are kind of unique to you, and you need to own them, right? In terms of not just, you know, provide them, but also like them and want folks to use them and want to sort of promote that. And so further into the whatever, the guidebook for platform marketing, like another thing that I've learned from talking with people over the years is, so what does that look like to market? So we've gone over, like, you know, you've got to have the brand, the name, and part of that is, and this is something that I picked up from, like, you know, UK GDS people talking about stuff is it's important to think about a set of principles that you have. And the principles, like, you know, it's fine to have principles, and I don't mean my tone to be dismissive, but I'm just saying that's not the area I'm talking about. It's great and fine to have principles like, you know, we should be good to each other, right? Like, the kind of, like, basic human things, or as I often think about it, like, well, I mean, if you're not doing that, that's unfortunate, right? Like, you know, every time we have to take our annual training about, you know, don't do embezzlement, I think, like, hmm, I like how positively you think about me. But anyways, like, you want to have that, but these principles, and I forget the name of the book, but there's a great book written by some people who had done a lot of the UK GDS work, and if you look at the list of principles that they have, they are, like, actionable principles. They're not just, like, I mean, you know, Pivotal had some great principles, like, do kind, keep it simple, be kind, keep it simple, like, I embarrassingly forget what they are, but those were high-level principles.
12:49But these principles are more things like, you know, this wasn't one of them, but it would be, like, minimize the time it takes a customer to finish a task, right? Like, it's a guiding principle of, like, focus on this kind of thing. Or, I mean, it could be all the way down to something like, allow a developer to get their own database or their own middleware completely on their own, right? Yeah, like the principle of self-service, you know, that sort of thing. Yeah, absolutely. Right, and that may seem kind of obvious, but as I was going through that, I was thinking, like, you know, back in the 2000s when I worked in the systems management, as we called it, space, and there was business service management, you know, and BSM, and also, like, ITIL stuff, like, more of a principle there. And I don't know if the sages of ITIL and ITSM, IT service management, would, like, like this, but there is an implicit principle of have a request system. I mean, they probably would, because there was a whole book in the 10, 12-volume set of ITIL v2 that was, like, service requests. And it was, like, we have a principle that the way that IT works is people request things, right? Which is the, not the opposite, but it's much different than people self-service get things, right? So, and that's where the rise of the ticket desk and the workflow to do that. And a lot of things come through is you have this principle of the way that people get stuff is they request it. I guess you could make a, I don't know if it's silly, but a silly analogy of, like, you know, it used to be you'd go to the grocery store in, like, 1892, and everything was behind the counter, and you would have to request your little bag of coffee or your beans.
14:50And so that's a request mentality for a platform, whereas nowadays you just go get what you want and you check out, right? And so, like, figuring out in your platform, like, what those principles are. And they can be operational principles, but, like, they're kind of like the goals or the principle behavior that you have. Like, that's also very much so not only to guide the way that you're doing things, but it's also part of the marketing, right? Because it's something that you use to kind of talk about with your community, with your customers, developers, and other people to kind of explain, back to marketing, like, what the deal is, what the value props are, the positioning of your platform is, how it thinks and how it can help people out, which I think is a valuable thing to, I think, I usually have the little book over there. But Duke Energy, who we worked with, and I think we still do, they had, like, this little book they would give people, like, once they got into the, not only the platform world, but, like, the new way of doing things, which was nice. Yeah, and together they form a sort of a charter, don't they, in a way, they sort of form a contract, as such, in that, you know, you use our platform, you can expect these things, and also expect that we'll continue to work on these things, so that it follows these guiding principles and delivers on the promises being made by them, right? Yeah, absolutely. And, you know, this principles thing, as you were kind of getting to this sort of, like, I guess to use, like, fancy pants operations term, these promises being made, right? Like, like, it falls into the line of, like, community management, and, like, your platform team's own internal operations, and I think it's also, like, a large part of the marketing that exists, right? It helps form, and this gets into the territory of marketing, where if you're, like, kind of cynical, then you do identify, like, the, whatever, the manipulative stuff of some marketing, right?
16:56But, like, of course, you don't want to be manipulative, but, like, there is a value in marketing of creating an identity that people identify with, right? And especially in technology, if you're not overly cynical about it, and you know how to do it, you can realize that, like, developers and operations people, like, identifying with the technology in that marketing sense happens all the time and is super valuable for everyone, right? So, for example, you know, if someone's a developer, you immediately ask, oh, what do you develop in, right? Because what you're asking is what their developer identity is, and usually they'll say, like, oh, I'm a Java developer, or I'm a, you know, Rails developer, or, you know, whatever, right? Like, some people, like, will be, like, oh, but you can eventually pin them down and be, like, what do you spend most of your time developing in and know the most about, and what do you get paid to develop in? It's just, like, that's what you are, right? Like, and, you know, also, you know, people will say they're, like, a VMware person, or they're a Linux administrator, or whatever, all these various things, and you get certified in Red Hat or certified from the CNCF. So, that's another thing that when it comes to the platform that you want to do is you think about how can we start building up that identity that people have around it, right? Like, I use, like, in JPMorgan Chase, they have, like, the Gaia platforms, right? And, you know, you want people to start thinking, like, I use the Gaia platform, right? Or in Mercedes-Benz, they have a Cloud Foundry platform and a Kubernetes platform. They have multiple platforms. But they have a Cloud Foundry platform, you know, the Tanzu Application Service. And so, those developers, you know, they can identify a little bit with, like, oh, I use the Cloud Foundry platform, right? Like, that's the kind of platform that I use. And having, as you were saying, the brand name, the principles, but then actively, like, and this gets into the area that my team works in and that you work in a bit, right? But having, like, you know, you need to, like, have that thought leadership, right?
19:01Which I think often leads to another thing that I see in most all, let's just be super hyperbolic and say all, you know, 90, you know, an SLA is worth 99.9999% of organizations is they have at least one, if not multiple, let's call them platform advocates. And this is, like, a full-time person whose job is to not only do, like, training and workshops, but they are supposed to, like, be enthusiastic about the platform, right? Like, like, all these, like, thought leaders and people out there that you see talking about various technologies and things like that, right? Like, their job is to, like, with enthusiasm, show people why the platform is good and how it can help them out. And, you know, oftentimes, like, I remember talking with people at BT or, you know, formerly British Telco or Telcom, like, there was a person who full-time did this. And they would travel around to the various offices and, you know, you would have, like, a meeting with, like, you know, it could be anywhere from, like, six to 20 people, if not more, right? And you're just kind of doing a road show and presenting things. And, you know, they do a similar thing where they're always thinking about how can we be an advocate for this and explain it to people. And then it gets to another aspect of the as a product, which is, and this is where it's fun to be a vendor and talk about things, is, like, when you're developing a product, a software, an IT product, you have this role called a product manager. And part of what a product manager, a product manager's job, there's lots of things, but the most important job for a product manager is to figure out for this release, what features are we going to work on and release?
21:01And there's all sorts of criteria and inputs that go into that, like, one of the inputs, as a business, one of the most important inputs is talking to your salespeople to see what people want to buy. But, you know, another very important input is actually talking to your customers and getting feedback about what works and doesn't work. And that's where a role of an advocate also is valuable, because the reason they're called an advocate is, and they're often called a developer advocate, is because they're supposed to be advocating for developers and to them, I guess. But, you know, so as these advocates go around and they work closely with the customers of the platform, the developers, hopefully what they're gathering up is like, oh, I talked to this person and they said that and this person said that. And you bring that back to the product manager of the platform, and it's another type of input that allows them to basically prioritize the backlog to figure out what they're working on. But, you know, I mean, I think all of those things are a large part of, like, what it means to do marketing for a platform, right? And I think it's worth going over those things, because again, when I was part of the traditional IT management world, which I think still largely exists in this way, like, people wouldn't say you didn't have those goals, but the way you would achieve them would be more with, like, a knowledge base, or like a center of excellence, right? It would be more of a, more of like a lecture, here's the way that you do it, kind of academic way of doing stuff, rather than, like, going out into the field and thinking about how you apply marketing to things, right? It's a lot, it's a lot more engineering, and I don't know, I have a lack of words for it, but it's a different way of thinking about how you're marketing than in the traditional way of doing things. Yeah, and it could be quite, like you said, quite dry and quite kind of academic when you do it that way.
23:03I do remember being part of organizations that had centers of excellence, for example, in service orientation or, you know, things of that nature. And, yeah, it's a very different way of thinking from the more proactive advocacy route, where, you know, you can't just publish a paper on a topic, like, I don't know, XML parsing, using XSLT. You actually have to have, you know, the ability to talk about that in coding terms, in terms of what it actually means to apply that idea or to, you know, use that idea in a practical way with practical examples, but also gathering information about where that breaks down, you know, which parts of it don't work as well as they should, and how could it work better and all that sort of stuff. So, yeah, it's definitely, I've seen plenty of that, yeah. And then there's two other things in my, that I wanted to go over. And one of them is, well, one of them is another aspect of marketing that I think is important, that I like to emphasize, because I think people would assume they're doing it, but not to the degree that I think is required to do to be successful. And that is thinking about conferences that you have. And what I mean by that, and this is one of those instances where I think it's very literal, like people should do literally the following until they are adept at it enough to figure out to do otherwise. It's the old, you know, you got to know the rules in order to break the rules situation. And that is, like every quarter, your platform group, and hopefully more than just your platform group, but it also should be inclusive of the group who is like working on applications and wants to do your software better. Who wants to actually like have your software be strategically part of the business and not just like some projects that they're, they're delivering.
25:06But anyways, like you want to have a conference every quarter and like, it's great if you have the will and the budget for it to actually be in person. Right. So in large organizations, there's always multiple sites. Right. And a very good thing to do if you can is to have this conference rotate at all of your major big sites globally and then broadcast it online. Right. But what you do at this conference, and again, this is, this is where it's this, this type of marketing that you learn at a tech company is you do a couple of things. Uh, one, the first thing that you want to do is you're just raising awareness that the thing exists, right? That, that it is there, which is easy to be dismissive about, but in a large organization, there's a lot of things and you have to really, uh, spend a lot of time telling people it exists. And then the, the, the next thing that you want to do is you want to build up trust that the platform is good and that people will benefit from it. And the way that you do that, uh, and this is what us tech vendors know is it's great to, to have people like Coté and Ben make claims and tell you why something is awesome, but it's even better if you have actual customers going over how it worked. And so in this instance, that means finding developers who have used the platform and just having them present everything, not everything, but you know, not only the good, but, but also the bad, just go over the story of how they use the platform, what they learned from it and what worked and didn't work and what their recommendation was. Because what you're doing here is you're building up, uh, the best type of marketing, at least according to the Seth Godin's and the clue train people of the world is, uh, your, your word of mouth marketing. Right. And that's the best type of marketing because one, uh, well, there's all sorts of reasons, but it's just, if you think about the dynamics of it, right, what you're trying to do is win over developers to use your technology. And I'll, and I'll get to why that even exists in the second, the second, the second last thing I wanted to go over.
27:07Uh, and really they're going to trust other developers, their peers the most about what works because hopefully because they trust and respect them, or at least don't think they're bozos. Um, and then two, because they have a similar, they have the same job as them. And so they can start to ask them very insider expert questions like, well, what about this thing? And what do you do when this happens? And did you think about that? And so like, you know, those are the people you want experts selling to other experts. So you do that. Yeah. Sorry. Well, they have like a shared domain, don't they? And I think, uh, I've, I've heard it, uh, termed social proof. You know, they're looking for social proof. Others in the same peer group that are doing the same things with the same technology. It all helps to reinforce the idea that it's a golden path and that it's good. Right. Absolutely. And, and, you know, to, to, to reinforce, and then, so the third thing you have at the conference is just educational content, right? Like just sort of, uh, training content. Like you're, you know, obviously your advocate people would be there and they would go over like, you know, now let's go over how to deploy to the platform. Right. Like, so now you have an application running on the platform. How do you gather the, what, to whatever degree we want of the, you build it, we run it. Like, uh, what's the word for it? Uh, riddle of, of, of, uh, cloud philosophy. Like how, what does it mean to like, look at your application and production? How do you manage like API gateways? How do you integrate with our weird certificate system? Just straight up training stuff, uh, that people will be interested in. And then of course, you know, the benefit of an in-person conference and actually making the time for it is then you have a lot of conversation afterwards. Right. And what I've observed firsthand in a lot of these, um, events is that it's that unscheduled
29:07time that is most valuable for like the team leads and the architect types, right? Because the team leads and the architect types, the ones who are like, um, who are not individual developers, but worrying about how a team of developers or how several teams of developers will be operating. I mean, they're, they're programmers of the system of people of the meatware stack. And they often have a lot of questions, right? And their questions are not really things that you can gather in a presentation. They need to be more of a discussion about that are very particular, how they're doing things. So again, like having those quarterly conferences, hopefully in person where you kind of go, you go over those four things, I think is a very valuable. And then the fourth thing to consider from a marketing standpoint is the reason all of this is important is because whether you accept it or not, especially in size, large organizations, you have a lot of competition for a platform, right? So the first type of competition you have is doing nothing, right? Like not changing to a new platform, just keeping doing what you're doing. Um, and it could be as, as I think is the case very frequently nowadays, it could be because that platform works. And it's very frequently the case when you're talking about mainframe stuff that like over the decades, we've already modernized and moved a lot of stuff off of mainframes, right? So as you, as you start to chip away and try to modernize more and more stuff on a mainframe, like it has a Darwinian nature of usefulness to it, right? That if, if an application, this is not universally true. There are still many applications, many, there's still a significant amount of services and applications that exist on a mainframe that should be modernized and have good reasons for it, especially in large government, uh, agencies and some financial organizations that haven't really like been keeping up with things. However, like a lot of those things that exist on mainframes now, like it, they've survived
31:10and it's because they work well. But so you have that kind of like mentality of just doing what you're currently doing. But the, and then there's also, as I was kind of mentioning with JP Morgan Chase and Mercedes Benz, they have multiple platforms, right? For various reasons. And so you're competing against other platforms, but the biggest competition that you're probably having is competing with the developers themselves. And you compete with them in two areas, one, and I, I've joked about this kind of throughout you're competing with developers who are like, Hmm, don't think you're smart enough to listen to, right. And, and, or, you know, they might've been like burned in the past. They might be annoyed about things, but they're sort of like, you know, they don't, they're not really interested in using your platform because they don't, they just assume it's going to be bad. And platform skeptics. Yeah, there you go. And, and then the, what's, what's, what usually is holding hands with that is that these developers will be building their own platforms or aligned with other people that are building things, or at the very least, they won't see the value in a standardized centralized platform as, or as we used to call it an opinionated platform, or as we used to even call it longer ago, a platform as a service. Right. And so, you know, that's the kind of competition that, that, that you're dealing with. And why, for all the benefits you're going to have with the platform, I think it's important to think about how do we deal with that competition. Right. And especially the last type, because the last type is this competition of not believing in the idea of a platform. And then, like, you're going to have to go in there and, like, do, and do the right thing with it, essentially. Yeah. Again, it's a super expensive choice, that last one, isn't it, as well. Yeah. There's other, there's other drawbacks with that.
33:11And, and you end up, you know, arguing on the head of a pin about very specific technologies, you know, oh, I prefer this one. Oh, the platform's got that one. It's, therefore, I'll just build my own, you know. But people often underestimate just how expensive that is, I think. So, yeah. That sort of alignment is helpful if you can, if you, if you can reduce the skepticism and, and show the value and bring folks along on that journey. It's very, it's very cost effective as well, right? There's a, there's a, there's a bottom line, uh, quotient to this. Exactly. Exactly. And so, so, you know, the reason we're talking about all this is, is you and I were, we're, we're catching up a little bit and we realized that, like, you know, I've, I've spent a lot of time, obviously, uh, either that I'm really good at just making stuff up as I talk, which maybe is about 15% of my abilities and pre-trained. Exactly. But, you know, I spend a lot of time thinking about that marketing thing. And I, and I think, I think recently you've been spending a lot of time thinking about, okay, so let's say we get the chance to like get in front of the developers every day and they actually want to use it. Like, what is the, I hesitate to say the word marketing, but what is the usability of the platform, the UX, the design of the platform? Uh, like what are the components of that so that we make it, uh, easier for them to use and to make it more successful at them? So what, what, what have you been thinking about in that area? Yeah, I've been working on a, on a few bits and pieces, but I liked what you said earlier about, you know, the, the thing that the, your, your opinion is that folks perhaps under cook the whole, the whole, um, conference idea, you know, actually getting people to confer about what, what it is that you're building and get that shared. The thing that, uh, that I have a bit of a bugbear about is, um, actually documenting what
35:15you have. Right, right, right. So the folks, because documentation is 24, seven, three, six, five self-service, right? So, so if your principle is run around sort of self-service, then having good documentation about it all is really important because you don't need the advocate to be there 24, seven. You can't have an advocate there 24, seven. You know, you can't have that sort of that care and assistance all the time. So you need a fallback plan and the fallback plan is, okay, how do you, you know, you actually have to create content around what this thing actually, you know, does. And it's, it's not the same as technical documentation, you know, press button X and then do button Y and then Bob's your uncle, here's your thing. It's not just the sort of technical documentation, which of course you sort of need, but it's also the, the sort of questions around the platform, you know, like why, why would I use this exactly? And what benefit is there in it for me? And how should I think about this particular problem in a, in a, in a platform, uh, manner? So, so I've been sort of working on, I do a lot of work with, uh, backstage cause we have backstage, um, GUI as part of some of our products, uh, uh, terms of application platform, uh, terms of application service. Uh, so we, we, you know, that's a, for folks who haven't seen it before, go check it out. Um, backstage.io is the website. Um, but basically that gives you, uh, uh, uh, a place, you know, a website where all the developers can come together and share information about their context. You know, we were talking about context earlier is things like, okay, how is our organization structured and how do they, what applications do we have and how do they relate to each other and which ones are integrated with which other ones and how are they integrated and where do
37:15they run? Do they run on Cates? Do they run on cloud foundry? Where do they run on, you know, bare metal? Where are they exactly? So it's starting to bring together lots of information about the context of developing so that you can discover more quickly. You know, you can discover what's going on in other teams more quickly. You can discover the parts that are relevant to you more quickly. It lets you sort of create stuff as well. You know, you can create, for example, nice documentation spaces where you can talk about your application and have folks be able to self-serve information about what it is that's on offer. There are APIs in there. So you've got API listings and things. So it's really useful and it does bring developers together into a place where, um, they can, uh, you know, do their work more productively, but also understand, you know, what's around them. So, so I've been working a lot on that recently. Um, we, we have, uh, like I said, we have a couple of products, uh, that, that use, um, the backstage portal. So I've been working on things like, um, service catalogs, uh, um, which basically tell, sorry, software catalogs, which basically tell you about, um, what is all the software that we have? Like what, what are the software applications that we're working on? And how do they relate to each other? So it handles things like relationships between individual pieces and components of that software relationships to APIs that are offered relationships to the people that actually code this stuff and look after it on a day-to-day basis, either operationally or from a, from a sort of a code perspective, which is really handy. If at three in the morning, you need to find out who looks after this thing and can they help us with this vulnerability that we're seeing, you know, so lots of interesting stuff in software catalogs, I think can be done. And it's, like I said, it's 24 seven. So folks can just go and self-serve and then related to that also is, um, another feature, um, called
39:22tech docs, which allows you to sort of document in a rich sort of websitey format information about your, um, about your software applications or about your platform. And this is where I think it perhaps is underutilized, you know, I think a lot of teams articulate very well, the software that they're working on, but for platform teams, platform engineering teams, that's a good place where you could actually document the platform itself, say what the platform is and why you put it together and how it was put together and what pieces are in there and, um, how they, uh, relate to each other. And also getting started information, stuff that's not necessarily in regular technical documentation, but is more about, you know, why should you be interested in this? It'd be a really good question to answer for someone visiting for the first time. Like if you're a platform advocate and you go out there and you say, Oh, you should check out our platform. Here's a URL. Like it'd be really nice if the landing page for that URL is like, Hey, this is our platform. And this is why we think you should like it, you know, and this is the sort of stuff that it can deliver for you rather than sort of, you know, some, some cold login screen or, or some, you know, baffling information. Uh, that that's, that's, that's too, uh, low level. So, so I think some of these features are underutilized, you know, having a good landing page, it's marketing and it, it really helps to, uh, help people get comfortable more quickly with your platform. And therefore actually consume it because that's what you want at the end of the day. You mentioned at the start of this, uh, the recent platform con, you're absolutely right. Presentation after presentation was all about, okay, I've built this platform, but how the hell do I get people to consume it?
41:25And because I, because I'm, I'm great at building it. I've answered all the technical questions. It's an awesome platform. You know, it's got all the bells and whistles and everything that everyone wanted is in there. And still I've got 5% usage. So why, you know, how do I make them go through the process of getting interested in a platform and actually, you know, first of all, kind of trying it, but hopefully ultimately respecting it. And then participating in improving it. Yeah. You know, that, that, that, that, well, first of all, that's, that's a great list of everything there that there was, uh, I'm going to have to go back and, uh, uh, list those out at some point. But I, I think on this last point, this is another one of those, like, you know, life hacks. I wouldn't, let's call it enterprise life hacks. Not, not like your everyday life, which is, uh, you know, the, the, the word, whenever someone who's, uh, nowadays at a vendor and again, public cloud or, or software vendor, when they hear the word consumption, that means a very precise thing. Not the sickness, of course, that was a problem back in the 1800s and whatnot, but what, what, what they know that means is the future success of my business. Right. Uh, because what, what you want to do in, in larger enterprise sales nowadays, uh, you know, you want to sell on a subscription versus a perpetual license. And so what you're very concerned with is you want to sell as big a deal as possible for as many years right away. There's good and bads about why you do this. We'll, we'll traipse over all of that. It's another thing. If you really want to get your software, your vendor, people thinking, ask them about this and they'll be up all night explaining both sides of it, but you sell a big thing. And what you want is at the end of that two or three year term, you want the person you sold it to, to not only renew it, but to buy more of it. And so what that means is that you need them to consume that product and not have it be as we used to call it shelfware. Right. So this has sprung up a whole realm of, uh, a whole new, like, um, what do you call it?
43:31Function in vendors called customer success. And what customer success does, they're not like professional services, people who help you set up and run something, but there's someone who works with the big customers to make sure they're actually using the product. Right. And, and that they're using an increasing amount more of it so that when the contract ends again, the customer renews it and they buy a little bit more. Right. And some of the best, uh, vendors out there in the world are masters at this whole thing, right? They not only have technology that's good, but they make sure to manage that complete life cycle, uh, of, of what's going on there. So we in the vendor space know all about that. So this is another area where, uh, you know, you could call up your vendor friends, have them buy you a free steak dinner or lunch and teach you all about this kind of stuff. And I think, you know, putting, putting, putting a lot of what I was saying, like, you know, uh, in, in, in, in the bowls that you are, uh, spinning up there. Like what that means has been was saying is you do think a lot on this platform team about how do I get people developers to start using the platform to use more and more of it. Now you've got to temper that a little bit, if you're not a vendor, because your goal isn't to maximize the expense, right? Like, so at some point you don't actually need to have them use more and more, but you want them using it and you want to focus on consumption. Right. To some extent, not to some extent, like that I've noticed over the years that that becomes a metric that people track on the platform team is how much usage do we have of it. Right. Not just to, to a point you were kind of making, uh, Ben, you don't just track the metric of, we delivered the service and the service has uptime and the service is meeting the budgetary goals that we have. You also want to track the metric of our people using it, right? Like is, and are they using it more and more each time? Um, and, and, and once you do start tracking that metric that has some interesting, uh, effects, like, like a while ago, uh, uh, uh,
45:39there was a presentation that, um, uh, Tony, uh, at the Home Depot at the time, now he, he works with us, but he was saying when they were introducing, uh, uh, a platform, their cloud foundry based platform back then, the pivotal cloud foundry. Now the Tonsu application service, uh, that they were tracking consumption and they had noticed that like developers weren't using very much of it. So again, from this very product mentality thing, uh, they, they, you know, they went and talked to them, you know, big mind blowing event there. They went and talked to the developers and asked them what the deal was. And what they found out is that the developers, like they thought it was too expensive and what that meant. So that means something different inside an enterprise. What that means is that the internal funny money of it is more expensive. So they had, it wasn't like at some point it becomes kind of actual money, but, but inside large organizations, there's also like a lot of like internal accounting, which is just like a number that appears in one cell in a spreadsheet versus another cell in a spreadsheet. Right. And it's literally like copy paste accounting. Right. And so like realizing that like Tony and the team were like, Oh, right. Well, our goal is to have people use this because when they use it, we know they will be running more efficiently and therefore our business will be running more efficiently. So what if we don't charge them? Right. Cause we're already, we're like, it's all just silly money anyways. And sure enough, people started consuming it more and more. Right. And now, you know, towards the out years of it, once people see the value of it, they put the effort into it. This is another exciting tactic. Some vendors use, then it's easier to have them pay for it in real money or otherwise, because they're like, well, yes, of course it's valuable. Right. Like, and the amount of money that I'm going to pay for it is negligible for like the benefits that I get from it. But you only get to that point, as you were saying, Ben, if you are focused on consumption, right. Like focused on people actually using stuff, which immediately trickles down into what you were saying is like, all right, why are they not using it?
47:40Maybe because as you, as you said, there's a cold login page and so we should make it more hospitable and explain what it is and we need better documentation. Right. And so you have that goal of consumption and that drives all these things that you might be otherwise neglecting. Yeah. But I like what you're saying there. There should be no toll booths on the golden path. Oh, Hey, I like that. Type that one up. Put it in your threads. That's a talk title just waiting to happen, isn't it? Yeah, exactly. Yeah. And, and, you know, the other thing that I thought was like, that I'm, I'm really interested in what you're saying is, is you were, you, you, you were, you were starting to go over something new and different that this whole backstage thing is attempting to do. Right. Like, like, like what you were talking about is almost a good example of figuring out what the principles and the identity of your platform is. Right. And that is that, I mean, what you're going over is, is what backstage deal is. And, and another thing I'm always interested in, in technologies is how does, how does, how does, how does it want me to think? Because as a developer, especially one of the things that is like sort of half true that you're taught early on is you should always use the right tool for the job. And like, you should, you shouldn't like let the tool dictate how you do something, right? Like you've got to control the tools, which I think is, you find is right 30 to 40% of the time. Right. Because instead what you're often faced with is you have a tool, right? And you don't want to fall into the fallacy of when all you have is, is a hammer. Everything looks like a nail. Instead you want to think like, well, if I have a hammer, maybe I shouldn't go buy screws. Right. And, and you want to think like, how does this technology want me to think? And so for example, you're going over the backstage stuff. Right. And what, what, what I'm like detecting from what you're saying, and you can kind of decode this from how Spotify has talked about it originally is backstage wants you to be as microservice-y as possible, right?
49:53If you just have a bunch of monoliths, whatever that means. If you just have a bunch of teams of people working in your organization and they don't really ever have to coordinate with each other, let alone like share services, like backstage is like a lot of work to get kind of nothing. Right. Cause, but if you want to have all these teams coordinate more and know about each other, you want them using the services that they have. You've got like various components of your system that you need to find out. Like backstage, that's like how it wants you to think and therefore it's going to do something good for you. Right. And so I always think it's important, especially with something seemingly as simplistic as backstage, like to figure out like, what is the complex, the good complexity it wants me to have that it's trying to help me do. And I don't know, like what you're saying is making me think that it really like, it wants you to have that highly distributed microservice-y cloud native way of thinking about things. It's what it's really trying to help out with. Maybe. I don't know if I fully subscribe to that. Maybe our listeners can tell us what they think, but I think there's another case where I was an integrator for a long time. So I was working with lots and lots of third parties and the larger the organization, the more third parties you've got. Yeah. Yeah. And those that you need to know what those third parties offer and they sometimes need to know something about what you offer in order to make that integration happen. Right. If they've got APIs and there will be, you know, usually thousands of them out on the Internet somewhere, you know, you've got someone who specializes in fraud detection or someone who specializes in, you know, cleaning data in particular ways or whatever it might be. You could have someone where you order stuff, you know, an order API where you're ordering things from them or vice versa. They're ordering from you. You've got all this stuff, all these APIs that you're offering, regardless of whether it's microserviced or not.
51:58Yeah. No, I think I think that's a better way of putting it in the sense of if you're if you need to collaborate and use a bunch of other stuff, that's what it wants. Right. Like that is that is what it's valuable. And then and then you could, you know, the further potential refinement of that is and that's all the time. Right. And so like like like and your point would be of doing SI work is a good one. Right. Is like I mean, it's right there in the title integrator. Right. Like so if you're like pulling together a bunch of stuff like it's it. Maybe to put it another way is like it feels like a lot of the functionality built into backstage is working with other groups. Whereas there's plenty of like things that are like your project management documentation stuff that's more about what's the word intra group stuff. Right. Like helping your group inside, like keep track of what they're doing in their own stuff. Whereas like what's layered on in backstage is like, well, there's other people in the world. And so it's almost like the landing page for your project. Right. Like how do you apply all the stuff we've been talking about to your own the thing that this group is working on? Yeah, I think I think backstage goes very wide. And I think I think it's you hit the nail on the head when you said collaboration, really. That's sort of what it's all about. But it's got a great use case in in the whole self-service thing as well. Like if you're going to have a self-service button to create a database or whatever it might be, where better to put it than in the portal where all the developers go every day. So, you know, it provides you that focal point that otherwise is disparate in an enterprise. You know, it's in wikis or, oh, no, that was a Word document that lives on this drive that you need to get access to through the VPN. Or it's blown up and all over the place.
53:58And this starts to bring it together into a focal point. So, yeah, your documentation might be a little bit insular. It might just be about the component that you're working on. But perhaps don't underestimate how useful it is for someone else to be able to get access to that in the middle of the day. While you're, you know, tucked up in bed and they're on call trying to, you know, keep the lights on. So I think it's easy to, I think it's a useful thing for a very broad gamut of situations and problems. And I love it. I love working in it. It's a really nice place to be. It's well thought out and it has a lot of value to it. And I think it brings a lot of value to a platform. If your platform doesn't have something like this, maybe it's time to think about including it. Yeah. Yeah, yeah. No, that's interesting. Well, I think that's what we have to say on this topic, Ben. Okay. All right. I made it. I've unlocked level two, end of level Guardian now. We defeated the level boss or whatever. I managed to exhaust a Coté. Brilliant. Yeah. You know, sometimes you just got to be like, well, we're done. That's, we've wrapped it up. On that bombshell, maybe it's time to end. Well, as always, this has been a episode of Tanzu Talk. You know, maybe you watch the video of it or you're watching it. But we stream these live if you go to the VMware Tanzu channel, which is just go to YouTube and search for VMware Tanzu and you'll find it. And, you know, so you can watch the video of it. You can watch it live. Or if you're subscribed to the podcast and you listen to it there, you must know that you would go to TanzuTalk.com to find the podcast or just search around. If you'd like to listen to the podcast, you can search around there.
55:58And it's always nice if you want to help us promote and share this stuff. I think there was a lot of fun stuff in this episode that's useful. So you should share it with people and be like, we need that. And look, it ends because they just exhausted the topic, which is thrilling. So, yeah, we'll see everyone next time. Bye-bye. Bye-bye. Bye-bye.