Community in a box

Transcript

Speaker 1: My name's Mandy Walls. I'm a, I have a totally different title. I'm a Technical Community Manager for EMEA. So we're based here around the corner in Moorgate for Chef. My handle is LNXTHK.

Speaker 1: You can find me anywhere but Snapchat, because I'm a little old, I think, for Snapchat. I started out with Chef five years ago as a technical evangelist, which at that time meant anything that sales didn't want to do, we had to do, which was a lot of fun. Then I spent three and a half years doing professional services. I ran the team in North America, then came over here to build the team, and what we found was our translation of community and outreach and all those things from North America didn't really translate into the new audience we were finding over here in Europe. So we changed tax.

Speaker 1: I have a different job now. I report both to product and to marketing. So we've got two different bosses who are all in North America and never come over here, which is great. So who is Jeff? We are a Seattle based startup.

Speaker 1: We're about seven, eight years old. We started out in configuration management and systems automation. Very much in the cloud space. We're a big AWS partner. We had a big release at re:Invent last week, all that good stuff.

Speaker 1: We are part of the DevOps community, which if you're not sort of playing in that space, is like this weird, swampy mess of commercial folks and open source folks, and a lot of culture and hugging and weird things that go on. We're kind of in the middle of all that, but over the past several years we've gotten a lot more corporate customers. Some of our big customers are Facebook, Alaska Airlines, which is a regional airline out of Seattle in The US, Disney, parts of Disney use our stuff, and our bigger customer here in our region is actually Standard Bank in South Africa. So we're kind of all over the place, and sort of have to shift gears kind of often to figure out what fits best for what we want to do with all of these customers, and still satisfy our open source community, which is thousands of people. So, our community history, we did start as an open source project.

Speaker 1: It was actually a fork off of another similar project, and life happened completely on IRC in those days, and everything was really much built around our founder, who's currently our CTO, and the stuff that he had been working on. So it gained interest in a very organic way, folks working on similar tasks, the professional relationships that he had with other people doing similar kinds of work. This was still systems administration and early cloud and those sorts of things that were happening at that time. It was very organic. Like I mentioned, our customer base really started to expand and take on a different shape, and it was wider with this sort of DevOps thing, IT modernization that happened, and we had a lot more enterprise customers, folks that had more internal developers than we had people in our entire company times 10.

Speaker 1: So we work with a lot of big banks. We're a two fifty person company. We're working with a business unit that has 20,000 engineers worldwide. So there's a lot of different scale and strange issues that happen there. There was plenty of things that we had to work on from a technology perspective with the product and usability and all those things that fed back into it, but there's also a lot to work on from the organizational standpoint when we're talking to these folks.

Speaker 1: There's a lot of us who are coming in from this warm and fuzzy, very collegial, sort of open source DevOps hugs in unicorn space, and they're sitting in cubicles in New Jersey talking to some other guy in Bangalore, and they've never met face to face and don't really talk unless it's by a ticket or something. So it was a very different culture for us to go in there and figure out what to do with our customers who are completely lacking community. They don't have that structure. They don't have that relationship to each other or even to technology, right? Those large organizations tend towards a lot of specialization.

Speaker 1: They tend towards boundaries. We call them silos. That's sort of the language that's been built out of the DevOps space, where everybody has their own things. They only talk to certain people, and they really only care about a handful of activities that go on, and bugger all to whatever else is going on. So our users ended up being divided up between multiple departments, multiple units.

Speaker 1: They're all over the place geographically, a lot of different language barriers and things like that that were going on with some of these. We also end up being divided up by just how they're going to use our tool. We're working with folks that are trying to do systems automation, but some of our community internally with this customer might be a team that does Unix platform integrations, and another team is doing Java. So they have different requests of us. They have different internal connections, and sort of a completely different frame of reference for what they're doing with our tool, and then we need to sort of take a step back and figure out what the language is to address all these diverse needs just within this one customer.

Speaker 1: So it ends up hindering all of our training capability as we go in, we do a training. If it's all one team, you can see them start to work together, and they're like, oh, we could totally do this, and whatever. If it's 25 random people from all over the country, They've never met before. They don't know what each other is doing. They have no internal relationship, and it stymies their conversations and things that they could then do with the tool.

Speaker 1: So, we're running into these sort of barriers with helping us get adoption and the sophistication of solutions. Folks were reinventing the wheel for every team. We're focusing on trying to reset a bunch of behaviors that we were finding in these customers to pick the best things out of our open source community, and import them into these internal communities. We're trying to counteract a bunch of things, like less exploration of outside ideas. Some of this is related to Some of it's related to budgeting practices.

Speaker 1: Team A buys a thing, and there's like team B is not allowed to touch it because it came out of team A's budget. You're like, but why? You all work together, but not. I also have a lot more politics than we were used to coming in from even open source, which is fraught with politics anyway. Also, less desire for external networking, and this is really hard, I think, for us as practitioners internal to Chef.

Speaker 1: We're all very enthusiastic, engaged technologists. This is really where we have put a lot of our energy on a bunch of our self identity, But when you're working with someone who has been at a bank for twenty five years, they're like, this is a job, man. This is putting my kids through college. I bought a Range Rover. It's awesome.

Speaker 1: Their priorities and the things they want out of their job and the technology and even their relationship to us as a vendor is just like, don't care. I'm gonna sit at my keyboard and get paid either way. Our frameshift on that was, for some of our folks, actually very difficult. It ends up being very frustrating. I also found a lot more reliance on top down and command and control management.

Speaker 1: There's still a lot of work being done in the management space about this IT transformation that's going on, reshoring work, doing more dynamic and team based things versus the command and control management. That's like five years, eight years out for a lot of the folks that we've been talking to. We're missing all these benefits, all this organic community that we were used to working with. Learning from and sharing other people's experiences, not a natural thing in a lot of enterprise organizations. Even commiseration, they have their own people that they could bits with in the lunchroom, and there's not a lot of cross talk there.

Speaker 1: Hoping to reduce duplication of effort and relearning lessons already learned. Also a lot of competition in that, where folks are like, you guys, you did it, but you did it wrong, right? So they have to start over, and those sorts of things. So we put together a framework of tools for our services and success teams. We call this Community in a Box, and it's meant for our team of folks, so there's like 40 folks worldwide that do these kinds of jobs, who are in constant contact with our customers, and helping them sort of bring in all of these happy, fuzzy practices in a way that still works for these enterprise communities, or nascent enterprise communities.

Speaker 1: So a lot of our customers weren't familiar with technical communities in general. Like I mentioned, there's just a different expectation of what it means to be a technologist in different risk environments. Lots of different demographics from our earlier customer base. Not only do they shift a little bit older, they're a little bit more mature, a little bit further on in their careers. Less time and interest in looking outside of the company.

Speaker 1: They know that trying to bring something in is going be fraught with difficulty. They're also prohibited oftentimes from talking to us in the avenues that we are most used to. Chef started out with half a dozen channels on IRC. We now have moved to Slack, and are learning all of the interesting ways that network security is trying to put walls in front of Slack as much as possible, which has been super interesting, but also super frustrating, but they're wily, and they're sneaky, and they continue to do it. Some folks are dissuaded from using open source technologies at all, or they have sort of a white listed preferred vendors list.

Speaker 1: This is where folks like Red Hat have been really powerful in taking that forefront and saying, yes, source is beneficial. It provides you with all these things, and we're here as a company behind it. Looking at putting your enterprise infrastructure on a company that's two fifty people is shaky, so part of the back end ends up being talking to legal and other weird things like that. So we focused on customers already taking part in our customer success program. Customer success is a regular touch point with us.

Speaker 1: We have dedicated engineers on our side that talk to a regular set of customers, and part of what we were then pushing them into are these set of guidelines or this guidance for building these communities and helping us gain a little bit more foothold with our tools. So we had no real We'd hoped what we wanted it to look like, but there's a couple different models that we were sort of working off of. One, of course, being our external community, but also then a couple of others that we had been working with and got input from. So these are some of our customers. Cerner is a healthcare software provider in The US, and they are based in the Midwest, and every year they have a great big huge developer conference.

Speaker 1: I learned on Twitter yesterday that AXA AXA here also is having one in Cologne, so very similar, where they bring all their internal folks in and then have a big party, and our former CTO did the keynote for them a couple of years ago, and we're like, that's really good. We should recommend to other companies that they should do something like this. It's low risk from them. It's all their internal employees, but super beneficial, and helps with the face to face and all the other things that were mentioned earlier. Target, which is a big retailer in North America, well specifically in The US, they're based in Minneapolis, and they built what they call Dojo, and this is like a boot camp almost, where specific teams come in and learn a bunch of things, and then they have contacts, and they build this family of people who have been initialized with the sensei and all this other stuff that happens, and it makes a real good connection for them.

Speaker 1: These are super high resource intensive sort of things that they were doing, both of these companies, to sort of put this together for themselves and for their own success. Finally, Disney, we've been working with them probably the longest, and over time we watched them evolve what they were doing, and we got to pick out the good stuff that they had tried. Different summit events for individual contributors, as well as management, which is super interesting when you're doing DevOps. Lots of internal forums, lots of workshops. All the things that we were still trying to do externally, they were doing internally as well.

Speaker 1: So we're like, oh, that's, yeah, okay. So we can start to pick some of these things. We're seeding inorganic strategies, so we're hoping we're going put this grain of sand in the oyster and get a pearl back from it, and some of the things we were already doing from a sales motion perspective, but we wanted to take it and twist it a quarter turn to get the people stuff back out of it. Some of the things that we help our services and solutions folks do is finding our champions, and these aren't necessarily just the person who bought the stuff. Also talking about particular activities with the customer and their community, setting schedules and communicating and us being available to help them push things through.

Speaker 1: The champions that we were looking for aren't necessarily, like I said, the people who bought our stuff. The person whose name is on the contract isn't always our best contact at an enterprise customer. It might just be some random person in procurement who has legal ability to sign a contract. These can be technical or just managerial folks who have a lot of official or unofficial influence, and picking a good champion or finding the right person is almost an art, and I'm sure you guys have seen this, where there's one person who's maybe very, very enthusiastic, but has absolutely no influence whatsoever, and they like to talk about things and to be present and to give talks and do all this stuff, and people don't believe them at all. Have absolutely no idea that what this person is talking about is legit.

Speaker 1: So we ran into a bunch of those at different places, and you sort of have to, that's great. Who are you working with? Who else are you talking to? Trying to branch out from who that person is. People with enthusiasm, yeah.

Speaker 1: They're awesome, but also not always the best person to pull in for that. We hope to find eventually an ever expanding group of these champions, just like we do externally, right? Where someone is really good at our product on Unix, and they have another person who's good at it on a different platform, that helps us. We pull them in, give them maybe some extra special things, send them some swag. The usual business that we would do with our external customers, we can then focus that effort into a particular customer as well.

Speaker 1: So we work with these folks. They're our point of contact. We try and invite them to our external community, help them build their influence, build their personality externally as well. As many of you know, a lot of this stuff ends up being really good recruiting methodologies for folks not only for us to hire, but also for our customers to hire. So we're talking about sort of blue chip, Fortune 1,000 companies that are trying to compete with the Googles and Facebooks of the world for technical talent, and not everybody is maybe as interesting as WebSphere, but there's lots of folks out there trying to find good technical folks.

Speaker 1: We try to pick activities that are focused on opening communication between groups, between groups of users, individuals, but things that are open for anybody who might be interested in learning about the product. This is something that we found is sort of counterintuitive to what enterprises are currently doing, where people end up being very pigeonholed, or it's like, well you work on that team, and your team does those tools. They're like, well it's a big company. Why can't they learn something to move around and get a better job or do something different? A lot of external communities, we use a lot of meetups, social channels, so we borrow some of that stuff as much as possible.

Speaker 1: A big one that we try to push that sort of really works is a lunch and learn, and sometimes there's bribery involved. You put some sandwiches out and some chips, and people are going to come and listen to talk about your tool. That's just sort of the way it happens, because they love free food, and why wouldn't you? For $25 $50 for a little bit of catering, you get 10 people in a room to talk about something cool you did last week. Another good one for some of our larger customers is just a demo day, and we do this with our own products.

Speaker 1: It's just like, all right, we're going to spend an hour showing everybody what we did and hope that it gets questions, it gets ideas, and expands the reach of the things that we're doing. Also taking advantage of whatever internal tools they already have. The blocking of Slack and the blocking of IRCs, a barrier between us and the customer, but not necessarily for their internal community, So whether they're on Exchange or Lotus Notes or whatever other crazy enterprise mailing thing they might have, there's always some kind of group function mailing lists at the very least. But also some have internal chat systems that we weren't even necessarily aware of, having never worked in that sort of environment. There's lots of things that we try to push them towards doing, which is sort of weird, because you find a developer would be like, I don't want to own the mailing list.

Speaker 1: You have to sign a form. Like, really? What? It's 2016, you have to sign a form to get a mail Oh, whatever. Okay, fine.

Speaker 1: Super weird. Internal DevOps days, showcases, developer conferences for bigger customers, these are super awesome, because nothing a manager or director likes better than showing off all their stuff. They get a big day with some fanfare and some beers, and that's great. If they can spend the money and the resources, that's a good showcase. It's a good way for them to brag about what they're doing, but also a good way for us to sneak in the back door with a banner and some swag.

Speaker 1: We try to help them keep their schedules as active as possible, just like we do with our meetups. Scheduling things, getting speakers, all that kind of stuff internally is just as difficult as it is for us out here in the other world. So sometimes we will go in and be their speaker. So it helps us get the talks out. Maybe we'll invite some other customer who happens to be in the neighborhood, in the region, who might have something interesting to share.

Speaker 1: So we can help facilitate that over time as well. Even if they're just meeting once a month or every two weeks just to talk and kibbitz and share some donuts or whatever, it's still a good All that face to face continues to build everything. As a company, we do a lot of these events. 15, I think I'm at 30 this year. I have two more before the end of the year.

Speaker 1: We do a lot of this stuff. We don't feel sorry for you. No, absolutely not. I've totally volunteered for this, and my mom's like, Where are you this week? I'm like, I'm not going to tell you because you don't want to know where I am.

Speaker 1: A number of our events end up being focused on a single customer. They have a dedicated account person, and that person might be on-site with them once a quarter for a showcase or lunch and learn or any of those kinds of things. We're actually putting some additional resources into these kinds of activities as well. Why did we do this? Why did we decide that we have these folks that normally would be in the field collecting dollars, right?

Speaker 1: Turn the crank and the dollars come out, because we bill in dollars. We put these folks out in these things. Part of what we do, the marketing and product side that I report to you, it's like trying to get expansion in account retention in some of our larger customers. When you're dealing with a large bank, we're talking to one business unit. There might be 12 others.

Speaker 1: We're talking to North America, but they might have subdivisions in lots of other countries that have different needs, different requirements, different hosting, things that we can then expand into. So we want to have that kind of traction, and help them build better solutions that then expand into all of those things. We also use them for marketing. The better relationship we have with the customer, then that goes up on our website too. So it's recruiting both ways for that kind of relationship, and we hope that that benefits them as being a cool place to work, even though they look like a bank.

Speaker 1: You sort of take off the case, and there's cool stuff going on underneath it. We also look for, I collect people. That's kind of what we do. And we're always looking for interesting people who are in these places, and maybe they're stuck. Maybe they're ready to come do something else.

Speaker 1: Maybe they're ready to come take my job, I'll go to South America or something. So all of these interesting things sort of pop out of it. It's been really cool. We've been doing this. It really started bubbling up about a year ago, after Target's dojo thing sort of hit, and it's starting to give us a Once you do it more, you get more practice at it, and all those good things, but it's been super interesting for us that way.

Speaker 1: A little bit about us, if you're interested, if you play in our space, if you're into DevOps, I'm sure we'll see you at some point. Anybody going to Tel Aviv next week, right? We are chef.io. We are on Slack, despite everybody not wanting to be on Slack, and we keep a bunch of our events on the blog. It was really great.

Speaker 1: I'm hoping to learn a lot from the rest of the day, since this is sort of my first foray into this sort of environment. Thanks very much, and have a great day.