Pros and Cons of exec-driven DX

Tamao Nakahara
Tamao Nakahara
DevXcon 2018
4th to 5th June 2018
Dogpatch Studios, San Francisco, USA

It’s great to have an executive-driven DX company, but how does it impact on your other internal stakeholders? Or your community? Tamao Nakahara explains how Weaveworks balanced enthusiasm with concerns as they built and launched their products in this talk from DevXCon San Francisco 2018.

Watch the video

Key takeaways

Takeaways coming soon!

Transcript

I'm sure some of you have experience dealing with certain types of executives who think that developer relations or developer experience is just something that's feel-good community stuff. You're just a cost center. You cost us money. You don't have real metrics. And the worst case they completely dissolve you altogether. I'm sure some of us have either experienced that personally or seen others do that. And I think it's really important to understand that these people aren't doing it because they're stupid or they're evil. But we do have to grow this field and we do have to continue to communicate. And it's something that we have to keep doing. So, that's part of it.

On my end, I joined this company Weaveworks because our CEO is completely DX driven. He completely gets it. And I like the fact that DX was directly under the CEO and that he understood we have a product that reaches out specifically to developers. So you think that everything would be great, and I really have nothing to talk about. But, of course, there are certain aspects of that that I love to share. And again, I will be talking about particular stakeholders in the company with much love and much empathy understanding where they're coming from. But as this is a practitioners conference, I really hope that some of these stories would resonate and be helpful to you.

Our products and our communities

So one of them is, as I mentioned earlier, we have our Weave Cloud product, which is a SaaS product. So this Weave Cloud product, so the origin was that there were four open-source projects that had been created by the teams that then ended up becoming Weaveworks. One was called Weave Net, which helped you do networking. It still helps you do networking of your Kubernetes clusters. One was called Scope, which was sort of the early stages of this nice observability dashboard.

There is a fairly new project called Weave Flux when I joined, which continues delivery automated deployments but it really, really was young. And finally, there is something called Cortex, which if any of you know Prometheus, which is an open-source project for monitoring containers. It was sort of an improved version that helps add features and capabilities to that.

So I've been out of the company for over a year and a half, and at the time being someone who's in community and has done open source, of course, I ask the questions, are there any areas where we should be building out these communities? Are there areas...what are the metrics that we can achieve? And in particular we had just launched this product. And there is this concept that Weave Net had gotten us a lot of credibility for the networking capabilities that it provided. But we didn't have a way to monetize it and we didn't feel that it was a part of the future of the business model. And so one thing was we thought, "Well, let's see what we do. We'll shift gears. We'll just focus a lot of what we have to do with the product."

So one of the things I thought was kind of interesting was I joined. The product had been launched. And literally, it only been like one to two months. And again, I say this with much love of our CEO. But he's running around. He's like, "When people think of Weave, they only think of Weave Net. Why don't they think of Weave Cloud?" I was like, "You just launched this product and it's so completely different from what you'd been representing yourself as." Anyway, we've been moving on along the journey and, in fact, we've also been seeing the value of building out our product, because like I said, there are three open-source projects that kind of went into this and then Weave Net, the networking bit was sort of floating out there. And I was trying to figure out what to do with it. But having a "product" that was generated from different open-source projects meant that there were pieces of the product that weren't really cohesive, and we've really gone and made that happen in really interesting ways where we integrate those pieces.

Open-source ambassadors

But now fast-forward, he's still just like not been more into the Kubernetes community. I would meet people who are just like, "Oh, yeah, I totally know you guys. You guys are amazing." But when they say, "I know Weave," they're still thinking, "I just know Weave Net." They still don't know about our product. So we're trying to find ways to get the word out. So one of the things that I've done and part of my thesis here is, you know, know your users, be creative, and know your internal stakeholders. So one of the things that we're doing is we have a support slack. And most of our support slack, surprise, are questions about Weave Net. It's really not everybody in the company knows how to answer these really detailed networking questions. So it's really a lot of energy that we put out there, but it's what we do.

So one of the things that we found were some people were like, "Look, we'll almost just pay you because we wanna thank you so much for all the support that you offer before we had official sort of Weave Net support." And so another thing that I'm doing is we're gonna kick off some online office hours so that people just have a way to chat with us if people wanna be on Slack or they want to chat with us through video, whatever. And then one thing that they will do is they will sit through a very short Weave Cloud demo in the beginning because we know you may not be our target audience for this product, but you probably know somebody who does. So please, that's another way to show your love. And we can sort of help internal stakeholders as well as help the community by using them as what I call open-source ambassadors to help spread the word.

Competing concerns

So another part of it, as I mentioned, we had this really fledgling product called Weave Flux that was very new when I joined. It served a need, but we're still figuring out where it fit in. And we've noticed that that has actually kind of taken off. And so we've been focusing our attention and talking about how we can do that. That was one of the areas where I said does it make sense at that point maybe to be trying to build a community of users when it's so new and we're not sure where it's going? But now since we've seen stickiness, we thought about doing that. And I don't know. Has anybody heard of the term GitOps? I'm not sure how many people are in this space, but that was something our CEO coined. And it was this concept of using git...like a git repo as your single source of truth, the state of your cluster and to do operations around that. And it kind of like took off. We just had a couple blog posts and it's like really been something that we're seeing within our communities.

And so I said, well, maybe it's time to revisit this concept of building out this community. And in this moment, again, it was a concept where you have many internal stakeholders, and we were all together in our London office. And the CEO sits down. We had this long meeting. He's like, "I'm all about it. Yes, I want to build this open-source community. We're gonna get Flux out there."  I'm thinking, "Well, we still haven't really thought about the strategy yet, but let's see what we can do," because we do have to earn our keep and try to see if there's an upsell strategy to this product, Weave Cloud.

Then the next thing I know the COO is like, "We need to talk." And he says, "I'm very nervous about this concept of the entire developer experience team working on building out this open-source community." I said, "Don't worry. Don't worry. I actually spent all night on a plan and a doc and how we can think of ways to see if there is any kind of upsell, see if there's any interest because there's more features, of course, in the paid product than in open-source. See what the community is about." And so since, of course, we have like all these KPIs that we've already aligned, I tried, identified sort of three small ways that we could at least change the language a little bit in the way that we present ourselves to the outside world.

Understanding the new metrics

So now we have sort of GitOps messaging on our flux GitHub page. We have a feature comparison chart that we're going to put. So if people are thinking about using the open-source bits, at least they are more aware now that there's the paid product in case they want better features. And then we discovered that people who may already be using the open-source Flux and want to upgrade to Weave Cloud, there's actually a little bit of clunkiness to their experience. Of course, we wanna remove the friction first with just better documentation and then second, if we feel it's worth the bandwidth to put some engineering time to it. But that's very TBD.

So with that, again, we had the CEO who's like, "I'm DX minded. I'm all about let's do open-source." We had the COO who says, "I'm very concerned about this and how much it's gonna cost." And then we also had the VP of Marketing who was just like, "Okay, you guys are talking about GitOps, but we don't really see how we fit this into certain types of frameworks in our messaging." So again, I guess the final message is even if you have an executive-driven DX company, you also have many, of course, internal stakeholders with different concerns and different metrics. And, of course, nobody's dumb or stupid or ignorant about it or maybe not ignorant, but maybe they need to be understood. They need to understand what kind of new metrics you can bring in. You can find alignment with that. And so you can both serve a community as we hope to grow this Flux community as well as have a business strategy internally and document it so you know how to communicate it inside.

So with that just quick, be creative. Know your community as your target audience. As we've talked about many times, have empathy and join that with your leadership. So leadership with your internal communication, leadership with your external communication. And final call is, of course, we are hiring. So please see the board over there. We have community managers and dev advocate roles. So we'd love to see people join our team. So, thanks.