Why don't you introduce our guest? Wait, which one of us is a guest? We're all guests of this short life, but you're the guest. That's right, so Josh McKenty, who are you? Fantastic, thanks. Very happy to be here, wherever here is. I am the head of the Global Ecosystem Engineering Team at Pivotal, which basically means I'm really good at begging favors from the rest of the company. Who are you begging favors on behalf of? Well, it's been an interesting six months. Last year, Pivotal had, I think, a dozen partners. Right now, we have about 125, and if this keeps up, I think we'll have about 1,000 by the end of next year. Oh, right, right. So it's almost too many to count, but some obvious ones just highlighted in the last week, top of my head, Apogee, Dynatrace, New Relic, CloudBees, Artifactory, GitLab. You know, we're really excited to announce some work with Mongo today, a ton of different Postgres vendors. Like, you name it, we have a partnership there. Right. And then, so what is, I mean, there's so many questions, but what does a partnership entail with someone like us? Like, is it like sales or technology or like, I don't know, marshmallows? It's like Lawrence and Arabia in a little town called Aqaba. Uh-huh. I like the desert because it's clean. See, I told you I know 40-plus of your references. There you go. But beyond Sanford and Son, I'm out. Yeah, so Global Ecosystem team, we actually rolled up our sort of three different partnership groups earlier this year. So we have ISV partners, really, technology partners where we've done some deep engineering work to produce an integrated solution. So you can think of, you know, anything from a data service running on top of Pivotal Cloud Foundry to APM tooling that can run inside the containers along with your Spring Boot.
2:01Right. So then we have Global SIs, your typical Accenture, Capgemini, Cognizant. And then we have Regional SIs, and probably our most famous in that one will be ECS team out of Colorado. Oh, right. Who's worked on more Pivotal Cloud Foundry accounts than I think anyone else. Yeah, that dude tweets almost as much as James Watters. Right. And James Watters tweets back. Yeah, yeah. Yeah. So is it a pretty fair, at least on the technology front, to assume that if there's a partnership, that means there's a pretty tight, close integration into PCF and vice versa? Like with things like, you know, Apogee and other people like that? Yeah. So we don't do partnership for PR's sake. In fact, the partner team is not part of marketing. It's part of product. Right. So I guess if you think of it from an org chart standpoint, generally by the time a press release comes out, we're talking about what customers have done with, you know, three to six months' worth of engineering work at least. Okay. What kind of engineering work takes place? I mean, you described the different models. I might sit outside of the solution. I might, you know, be a service that shows up. So when we have to integrate, what kind of engineering work typically, typical may never be typical. What kind of engineering work do we commonly see, at least for some of these, when it comes to trying to make them feel to a customer like, I'm just consuming another piece of your platform, because I've got this weird side thing I've got to engage with. Yeah, so I was partly joking when I said Lawrence of Arabia in a little town called Acqua, but I wasn't. I really think of this as being like Microsoft circa 1992 and the rise of the .exe, right? So you've got a standard packaging format for your applications and you know anything that's wrapped up as an .exe is going to run on Microsoft Windows, roughly speaking, as long as the versions line up. So we have a package format for Pivotal Cloud Foundry that we call Tiles, and we've worked really hard to standardize some SDKs for tile developers.
4:02This is generally joint engineering work. So there's engineers on my team that pair up with engineers in our partners' companies, and we sort of sprint to a first version, to an MVP, so that we can get it as a classic Pivotal Labs, fast feedback loop, lean startup kind of approach. Use a few Lighthouse accounts to tell us if we're building the right thing. The tile can come up in multiple ways, right? I can envision a relationship to an already existing SaaS service, I think. It could be something that we actually use Bosch and build out VMs and infrastructure. And then I think you've described, too, that you also try to make sure the hooks are there back into platform stuff like logging. I want it to feel like a first-class citizen in the platform. So what are some of those things that you might write in that assessment? What does the tile make? Yeah, absolutely. So a service broker that connects to a SaaS data service or an on-premise database in the basement. So most companies in the world still have either Oracle or DB2 or something locked down there with cockroaches. And so we often have a service broker provisioned in the platform that connects to those. Or we're deploying, as you say, into VMs, distributed data stores. We even package up applications now. So we're starting to see more and more integration level, maybe not COTS apps, but certainly business-focused. So things like Mendix, MBAS solutions, analytics and visualization tool sets, and so on. Interesting. And so what, I mean, in the realm of strategy on both sides of that table, why do we need partners? What's our goal? I mean, the SI stuff is sort of like, well, people implement stuff. I mean, at a very basic level. So that kind of makes sense. But walk us through what we try to get as a company out of having a bunch of partners. Build versus buying these two. Why don't we just build the whole thing? Well, and bear in mind, creating a real partner ecosystem is about the hardest thing that you can possibly imagine.
6:09It's not just a double-ended marketplace, you know, but it's almost a three-cornered marketplace. So why would we do that? I think there's a reason it's good for our customers, and we always start with that, which is they don't want to buy everything from Pivotal. They want to buy the things that we're good at, right? We're really, really good at cloud-native infrastructure. We're great at Java frameworks. But they also want to buy APM tools from APM vendors. They want to buy – and increasingly, hard software is hard, yo. So we're really good at the hard software we're good at, and other vendors are good at the hard software they're good at. So our buyers are really sophisticated. So that's why the customer wants it. Why we want it is simply leverage. We can't pick the winner in every spot in the marketplace. Do you know the Donnie Berkholdt accordion thesis? I think we talked about this before. I don't remember, but it sounds like it might involve, like, carnies and gypsies and stuff. Yeah, exactly. Short people and tall people. Sure. So at any moment in IT, there's parts of the accordion that are contracting and standardizing. There's other parts of the accordion that are expanding and innovating. Sure. And when you've contracted to a perfect standard, you have a standard of one choice, right? So there's only 19-inch racks in data storage. Right, right, right. We don't do weird alternate rack formats. There's really only IP as a Layer 3 protocol. I mean, there are others, but, like, if you do IP, you're going to be fine. Right. There's more or less only JavaScript and its many variants for doing that kind of thing. On the client side, yes, in the browser, there is JavaScript. Right, right, right. But there are other places in the stack where we've never achieved a monopoly of one. What is your favorite database, for instance? There isn't just a single choice for database. There's no single choice for queue services, even though we happen to love RabbitMQ.
8:11It's not the only one that people like. Right. And in areas of innovation, there are more and more options. And so we can't be in the business of picking winners or of telling our customers, oh, you've got to use this one, you've got to use that one, because that's the only one we support, even if it's the one we built. So there's, like, a big stack of accordions and various parts of ingress and egress. Yeah, think of it almost as an Oompa Loompa band. Yeah. Yes. That makes sense. Yeah. Yeah, but then there's also that choice of, again, what do we decide to build ourselves? Because we can say, hey, look, we don't want to pick a winner. And in some cases, we do think this should be native, built-in stuff. I mean, there's always that tension you brought at Microsoft. Yeah. Circa 1992. Yeah. Microsoft eats their ecosystem from time to time. Amazon does others. So there's always that maybe healthy tension between your ecosystem and your core engineering. And I guess a lot of your job is to continue to be transparent and help our partners find value. But how do you balance that tension? And how do you see Pivotal deciding between a build versus a buy? Oh, that's a great question. I think there are specific approaches. And then there's the general approach, which you highlighted, which is trust and transparency. Right. So I don't think Microsoft was the best example, but they're certainly not the worst. I've worked in other ecosystems that were 100% cannibalistic. And as a vendor, you know, and particularly I've been a startup founder, so as a startup vendor, you either want to become a monopoly or you want to become acquired at a price that indicates you were going to become a monopoly. And so if you're going to be part of an ecosystem, there needs, you know, the best thing that Microsoft did, honestly, was when they saw a market that they planned on massacring, they bought up the vendors in it. They said, look, we want to own that space. We're going to buy you. As opposed to we are going to obliterate you by undercutting and disintermediating.
10:11It's a warm, wet embrace of Redmond. Right. And there's a bunch of safeties in here. And I think the Redmond embrace, if you compare it to, let's say, the Apple marketplace today and the iOS, if you were packaging executables and you were a member of the Microsoft Partner Program, they were still your customers. You sold to them directly. You priced it. You wrote your own SLA. You went through a certification effort, but Microsoft didn't try and get between you and your customer. And there are other marketplaces where the platform has decided to interject themselves in a way that's frankly kind of dangerous. So I think we're trying to maintain that position of saying what is best for the customer is always in the long-term best for Pivotal. And if that means they prefer our partners' products to ours, I think that's actually great. I think the rising tide lifts all boats. So I had one more question, but now I have two. I've noticed the way we do product management around here is very hyper-agile, which is to say, and I'm doing this in a dismissive, funny way to make a point, and it's just like, there's no roadmaps. And instead of roadmaps, you're more adaptive in what you're doing based on the stakeholders and customers and users. So the risk of a roadmap is, as this guy Ben Thompson always jokes, is like, you might be successful after a year and have done exactly what you wanted, and that's the wrong thing. So it can be better to be adaptive. And so I'm curious how you see that mentality being different in an ISV partner world, right? Like, you were talking about how, you know, you have more of a team. I'm putting words in your mouth. That's a little more adaptive. But I would imagine in traditional partner work, you sort of like, you know, anytime there's two parties, there's a lot of word docs involved. And so I imagine, like, you spec things out traditionally with partners, and it's like, it's all protective. Like, in case something goes bad, we go back and refer to what we promised to do and all this nonsense.
12:11But if you have more of a Pivotal way of doing things, like, does that change that at all? Or are there still a lot of word docs involved? Or how do you fit that in? Yeah, I often joke, but I'm usually serious, that I have the only engineering team inside Pivotal that doesn't do Pivotal things, right? We're not all pair programming all the time. We're not all test-driven development. We're not all agile backlog. And the reason is our mandate is to match the style of our partner. Oh, right, right. And so if they're an SDLC shop and our customers are really excited about their products, we will figure out how to work with them. So we do have a lot of partners where we have taught them to pair program because they were excited to do that. Or they were already doing it and we've gone to their offices and paired up with their developers. We also have a small number of partners where we've put a Gantt chart together and a 20-page Word doc with a bunch of diagrams. And we've argued about the diagrams instead of writing code and arguing about the code. And frankly, both approaches have worked. What's interesting is, I mean, I get back to this accordion thesis just because I like the sort of mental picture of a bunch of people playing accordion. And I used to play accordion. Oh, the shit comes out. There you go. So, you know, not all areas of IT are innovating all the time at the same speed. And there are places in the stack where there are very necessary capabilities that are not exciting, right? And they don't need to be exciting. And so in a certain sense, when the requirements are really well identified and this is a must-have but boring, I'm thinking of antivirus, right? I'm sure someone out there would say that there is innovation going on in antivirus. For us, it is generally a checkbox. We're doing very innovative things in security, but not on the antivirus side. And so working with AV partners has really been a matter of saying, here's the very basic checklist that covers regulatory compliance.
14:13Right. Let's get that done in this time frame for these accounts. Yeah. It looks like a Gantt chart. Yeah, I guess that makes sense. I mean, Gantt charts and Waterfall and all that upfront stuff are a lot less dangerous if you basically know exactly what you want. I mean, back to the joke. Right. But there are, and it would also make sense that in the building out the partner ecosystem, which is to say, not all of it, but a fair chunk of it is expected behavior that doesn't already come in the platform that you get through partners. Like, the fact that it's expected behavior is like, well, we know exactly what it should do. So we don't have to invent all of it. Right. Yeah. Right. And it's actually not high value for us to do it because just because it's expected doesn't mean it's easy. Right, right. It can be hard. It's just well understood. Yeah. So you've name dropped a couple of things along the way, some of our favorite partners. As a co-estor on set of categories that when our customers come to us and say, look, I need to be able to do X, Y, Z, do you feel like that's a pretty discreet set of things? There's always going to be outliers. But what are those core categories of things that people want to plug into a platform? You know what's fun is that we use the partner ecosystem to identify the maturity of our accounts. And usually our customers start asking for table stakes. The table stakes are, hey, we need source control. We need CI tooling. We need some kind of artifact repository. We've got to at least be able to do some dev work. So they start with dev tools. And then they start going out into prod and they say, oh, we need APM. Because now that we've built a bunch of software, we need to understand what's going on. So then we get into APM tools. And then they say, oh, okay, so now that we're done connecting to systems of record in our initial, like, in the basement Oracle database, we want to start using next generation data stores. We want some NoSQL. So then we see, you know, Cassandra, Mongo, Couch, and so on. As the big data side of the data to apps equation is finally coming together, and I've been really excited about Spring Cloud data flow, especially this week, we're now seeing more and more pull to say, hey, give us Spark and Kafka and Hadoop and like 20 other things in that space.
16:32They're like, now we really want to just connect everything together. Oh, and by the way, now we need integration platforms. So we see this spread into more and more systems of engagement on the one side and more and more systems of record on the other side. It's an interesting pull. I mean, I guess to answer your question long-windedly, there's no simple category, which is why we have so many partners and why it looks like it's going to expand. I mean, think about Windows circa 1992. People are like, what do you want to do with an operating system? Right? You've called out things like data services, messaging, mobile back into the surface, AP and things like that. Yeah. I think we'll go all the way up the stack, which is, I guess, exciting. You point out an interesting journey there of, you know, potentially the company doesn't just look at a platform and say, all right, give me all your new hotness and that's where I deploy my stuff. I know, I'd love you to maybe rant for a second, but you hate the term migration. Yeah. And things like that. But, you know, as a shop's looking at a platform like PCF or what have you and saying, I want to start using this and getting real value out of that, that probably doesn't mean just net new stuff. Right. It says, okay, I've got this whole stable of stuff that, you know, maybe is fine where it is. Maybe I do want to move it. But, you know, as you look at that, what role does a marketplace play when it comes into pick the right word, refactoring, refugging? So, first of all, why do you hate the word migration? And then secondarily, how does an ecosystem help whatever we want to call this thing of moving things? I hate the word because lift and shift has no value. Right. So, the idea of a migration is just, hey, let's take it from A and put it in B and somehow that will be better. It's never better. And it costs a lot of money to move it, so why would you bother? But there's tremendous value in getting apps onto the platform if you tweak them enough that they can get value out of being in a cloud-native environment. And so, I love the term re-platforming if what you're focused on is the minimum amount of refactor required to take advantage of the platform. And I love the term refactoring because it's well understood from an engineering standpoint.
18:33Now, the line, people say, look, we start with Greenfield apps not because that's the only place where we can use a platform, but because typically what's hard about adopting cloud-native is not tech, it's people and organizational process and the rules and checklists and the thousand people in every organization who are allowed to say no and not allowed to say yes. And so, it's easier to go and figure those things out with Greenfield projects, say, hey, let's go build some systems of engagement first. But over time, your systems of engagement always have to connect to the systems of record. And I think about mobile apps and everyone says, oh, mobile apps initially were just for marketing, right? Or then they were new databases and they were just cute loyalty stuff. And then sooner or later, you're like, oh, well, we want to do search, product search. Okay, we've got to tie into the product database, which usually is actually buried in the POS system. Oh, well, now we want to do all of our customer service experience and new user sign-up and we need to tie into the... At some point, you realize every system of record is also part of your systems of engagement. So, those integration points, for a really savvy organization, not only are they looking at the tile format and our partner ecosystem as the way to manage connective tissue, they're writing their own tiles. They're building their own internal marketplace and they're using Pivotal Cloud Foundry as the platform to deliver their internal services as well as external partner services. You know, it reminds me of Jeff Bezos' famous email saying, look, everything at Amazon is going to be a web service or you're fired. Thank you very much and have a nice day. But that is what's happening with these large-scale re-platforming. They're saying, look, everything inside the organization is going to be a service on Cloud Foundry and it's going to use this set of binding ideas.
20:33So, then I wanted to ask you about the open control stuff you worked on to wrap up with because that's always fascinating. You know, more YAML in the world can't help but help. I don't know. But before that, so we talked a lot about, I would say, the sort of tech partnerships. So, what do we do with SIs and, I don't know, warm bodies and meatware people and some of the software? So, what's an overview of how that functions around here? Yeah. There are basically two kinds of things a partner can do. They can deliver PCF, which typically means, you know, install and configure it. And we can install and configure PCF in a couple of hours, but a real enterprise-grade deployment is tying back into those key systems, authentication, authorization, logging, SIEM, and so on. And so, there's some well-understood but boring work there, right? And SIs do it not because they love it, because it's not great margins and it is usually fixed duration, but because it maintains a trusted relationship with the account. Yeah. The second and more interesting side is typically scale-out of this refactoring and replatforming work. And look, Pivotal Labs is an amazing, probably the world's premier development shop in terms of agile and lean, but there are a fixed number of us, right? The whole company is only a couple thousand people. So, when we have customers who say, look, we've got 30,000 of our own developers, we'd like you to give a staff aug of another 10,000, we're just not in that business. Right. But it's a huge business. And so, a lot of our largest scale-out accounts have now been saying, you know, train up partners, bring them to the table, tell us they're certified, embed some of your own people in that relationship. And so, we've been driving all of those programs, certification programs, and sales enablement, as well as practitioner enablement, and then a lot of joint go-to-market.
22:37So, when you, in your position, when you look at, like, staff augmentation, how it is nowadays, do you think it's changed a lot for this kind of cloud-native development, or is it still basically like, oh, we need people to write the code? I mean, like, we spend a lot of time in Pivotal marketing, I guess, to be crass about it, like, telling people how they need to do things differently. Right. And so, I wonder if in the staff augmentation world, when you're working on a platform like this, does that add up, or is it more traditional? It is different. I think the reality is the difference is sort of split. But, you know, Pivotal takes the extreme opinionated view of, you know, all pairs, all the time, all test-driven, all the time, never more than eight people on a team, and maybe 12 in a pinch. And we see, and the old world is 40 people in a very hot room in India for three years. And so, you know, in a re-platforming, re-factoring era, we see, we've definitely seen team sizes come down. We do see a standard team size closer to two pizzas. They have bigger pizzas in other parts of the world, I think. So those teams are closer to 20. Or smaller appetites. Or one slice apiece, something. They, you know, they are shorter-duration projects. They're six-week or 12-week or 24-week engagements as opposed to three years. Early shorter to the first delivery. Yeah, yeah. They're not, they're still not doing, you know, CD in terms of day one we push code, during the interview we push code, we push code, you know, before we go home and when we get up in the morning. But we do see, you know, even in an outsourced staff org model, we see deployed production once a week. Right. Which is amazingly different. Yeah, yeah, yeah. So, I know you've got to go. We keep having people come in here. Yeah. But, so the last thing, like, on the changing topics, on the open control front, right?
24:40Yeah. So, first of all, I'll ask two questions and then let you just burn the rest of our time. So, one, can you just give us a brief overview of what it is? And two, like, when I look at it, it seems like the insight that you have, not you, but one has with open control is like, oh, we just need to document everything. Like, we actually have to do what we said we did. That's sort of important. But the key bottleneck with a lot of compliance stuff is documenting it. And so, I wonder if that's like, is that true or is that just something I made up? So, first of all, what is open control? So, open control is a open source project and community with a bunch of participants. I'd say the largest number today work for the GSA, although there are a lot of other agencies and private companies involved now. And GSA is? That's the General Services Administration. The General Services Administration of the United States government. We're going to have the first open control symposium probably end of September, early October. There's a survey up on open-control.org right now if you want to go. Oh, no more XYZ? What happened? XYZ also works. All right. But government agencies have a real problem with strange domain names. So, yeah, we've retired that. So, what it is is the idea that we treat infrastructure as code, we treat code as code, and then we treat compliance as paperwork. Right. And so, why not compliance as code? Put simply. It's something we tried to do years ago at NASA before kind of the tools were ready or the community was ready, and it's getting a lot of traction now. So, cloud.gov, which is Cloud Foundry run by the GSA, is using open control for their initial authorization to operate, their initial compliance effort, as are some other agencies. And so, it's YAML schemas and Go and Python tools for pipelining YAML into compliance.
26:42And we're working kind of backwards from the fact that today's auditors need a Word document in a specific format, but rather than us treating that as the artifact, we're treating that like a binary deployed in production. It should be immutable, and when it needs to change, we should change the pipeline behind it and change the source artifacts. So, we're treating compliance source code as being YAML, which can be in the same repositories along with the applications and along with the infrastructure configuration and so on. So, you can think of every aspect of your platform as being versioned and living in source control. And then you can also push that down further to where work is happening. The developers can start modifying that so you don't have the, what's the, the sort of like, it's not an analog loophole, although I guess it kind of is. There's a bad analog loophole between developers writing code, email, then going to a Word doc. And so, you can kind of close that loop out. Yeah. And you're also circumventing the fact that auditors have to come back in and interview the developers later on to be like, how does this work? Does this, should I test it this way or that way? Which, you know, is this nine-month process after the code's done. When you get to CD in government, you want to actually push code once a week or once a day. You have to update that documentation and have it signed off every time you want to push code. And so, if that documentation cycle is typically nine months, CD is impossible. So, OpenControl is really, I mean, fingers crossed, as a community effort, it's the only thing I've seen enabling continuous delivery for government agencies. Yeah. All right. Well, great. Well, tell people, I don't know, where your Twitter or other nonsense is online. Yeah. Jay McKenty, M-C-K-E-N-T-Y. And you have a blog that, like, you published the last five years ago or something. Yeah. I'm not, I spend a lot of time supporting my team blogging, you know.
28:42I think, like most people, Twitter is where people publish now. Yeah. Blogs are just a weird affectation. How do people send in ideas for things they'd love to see in our marketplace? Ah, that's a great question. You know, if you're already a Pivotal customer, just grab your sales rep or your platform architect. They know how to get a hold of us. If you're outside the ecosystem, just send an email to isv at pivotal.io. Awesome. Great. Well, we'll see everyone next time. Thanks. Thanks so much. Try not to pound the table. Don't go all, uh, what was that, guys? Russian? Don't take your shoe off. All my references are, like, 40 years old or so. No, but Stanford's not going to take off. That's right. Did you guys catch what it was gone? Yeah. It was rock at last.