 Okay. Then we'll just go. Hi, everybody, and welcome to SIG Usability's community update here at KubeCon North America 2020. What we've been focused on is really kicking off SIG usability over the past year and getting some of our first projects off the ground, and we're excited to be able to share with you both what we're doing here at SIG usability, why the Kubernetes community has decided to kick off SIG usability in the first place, and then some of the projects that we're working on as well as how you can find us in the upstream community and get engaged. Just to introduce myself really briefly, I'm Tasha Drew. I am the Director of Product Incubation at VMware, and I am the Co-Chair of SIG Usability, and I'm also the Co-Chair of the Working Group for Multitenancy in Kubernetes. My name is Gabby, Gabby Murno-Sazer, and at IBM started contributing to SIG usability about a year ago when it got started, and I'm a UX designer on the Kubernetes design team. I'm Carl Pearson. I am a UX researcher formally at Red Hat, and I've been involved with the SIG for about half a year now. Cool. So when we kicked off SIG usability, it was for a very sort of silly reason initially, which was that at VMware we've been working on vSphere and Kubernetes, and we had a bunch of icons that we've open sourced as part of a clarity.design project, and so we were wondering what the upstream iconography for Kubernetes was, and if we could work with them to have upstream icons to figure out like if I'm looking at something as a container, is it a cluster, is it a node, and then as I sort of dug through the various mailing lists, kind of ask my question, it started this torrent on the mailing list about how we really, as a community, as an upstream Kubernetes community, needed to make usability more of a top-level focus, and so from that we realized that we needed to form a special interest group, which in the Kubernetes upstream community is how we organize contributions basically. So here we see back in 2019, Newstack had a sort of evergreen article about how UX is Kubernetes biggest short-term challenge. We really see from people who are adopting Kubernetes that getting started and understanding how to use the project and understanding how to manage lifecycle and extensions can all be pretty confusing. Additionally, here's a study from Newstack also in 2019 saying top areas the Kubernetes project needs to address in 2020, and we see at the top really two things that can be pretty tightly coupled to core usability issues, which is core Kubernetes needs to start thinking about the administrator operational experience of operating Kubernetes, and also the developer experience of deploying applications and automating their lifecycle on Kubernetes. So from this data and from our own experiences as creators of Kubernetes, and as users and implementers of Kubernetes, we realized that we really needed to make usability a top-level concern in the upstream community to make sure that we were enabling people to really use Kubernetes in the way that it could be, if it was a little more user-friendly. So where to find us? So in the upstream community, the Kubernetes community is organized into SIGs or special interest groups, and so currently we have three chairs of SIG usability, myself, Gabby, and Himanshu. If you want to engage with us, what I would really suggest the best first step to be is to go to Google groups. So just type groups.google.com in your browser and look up SIG-usability Kubernetes, and you'll find our Google group. This is really a mailing list, and the mailing list is how we organize everything, such as sending out calendar invitations, having group conversations around various projects we're working on, sharing links, sharing documents. So if you're on the Google group, you'll get the invitations to our regular meetings. You can attend those meetings. They're open to the public. You'll be able to see our meeting minutes. You'll be able to see our notes. You'll be able to see links to interesting things that we're working on. So I really, I don't want to undersell the Google group because that should really be your first step if you're like, oh, this is a cool group of people working on things I'm interested in. I'd like to kind of understand maybe to start participating. Google group is really the best first step. The other thing I'd like to call out, and this applies to every Google group, is that when you join the Google group, you will not immediately get the calendar invitation. There's some lag in the system. And so just be patient. It may take up to five days because maybe there's a carrier pigeon involved in the back end. I have no idea. But you will eventually get this calendar invitation that will allow you to join our regular meetings here at SIG-usability. Some other places you can find us. We do have a page on the Kubernetes-SIG. So we have a repo there where we're starting to use the project tracker and highlight some of the work that we're working on. And so that's a good spot to kind of check out. Then we also post all of our videos to YouTube. You'll find these meeting notes, the link that I posted here. You'll also have added access to when you join our Google group. And finally, there is a Kubernetes Slack where all of the upstream maintainers have various channels for their SIG and different organizing functions. So you can join the Kubernetes Slack channel. And then we have a SIG-usability channel there where you can also talk to us. So TLDR, join the Google group. The links at the bottom of this page. We'd love to see you at our meetings. And we definitely are always interested in seeing new ways that people seek to address and improve upstreams, projects, usability, and also involve you in some of our projects. I'm now going to hand over to Gabby to lead us through something that we've been working on recently. Thanks, Tasha. So I'm going to be giving an overview of one of the projects that we have going on. We're calling it our jobs to be done study. A little bit of background first, just about my open source contributions. I hadn't contributed to open source before. And so about a year or so, this opportunity came up. So usability started. And I just thought it was a really cool opportunity to be able to do this type of user research as part of open source. And with Tasha's help and Carl, we've been able to put together this really great team around this project. The main questions that jobs to be done is kind of trying to answer is, one, who's using Kubernetes? Most importantly, for those people, what are they trying to achieve with Kubernetes? Kubernetes is the technology, but what are they trying to do? And what other options did they consider before deciding on Kubernetes? Once they do adopt Kubernetes, how do they go about kind of like working towards that objective or that goal? And ultimately, at the end of this, we're trying to figure out what are the top opportunities for the open source community to be able to improve Kubernetes. And we have a pretty good set of people here, myself, Tasha, Carl, Josie from Pivotal, and then Boaz as well. For those of you that haven't heard of jobs to be done, this is kind of like my favorite way of explaining it is that people don't want a quarter inch drill, drill being the technology. They want a quarter inch hole. So an example of this could be like if someone's trying to drill a hole and they had an adjustable lightsaber to do that, they would buy the lightsaber instead of the drill. So if you focus just completely on building this perfect quarter inch drill, you kind of miss the point or the opportunity to be able to help somebody just drill that perfect quarter inch hole. So this is a pretty industry standard approach and methodology. We just wanted to call out the two sources that we've been referencing, mainly this book, Jobs to be Done by Rosenfeld Media, and then also Jobs to be Done by Tony Olwick, who started the firm strategy. And so they're really well known for doing this approach as well. And just to cover some of the jobs to be done, kind of like standard terminology, we have the job, the job being like you want to drill the quarter inch hole, or you want to prepare a meal, for example. If we took the meal example and kind of like looked at the steps involved into making a meal, you don't just make a meal, like you need to go to the grocery store, you need to, or maybe like do like an online service or something like that to figure out like first what are you going to make, then what do you need in order to make it, double check that you have the right amount of everything, and then you can make a meal. And if you like the meal, you know, you may conclude that it was a good meal and that you'll make it again, or you may decide that this was not the best and better luck next time. That's kind of like the highest level concept behind Jobs to be Done is that you do your analysis around this job. The other concept that's important to call out is this idea of a desired outcome, which again goes back to the drill the quarter inch hole, not the drill. And so if we take a music example, an example here is let's minimize the time it takes to get songs in the desired order for listening. And if you kind of like look at the statement, it feels like very specific. And the reason is that it is, you know, we have the reason that it's structured this way. And again, this is from Jobs to be Done is because, you know, after you do qualitative interviews to, to figure out like, what's the job? What are the steps? This kind of like informs a survey that you send out with all these desired outcomes, and you end up generating maybe like 100 to 150 of these. And what happens is that when you send this survey out, you ask people, you know, how important is this to you? Also, how satisfied are you with your ability to do it right now? And so, you know, you get people's input on these very structured statements. And what ends up coming out of this is this really amazing opportunity landscape. So if you look here at the little at the quadrants, you have everything from over served, over served being that people were very satisfied. And it's not very important. So probably don't want to focus on that. But then on the opposite spectrum, you have outcomes that are very important to people. And they're not very satisfied with how they're done today. And so what we call those is underserved. You know, it's very important to people to be able to do these. They're not satisfied. And so you as a project or you as a community, how can you better serve these? And then you have everything in the middle, which is like mid importance and mid satisfaction. So what we've done so far, as far as this process is we're still pretty early on. But what we have done is we have designed a screening survey, which we sent out to collect basically background information on people, people that use Kubernetes. And we also included a free forum response, and put it in a net promoter score as well. And we sent this out through the CNCF Twitter, as a way to both qualify these people and just kind of see what their use of containers and Kubernetes is. But also, you know, for the eight weeks that we ran the survey of the 1800 people that responded, 41 of those agreed to be contacted. So what we're going to be doing next is setting up qualitative interviews with these people. But we also wanted to share from the survey that we sent out the data that came back, because we also think that this is super interesting. That talks about a little bit about how people use Kubernetes and containers. And so with that, I'm going to pass it off to Karl. And Karl is going to take us through the analysis that he did on the survey. Thanks, Gabby. So yeah, we collected all of this data to get a background for some of these folks that we hope to interview down the road. And we got people from all over the world, mainly Europe and North America, but a few people from Asia, Australia and South and Central America as well. For the organization type, we have a lot of people that didn't fit into the buckets of consultants or managed service providers. So we could be any other kind of organization. Had the fewest consultants and still a good number of managed service providers as well. And we also looked at people's job function and their role. So the job function is on the left and the role is on the right. So we primarily have software architects, DevOps management and backend developers. That is kind of the three that are leading the pack there. But we did get a really, really widespread. So we have some things that are probably a lot less common when you think of Kubernetes, such as sales or marketing. So there are a pretty, pretty wide set of people that responded to this. Although most of the people are some of the more typical titles that come to mind. We mostly had individual contributors or consultants. But we still got a good number of managers or directors as well. So we're hoping that we can talk to people that are both in the IC roles and in more of the management roles as well when we do these interviews. For the environments that these folks had, by far and away, people were running quite a few machines. So our biggest bucket was 5,000 or more machines. And that's how most people responded. So a lot of people were in that highest bucket. The ones that were lower are kind of surprisingly evenly spread. So if we end up running a survey like this again, I imagine we might maybe break it up into five to 10,000 and then more than 10,000. So people are running a lot of machines in their Kubernetes environments. For the data center types, most people are running in public cloud, but a lot of people are also running private cloud or on-premises as well for our respondents. A lot fewer running hybrid cloud. And one person wrote in a response, bare middle, cube admin, which I would imagine would probably end up being bucketed with private cloud. But mostly public or private. Hybrid is definitely there, but not as strong as the other two. We also looked at activities, so what people are actually doing with Kubernetes when they're working in it. So the sort of teal blue color is when people are very involved with the item. Red is when they're somewhat involved and orange is when they're not at all involved. So the things that people are most likely to be involved with were working with infrastructure resources, researching, evaluating, purchasing new tech, monitoring and troubleshooting applications, managing deployment pipelines, managing the cloud platform, developing software and architecting software. People were less likely to be involved in working with AI or machine learning systems. And people were kind of just somewhat involved with managing data processes, which I imagine is somewhat aligned with the folks that actually are working more with the AI and ML systems. And for Kubernetes use, it would make sense given who we sampled for this. But people are currently using Kubernetes across proof of concept to production by far and away. So it's kind of interesting that folks don't really give up on the proof of concept. They're still trying out new things within Kubernetes, even when they're running it in production. A lot of people have moved past proof of concept for future plans, which means it might be somewhat more cemented in the way that people are using Kubernetes in their work environments. And so we also looked at what resources people use to learn about Kubernetes. Documentation is very, very strongly in the lead here, but everything else also has a good showing. So these other ones are fairly even, but Twitter is pretty common. This might be a little biased because we did send this out via Twitter. But everything else is, again, pretty even. So people are going everywhere from YouTube to Stack Overflow. A lot of people wrote in other responses, and they were more likely to mention specific resources in those other comments. So maybe like a specific person on YouTube or a specific book or something like that. But documentation is still definitely the leader of where people are going to learn about Kubernetes. And finally, the net promoter score is something we asked about. So you've probably seen one of these multiple times. It's where a company will email you or give you a pop up, and it'll say, how likely are you to recommend our product to a colleague or friend? And then you answer on a scale of zero to 10, 10 being more likely to recommend that product. So this is a really, really common marketing or customer experience measurement to gauge general sentiment towards a brand or product. And it's calculated in this way where if people answer a nine or 10, they're called a promoter. This is our green bucket. Passive is seven or eight. And that's kind of the middle bucket. And then detractor is zero to six. And the way that you calculate this score in the industry standard way is you kind of throw out the passives. You take the percentage of promoters and then you subtract the percentage of detractors and you end up with this percentage score. And so our percentage score that we came up with for Kubernetes is 62.5. And the scale actually goes from negative 100 to positive 100. So this is fairly high. And considering across most industries, this is actually a super, super high NPS score, which is really interesting. We looked in a little bit to see if we could find data around other open source projects that might have been measured in this way. But it doesn't seem to be a very common metric to be used on open source projects. So we don't know if this is relatively high or low compared to other open source projects. But across the board, this is a very, very high score, which shows a lot of engagement from the people that use Kubernetes. And that's it for the data. So I'll give it back to Gabby. Thank you. Cool. Thanks, Carl. And just to wrap up, as far as the next steps for us and the jobs to be done study, right now we're working on setting up user interviews, like we mentioned from the people that responded to the survey. Out of that will come a lot of analysis, going back through responses and extracting out that job map that I showed at the beginning and also understanding what those desired outcomes are. Ultimately, we'll put all of this in a survey and send it out again. And after doing analysis on the results of that survey, we'll be able to generate this very nice opportunity landscape that I talked about in the beginning. So with that, that's pretty much it. Thank you for coming to our talk. And let us know if you have any questions. Yeah, thanks, everybody. And we'd love to have, so all of this data is going to be open sourced. We look forward to sharing it with everyone who's interested. And then if you want to chat more about with us about what we're doing and how you can get engaged, definitely join our Slack channel and check out the Google group and we'd love to chat more. And we're happy to answer any questions people have in the audience now that the chat talks over. Thanks.