 Welcome to today's sales enablement training. Today, we are really pleased to have with us Priyanka, who has been in the cloud native space for quite a while and talking to us about cloud native transformations. So with that, we'd just love to pass to you, Priyanka. Awesome, thank you so much, William. So I will start sharing my screen and presenting, if that sounds right. Okay, Google Chrome share and present. And present. All right, well, that's the last slide. We're done, bye. Okay, so again, thank you everybody for having me. Thanks, William, for that lovely intro and I'm excited to be here. Today, we're going to talk about the cloud native ecosystem and I'm going to focus on the people, the personas and the purchasing power that they have. So this stock is very different from the one that William gave, I think, a few weeks ago, which was focused on what is the cloud native transformation that the industry is going through. At the end of my presentation, if people want an overview of how cloud native came about, I'm happy to do that. Actually, before I get into the rest of my deck, I wanna do a quick poll. How many people want a brief history of cloud native? How should we poll people, I'm trying. Any thoughts, William? How can I get a sense? I would say go for it. Let's do a brief history of cloud native. We have a few chats that are saying yes. Okay, cool, cool. All right, thank you, folks. So let me introduce myself very quickly and then I'll get into cloud native and the details of that. So I'm Priyanka. I serve as director of cloud native here at GitLab. It's officially cloud native alliances, but I've started just saying cloud native because I'm involved in things from talking to other companies around DevOps for alliances, presenting at conferences, organizing ice cream trucks for fun things we do or being involved in the serverless project and bringing that functionality to GitLab. So it's a mixed bag of responsibilities that I have. I really enjoy it and I'm grateful to have found a job that leverages all the good I have and doesn't make me do the things I don't want to do. So it really works out. I'm on Twitter at Priyanka. I'm always there, please feel free to follow me. I love new followers. So the thesis for today's talk, I'll get into the cloud native history in a second, is that with the advent of cloud native, engineering leaders are now empowered to procure and purchase software that helps them ship faster and reliably. These engineering leaders are different from the usual high ticket item buyer and an understanding of their persona is critical to success when selling DevOps software. I'm going to focus our talk today on the champion persona. So in the GitLab handbook, there's the buyer persona section, which I will link to over here. This section has a bunch of categories, so things like directors, VPs or the CIOs or the CISOs. So we call them the buyer. I differentiate people who are not CIO, CISO type people into the champion persona. They may or may not themselves be the buyer, but they definitely will be able to have their direct boss sign the check. So it's anyone who has overview of multiple teams and their productivity in an organization. These people, I call them the champion because they can get us any vendor like GitLab or any other or even open source project, a foothold into the company and a pretty sizable one too, but they are the critical starting point. You have to get them bought in or it's just a very uphill or a very slow land and expand model. And by the way, I'm talking about this persona based on my experience with all these companies and the observability space. So this is one person's perspective. I found it useful when I engage with the community and I hope you'll find it useful too, but by no means is this the comprehensive persona guide or anything like that. All right, with that disclaimer. So as I said, these people can be anyone who has overview of multiple teams and their productivity. So titles are also varied. So it can be a director of engineering, VP platform, even like a systems architect, senior manager, sometimes even team leads. Depends on what is their purview and how do they think? Something that's interesting that Cloud Native has enabled and alluded to this earlier is that these people themselves or their direct boss can cut million dollar checks without needing to heavily involve the CIO. Of course, you still need to go through procurement. There's no way around that once you're in the large six, seven figures, I'm sure you guys know this better than anyone. But it is possible to get these folks to write large checks. So this makes this persona even that much more credit important. When we think about this champion persona and it's good to understand what's their responsibilities and how do they get promoted, right? So what I've seen is that they tend, as I said, they tend to lead multiple teams and have insight into cross-organization productivity challenges. They're promoted for shipping fast and reliably and for introducing systemic improvements that enable that. So usually they get really excited when they feel they can introduce large scale improvements and ship faster more reliably every day as a company because that's what makes them, shows them to be the leader that they are in their organization. So I'll talk a little bit about these folks based on my understanding of them. Again, it's a one person's perspective. One second, I need some water. Okay, sorry about that. Okay, when we think about the self image of these folks, their primary work persona in their head is that they're a technologist. They're not a business person, they're not a buyer, they're not a manager. They're a technologist and they take pride in that. They always want to be on the cutting edge and know the latest. They're usually very well compensated and they're aware of it. But they're fairly humble and down to earth in general about socioeconomic factors which personally has made me really enjoy these interactions because there's no fru fruness. It's more just like, let's be real, let's talk about our interests that happen to be technology. Sometimes they can be a little intellectually, I would say, elite elitists just because they're operating at a level of understanding that many folks in their jobs never encounter and then they have to deal with very complex problems. As a result, their brain is trained to handle a lot and they value intellectual vitality in the people they talk to at all times. So where to find them? So I have great success when I talk to these people on Twitter. DMs are way more effective to reach a busy person than emails or LinkedIn in mail, God, things like that. But that said, it's a fine line so you don't want to be DMing left, right and center. You have to have some contacts, some conversation going, et cetera. They're often checking out the hacker news front page. I don't necessarily think all of them are that involved with the show HN, new on HN stuff but the front page is quite important, excuse me. They often go to very specific kinds of meetups and small group events. So there's a meetup called Papers We Love which is all about people really but predominantly technologists coming together and people sharing their favorite paper and why they like it. And when I say paper, I mean like academic or industry papers on software development, cloud computing, things like that. Being involved in these communities and being able to converse there is going to take you from 10 to 100 really fast. Partially because you'll have to read a paper or two and once you've read that, you'll be that much more comfortable in this space. When I first got into observability with LightStep, the first thing I did was read the Dapper paper which was about Google's Dapper tracing system. Describe the architecture and all those details and frankly, you really don't need to be an engineer to read that. Some technical knowledge is helpful but once I went through that paper, I had up-leveled my knowledge in just that one experience so much. It kept helping me for the next two years as I worked in observability. A few good papers to look at are the Google file system, anything you can find on Kubernetes and orchestration, maybe after this call I can search up some of the cool papers and share with you guys. I know a lot of the observability papers but we need to look a little bit more on the Kubernetes side so I'll research and send some your way. Then there are some small group Kubernetes events where people, it's like maybe maximum 50 people and it's maybe a meetup or a company organizing it and inviting like-minded companies. And then there are these small group events hosted by technologists like Brian Cantrell. There was something he did in San Francisco a few weeks, months back, which attracted a lot of folks who want to be on the cutting edge and think deep about these things. Another place you can find these people are workshops and I don't mean the generic, like learn how to go workshops at conferences but rather a lot of open source projects will bring people together for, so in the Kubernetes world, it's the special interest groups in observability. It's the context propagation, I forgot what they're calling themselves these is, context propagation, what was it? Nevermind, there's one where they're trying to decide on the wire formats. So places where decisions are made in small groups, those kinds of workshops, you'll find really high-end technologists. Then in the physical, in the large scale conference world, KubeCon has always been the mecca for these folks. Monetrama is a good one specific to observability but it has a lot of senior people showing up there. So yeah, that's another thing I should mention. When we think of these conferences, KubeCon or trauma and blah, blah, blah, you'll have some systems developer who's been working for five years but you'll also have the director of platform who's been in the industry for 20. It's really a democratizing field these places because everyone's interested in the technology. As I said, the self-image of these people, the primary self-image is technologists and so whether they're an individual developer or they're a director of development, they're showing up to these places. Some other conferences are Strangeloop, PromCon, GrafanaCon, SRECon, GopherCon, just a list that I know is good. I put here, there's definitely more. In general, if it's a systems conference, it's a good bet. And you know, something I noticed in the last few years having been in this space, when we started out, the first conference, when I was just entering space into 2016, the conversation was very Kubernetes, Kubernetes, Kubernetes, like what is Kubernetes, how do you use Kubernetes, that's around. And that's still going on, but then I thought 2017 and early 18 was very much the year of tooling. So everybody, like so many tools like sprung into the ecosystem and it was a discussion on how do we do metrics, how do we do logging, how do we do this, how do we do that? And everybody was talking about one special way. And that's something that's consistent, that's been consistent in the general DevOps ecosystem is that people have been talking about individual ways of doing things, which may be very, very cutting edge, but they haven't often talked about scale. And now, since the middle of 2018, I've noticed that folks are discussing just how many tools there are, how tooling is too fragmented, how we really need to think like enterprises when we're building our tool chain, it speaks directly to the GitLab story. It is so perfect. I couldn't have made it, I couldn't have manufactured it better if I tried. So we're in a really good place. This is the right time to talk about what we do. So going back to this champion persona, these folks appreciate conversations about the ecosystem, the latest trends or less monitoring, et cetera. They tend to be straight shooters and appreciate when people empathize with their struggles. Two years ago, it was how to make sense of the Kubernetes thing. Last year it was all the point solutions and this year it's like, oh God, we have too many tools. And then they really appreciate demos and technical knowledge. Now, when I say technical knowledge, many people get scared, right? That, hey, I'm not a systems engineer, I haven't spent 10 years in this space, how am I gonna do this? It's actually okay to not know how to define the function and write the code yourself. My experience has been that what's more important is the strategic level view. You need to understand the ramifications of various technologies and tooling and how that impacts people's lives in a very technical way. Like, okay, this is how your workflow will be impacted. This is how the data you collect will be impacted, that kind of stuff. But you don't need to have the experience building those data sets, building those tables, all of that. So I've found it really welcomed when I share my thoughts on how to set up your observability stack with people, even though I may not be developing every day. People actually appreciate the sort of panoramic viewpoint. They definitely don't like pitches that sound can. Now, keep in mind, your pitch can be, like, you know, some one main thing, but you have to cater it to the person so you're empathetic. Anything that sound can, anything that's like mass marketing, mass email, they're just too busy to even, they can filter it pretty quickly. And so they're not being rude, they just don't have time. So yeah, so that's the champion persona. I've spent a bunch of time talking about it. I'll quickly move on to my personal engagement strategy with these folks. So when we, as I said, this is one person's experience and this is what's worked for me. I have worked hard to understand the space and understand these people and the technology that they operate with every day and become a peer in a way. As I said, I don't need to be coding every day to be a peer. I talk about the cloud native ecosystem all the time. This is, I think my third talk of the week. It's too much, but it seems like there's a lot of demand. And I talk about like various things, people, struggles that they have. I tweet about it. I retweet other people. I engage. Basically, I consider myself a peer in this space because I'm contributing to the conversation. I try to teach people something new and that comes from talking to disparate end users at all times because there's always a nugget of information that you can delight people with. I try to always be up to date and I do that a lot via Twitter and also by keeping up the newsletters and all of that. Being credible is really important and so citing references, the exciting where I get my information is more than half the battle. So you need to make sure you know who said what and what paper that was in, all of that kind of stuff. It sounds harder than it is. You read five papers and you're good to go. And then the other thing is always be ready to demo at moment's notice. So I'll give you an example. I was once in Austin and I walked into one of the companies that I said before's office just to chat about observability with one person. That was my expectation. I walk in, there's actually a team of 10 sitting there, everywhere from a director to an intern and they're like, okay, we are ready to get going with open tracing if you can convince us that we should do it. And I was like, oh, cool, all right. And so I talked through the concepts a little bit and then I saw them listening, but not really buying as much. And I was like, okay, you know what? Let's just go and do a demo. And on moments notice, I pulled up my computer, I had an engaging demo that I had built with the team and we walked through it, they saw and result of like, I was showing traces with open tracing and people instantly got it. And they were really impressed that I was able to show and tell both at the same time and they are actually a really large open tracing user at this point. But had I not been ready for that demo or for that large crowd, I don't know what the result would have been. Then the other thing that I tend to do is help as much as I can. I contribute generously, GitLab in general values, co-contributing, building together. And I expanded beyond the company to the ecosystem. And a lot of times it's doing things that you don't have time for, but it always pays off. So I'll give an example, one of the, so Yeager, I have spent a bunch of time working with Yuri and he was like, hey, can you write my case studies? And I was like, no, I have a really busy job. I can't do that. And he's like, okay, well, can you help at all? And I pushed back quite a few times, but they said that they really wanted someone who understood the end user and observability to just guide them through. And so I was like, okay, well, it seems like this is important. So I'll support in one, in whatever, in how much ever time or the weekend I can give you. And that paid off right away because by chance we were talking and they're like, oh, you're in New York. Why don't you come and talk about GitLab? And myself, Mike Walsh and Patrick Carlin ended up doing a presentation there. So this is one case where it was very quick, I guess, but in general, building Goodwill in the industry will get you so much. Oh, sorry, am I at time? Yeah, I think there's a lot of great content. What we might need to do is invite you back to chat some more. Oh, shoot, it's 9.25, I am so sorry. So what would be great is I'll give the recording a pause. So we have this content recorded. I do wanna say that in the YouTube video, I will link a copy of Priyanka's slides. I will also send a link to the Handbook page, which will have all of the slide content, it'll be in the Handbook. And that will be in the description of the YouTube video that I will publish.