Building developer experience for Weave Cloud

Transcript

Speaker 1: I'm going to talk a little bit about how we work on developer experience at Weaveworks. It's a little bit of sort of company context, so you know where I'm coming from. Weaveworks is a fairly small start up based in London. Got an office in San Francisco, an office in Berlin. We're about 30 people or so.

Speaker 1: And we build developer tools for DevOps teams that are using containers and microservices. Our product is, or our our products and and tools that we're that we're building sort of come in two flavors. There's Weave Cloud, which is delivered as a software as a service, which is really an add on for open source container orchestration for people using Docker, and it provides troubleshooting, continuous delivery, monitoring, networking, and security. The way it does that is by sort of wrapping up all of the different open source pieces that we also develop. Everything we do is open source, and so there are four open source projects that correspond with those pieces: Net, Scope, Flux, and Cortex.

Speaker 1: This really isn't meant to be a product pitch. I'm going to go into talking about how those different pieces affect the way that we we build the developer experience for all of those things. So so within that context, small company building developer tools, The first thing that we did was to identify, like, who the audience is. So the first step was trying to identify our persona, and, I decided to name them Bjorn. They work in a Swedish web agency.

Speaker 1: They're a full stack developer on a DevOps team, and they're developing an app for a big client. Let's suppose it's a sock shop. Maybe they're the Amazon of socks for Sweden. So this persona is a full stack developer, sort of has a foot in both worlds of running a front end team and also responsible for deployment of that SOX application for that company, which is maybe a bit of an odd sort of lumping together of two roles, but you'll see why in a minute. So I'll show you in a minute.

Speaker 1: I'll show you now sort of the so this diagram, a little bit complicated, sort of shows the and it and it goes between these four slides like this, so like that. So I'll I'll I'll show you the different bits. The first one, and this is sort of the the whole joined up story that we're trying to show people through the developer experience. The first bit is that you can boot up your app on on your laptop, and then you can boot up a production, container stack, and you can use scope to visualize your application in the same way across both of those environments. So so that's the first bit.

Speaker 1: Then Flux is about deployment. It's about continuous delivery. So it's about users or developers being able to take, changes to their app that they make on their laptop and push them through this, continuous integration and continuous delivery pipeline. And so Flux is a tool that helps with the final bit of that. It gets the output of your CI system into your container orchestrator and then into your, which is your production system.

Speaker 1: Then we have this thing called Cortex, which is about monitoring that application. And finally, we have this thing called WeaveNet, which actually, if you noticed, was in there all along, sort of hiding in there as a a component of the production stack, which is a networking component for connecting containers together. And and so using that Weave Cloud, you can then add security to your app. So the challenge with this fairly complicated story that we're trying to articulate is trying to make the developer experience excellent for all of these different use cases, trying to make it appear simple when there's actually several different lots of different moving parts, yeah, trying to trying to get users excited about it and enthused and and get feedback from them so we can feed that back to the product team. So speaking of which, we're fortunate enough that Weaveworks to be to have a company structure which puts developer experience at the top level in the organization.

Speaker 1: It's a top level team, my team. It's a top level team that sits alongside marketing, product, and engineering as peers. This makes sense for Weaveworks because the whole sort of go to market motion for the company is to build a grassroots community of developers who use our technology, and that they'll eventually start using the services we provide as well and evangelize for us, and and so that's how we plan to be successful as a business. So the DX team is broadly responsible for ensuring that developers using our stuff have a good time. This, of course, interacts with marketing, because marketing do digital demand generation.

Speaker 1: They do advertising campaigns. They run events and conferences. And so their job is sort of getting the users to, like, start seeing what we're doing, like, in the door. Then it, of course, interacts with product because the the DX team speaks directly with so many users, and so we have feedback from those users on what works well, what's unclear, features that could be added, and so on. And then we also collaborate with engineering because an important part of what we do is to do real work in open source communities.

Speaker 1: So we actually contribute code as well to some open source projects, and I'll talk about that a little bit more in a minute. And of course, we collaborate with engineers on content as well. So for example, I was talking to Brian, who's one of our engineers on the Net team, just the other day about how we're going to make an argument for hybrid cloud in a blog post that we're working on and that sort of thing. So so what we do as a team, and this is the team, there's only four of us. That's, Tamo in San Francisco up there, Ilya in London, Anita who's in Mexico, and myself.

Speaker 1: And so between between this team, we are trying to maximize the number of happy users, either using the cloud platform, or the open source products. And we do that in a couple of different venues. We do it online where we we try and make sure that the user journeys are great when you come to our website, when you look when you hear about us from some other open source community perhaps. Then there are touch points, when users will read our guides, they'll look at our catacoders. I'll talk about what catacoders are in a minute.

Speaker 1: They will look at the in app documentation, and we need to make sure that all sort of lines up and it works together. Like I said, we also work online in open source communities, and sometimes that spills over into real life. And in real life, we speak at meetups and conferences, and we try and meet users where they are. Sometimes we go to their offices and learn about what their problems are and things like that. So I talked a bit about user journeys.

Speaker 1: I just threw this together. This is the way we think about developers coming to learn about our stuff is at different stages. So they start out in a discovery stage, education, engagement, and then hopefully happy user, or of course, they drop off and go away because we didn't show them something interesting. And I won't go through every single piece of this, but the point of this slide was really just meant to be that there are lots of different paths that users can take through these different things that we work on. So they might come in through organic search onto our blog, we want to provide them with some interesting content, maybe link them to a guide or a catacoder, again, I'll talk about what those are in a second, that eventually get them to become an open source user or or a Weave Cloud user.

Speaker 1: We might want them to try our stuff and sign up, and then later get a nice email from us saying, hey, would you like to join a free training session? We're just starting to do free training sessions. We think that this is going be a really useful way of getting people in an online context to take the next step beyond signing up and actually get involved in what we're doing and see the value for themselves. They might end up on our Slack channel. We're trying to cultivate a community on Slack and so on.

Speaker 1: And so ultimately, we hope that users will start using this stuff for their own applications, that they'll join our user groups, that they'll give us feedback, and that we can tie that back into a sort of virtuous cycle. Okay. So next slide I've got here is about our sample app. So we I talked I mentioned the Sock Shop earlier. Right?

Speaker 1: So so the Sock Shop actually is a sample app that we built that we use consistently through all our material. And it's really useful because developers are often trying to build applications using microservices. That's sort of part of the whole movement around containers. And so we decided to build a sort of best practice microservices app that we could say, like, if if you if you're not doing microservices yet, you can learn about how to do it. You can look at this as an example, and we can use this as something you deploy for real.

Speaker 1: And so I'll actually show you that later in a minute. Another tool that we used, I keep mentioning this, Catacoda. This is really awesome. It's run by a friend of mine, Ben Hall, who's here in London, and, it's an interactive online learning environment. So, you know, I mentioned that that with developer tools, a lot of the interactions with our tools are through the command line.

Speaker 1: So and and one of the problems is that it often takes quite a lot of setup and, like, putting things in the right place and joining them up before you actually get to the good bit of seeing what our thing does and seeing how it can give you some value. So, CataCoda sets an environment up in advance, drops the user straight into an environment, and gives them a terminal in the browser that they can use and some, some guided instructions on the left hand side to see the value straight away. So, I think this is a really nice way to minimize time to value. And so, this idea of time to value is how quickly can a new user actually see something that they think is gonna help them. Okay.

Speaker 1: So that's my little pitch for Catercoder. Go try it out. It's well worth it. I'm sure Ben would like some more, people giving him feedback on on his product. So I'll give you a case study just quickly of, with Flux.

Speaker 1: So I talked about Flux in that early diagram, being this this this thing that helps you do continuous delivery. So it connects the output of a CI system into Kubernetes. So if users are using Kubernetes, it's a container orchestration framework, and they want to have a CI pipeline so that when people make changes to their app, they can automatically get deployed in Kubernetes. So this is a little diagram I wrote in a doc the other day, which is like, these are all the different pieces that you need to actually experience the value of Flux. You need a developer's laptop pushing to version control, CI system pushing to a container registry, and then Flux does its magic, pushes its config to, another version control place, and also pushes the config into Kubernetes.

Speaker 1: So the problem was that, users having to wanting to try out Flux would have to have all of these things, and they'd have to have all these things in a place that they can easily experiment with them. So so that's kinda tricky, but Flux really help oh, sorry. Catacoda really helps with that because we can set it up in advance. So the user gets dropped straight into this environment where they're sort of test driving the application. And they get given some context, and then they have an applicate then they have a terminal that they can use directly there in the browser.

Speaker 1: So we can see like, we can run click here to run this command, and we immediately see, oh, I already have a Kubernetes cluster running. That's interesting. Okay. I can see that if I click if I run get pods, then I already have a Flux agent deployed in my cluster, and I can set its config file and have a look at its config file. So this is how Flux talks to the version control system, and this is how Flux talks to the container registry.

Speaker 1: And so they can then run these commands, they'll see that their application is up and running. So I won't go through the entire tutorial because I'm a bit short on time, but I just wanted to point out that Catercoder is a great way of getting people that really fast time to value on what they're playing with. So next up, of course, after the Catercoders are our long form guides. So let's just go back to this user journeys section here for a second. We put I put CataCoda in the user journey sort of earlier on in the life cycle of the user's adoption journey, for lack of a better phrase.

Speaker 1: So because it requires less commitment. You can go to our site, you can try the catacoder, you can see it, you can feel it, you can hack around on the terminal and poke around inside the VM. But once once you're done with the catacoder, that that environment evaporates within minutes of closing the browser tab. So so it's not permanent. The next step after the Cata Coda is for the users to to actually try and deploy it themselves.

Speaker 1: And so that's where the long form guides come in, and these are sort of by definition longer. It's how to deploy it on your own own infrastructure, And users are gonna be happy to shave some yaks when they're doing this, assuming that they've already tried the CataCoder and they've had a good time. So they're like, okay. This is actually seriously worth looking into. Maybe they've gone to their boss and they've said, sure, like, you and Jim or whoever can try this for a couple of days and and so on.

Speaker 1: So the important thing for the guides, of course, and this is just basic documentation stuff, is that they have to be clear and well tested. So that's something else we're responsible for. This is my favorite one. We like I say, we directly get involved in open source projects as well. We get lots of love from the open source communities for helping improve and organize things.

Speaker 1: This also gives us access to lots of users, which is fine. Like, it's great to be able to just talk to them on Slack. Like, people try out the things we're working on in open source. They get feedback. We learn about what they're working on.

Speaker 1: I had a fantastic conversation, for example, with a guy called Mike from Ocado, and I learned all about how Ocado's robots are really awesome, and I'll tell you about them later. But and and they're using Kubernetes, and and they have all they have relevant problems, but we only met because we were we were in this, you know, in this open source community together. And of course, we get to write code, which is nice because developer experience people are and should be engineers, and it's great for those people to get a chance to write some code sometimes. So the case study for that is where we got involved, got actively involved in Kubernetes. The problem that was on the table was that Kubernetes was really hard to install, which is a developer experience problem.

Speaker 1: And so we collaborated with the community in this thing called, SIG cluster life cycle, that little sidebar on Kubernetes community. It's it's described as a SIG tater ship, and SIGs are special interest groups. So the entire project is based around these, subsets of, the community working on special on on different areas. And so I I took the lead with SIG cluster life cycle, and and and we we got involved. We got organized.

Speaker 1: We decided to, develop, these tools called kubeadmin init and kubeadmin join that would make it as simple as running these two commands on some machines to create a new Kubernetes cluster. And as and and while we went along with that process and and drove that project, in in the open source community, we also worked with the Net team, in the engineering team at Weave to make sure that installing Weave Net on Kubernetes was equally simple. So that became as simple as kubectl apply minus f git dot a o slash weave cube, which is a bit of a mouthful, but it fits on a slide, which is better than it was before. Of course, we also needed an excellent guide as part of the Kubernetes docs. And after we launched this project, and got lots of love from everyone, we also helped out on Kubernetes Slack and, and supported those people, supported the users who actually were flooding in.

Speaker 1: At the peak after we after the Kubernetes one point four announcement, we had maybe 20 people a day trying it out and giving us feedback in in the Kubernetes Slack channel. And so that was a great resource for us, because we can build relationships with those people. Okay. A few more things. A little bit about user testing.

Speaker 1: So this is user testing the bad way, and this is how we, this is how we're currently doing a little bit of user testing on those guides I mentioned. They're all fairly new. It's fairly fresh content. So I I went to Ilya, who's my colleague I showed you the picture of earlier, and I said, okay. Can you can you just completely clear your mind of everything Weaveworks, become completely zen, and then try and use our stuff like a new user.

Speaker 1: And I did this on a on a Zoom meeting so that I could record it, which is really useful. And and so he did. He pretended to be a new user, and he clicked around and clicked around on the guides. And and he got he he said to me a few times, Luke, I'm a really confused user, and and and fair enough. So there we we this was a great sort of way of doing a first pass through these guides, through the catercoders and the long form tutorials, and and finding those really obvious things that weren't obvious perhaps when you were writing them, but were obvious when you actually put yourself in the position of a user and try and run through it.

Speaker 1: So this was sort of the way of doing the first pass. What we're gonna do next in the new year, which we haven't started doing yet, is actually do user testing on real external users who aren't just Ilia pretending to be a new user. And so we're working on this. And any volunteers, please send me an email. We'd love to spend some time on a Zoom meeting testing our stuff with you.

Speaker 1: Okay. Next slide, I just wanted to touch for a second on customer development. So I think this is an essential skill for for people in the in the DX team. I think it's, it's also an essential skill when you're building a start up. It the idea of customer development is that when you go and talk to people about your product, they will probably lie to you.

Speaker 1: And I point I point to this book, which is called the mum test or the mom test. It's American, which, talks about yeah. It's this idea that if if you ask your your if you ask someone who who loves you, should I do this startup idea? They'll probably say, yes. That sounds like a lovely idea.

Speaker 1: Even if they're thinking in their head, like, that'll never work, but, like, I I like my child, so I'll be nice to them. And this is the the the problem here is that human nature is to be polite. I mean, in Britain, but all over the world. If someone comes to you and says, hey, I'm working on this great new container orchestration thing. It does blah blah blah blah blah.

Speaker 1: They'll probably say, oh, great. Great. Yeah. That's awesome. Really cool.

Speaker 1: And shake your hand. Take your business card. And maybe they thought it was stupid, but they didn't tell you. So and and this is so so this is a a key skill. It's something where I work closely with Stuart, who's, our VP of product, to interview new users, and this is separate from some of the other interactions because we've the the trick is do not tell the user anything about what you're working on really, at least for the first three quarters of the meeting, because it's kind of like archaeology.

Speaker 1: You want to you can direct them with your questioning to learn about their business. And by the way, people love being asked about what they're working on. So, yeah, you can talk to people. You can do archaeology on their business environment, their problems, and this way, you can find out what the real pain points are that can give feedback to to product to figure out what the best new feature is or the best new product is that you should build. We've just started these free training sessions.

Speaker 1: That's one way of building community. I'll let you know how they go. This is just taking users through the catacoders. They follow along in their browser and feed that back into product. And where we need to improve, I think, is more measurement.

Speaker 1: We currently have lots of bits of the business measuring different things in different ways, and we're going through the and that's kind of crazy for a 30 person start up, so we're start we're starting a project to get all of this measurement happening in a consistent way across all the different teams in AppDocs and more external user testing. So thank you very much.