Jenny Wanger heads the DevEx Rockstars at Arrity. In this talk, recorded at DevXcon San Francisco 2017, she describes the challenges unique to developer experience in enterprise companies.

Transcript

Hi, everybody. So I know I’ve got the tough spot of being between you all and food, but hopefully, this will be interesting enough that we can keep going. So I wanna start just by setting some level-setting about what I mean by Enterprise. What I’m talking about here is a company that has been around for a long time. So that means that it’s not digital first and that means that they, you know, are maybe not so used to APIs. They’re not so used to, you know, these new technologies. What it also means by Enterprise is that it is large. I sort of think a small enterprise is probably 2,000, 3,000 people, and then you get up into the hundreds of thousands of employees at these places.

So they’re really a different beast than your newer companies, your smaller startups. And, maybe, can I just get a sense of who here works for an enterprise because you’ll probably empathize? Who here already has enterprise customers? So you guys already know everything I’m about to say. And who here is looking to maybe land that first big customer and is hoping that I’m gonna give you all the wisdom you need in order to do so? Great, thank you for being here.

But yeah. So what do I know about enterprises? The click…there we go. I’m at Arity. We are a very strange place in that we are a corporate spin off and we’re now a startup. So we come out of Allstate Insurance, which is an enterprise with 35,000 employees. At Arity, we have 230. We took a couple of APIs that Allstate had developed and are now productizing them and moving them out into the market. And it’s a pretty complicated product. So what we do is mobile telematics which means taking data that people send us from their phones or from their devices. They choose to upload it into our servers, and then the company hooks into their back-end into our APIs, they get a score. And so the onboarding process is pretty complicated. It’s got a bunch of different steps and all that kind of thing. Allstate, of course, one of the largest insurers in the United States. They have been around for 90 years. They have helped us out a lot because we’ve gotten their data. And as this person in developer relations, I’m really living between the two worlds of startup and enterprise.

And our customers include Allstate, which is our biggest one. We also have Esurance and Answer Financial in the insurance space. And then we’re also doing the developer relations for Allstate roadside services, which means that we’re also interfacing with some of their customers like T-Mobile, GM, that kind of thing.

So why go after the enterprises? They are a great catch and here’s three main reasons why it’s worth going after these big companies. First off, the credibility, right? Everybody loves to have, you know, the logo on their website saying how great they are, what they’re talking about. And to have that stamp of belief on what they’re doing. The second piece is the scale, right? These large enterprises have a huge number of employees because they have a huge number of customers. We are currently in talks with one enterprise that if we sign them they’ll be adding six to eight million daily active users with their one install. So it’s a very different way to scale than going after a whole bunch of smaller places where you’re getting maybe 1,000 here and 50,000 there and 100,000 there, very different kind of business model.

And the final reason that enterprises are really a great place to start is a lot of them are on the Fortune 500 list. It’s called the Fortune 500 list and that’s obviously a good business to be going after. So with that, I have discovered doing enterprise developer relations that this is really a different world. My developer community is measured in the dozens because we’ve got only a small number of these high-value clients. And so I’m not going out and doing hackathons, right? There’s not going to be a lot of people using stack overflow.

On top of that, these are kind of secretive companies where they’re a little bit worried that if they are out there saying, “I’ve got problems or I’m trying to figure out how to do this with your API,” that they’re worried how that looks to their brand. And so they don’t wanna really be going out and being so public with their questions, with their support. And it’s a different thing to be a reference customer than to be an active community member.

And so I’ve really been thinking a lot about how it is that you develop a new strategy for enterprise instead of for these, you know, easier to communicate with communities. And the first thing, the first big lesson from this is about the kind of service that developers are expecting when they work for an enterprise. So think about the other vendors they’re used to working with, right? You’ve got Microsoft and IBM and Accenture. And these are companies where they have an entire account management team, they’ve got sales staff, you have your technical account manager, you’ve got your account executive, you’ve got your onboarding plans, you’ve got all sorts of resources. They expect to be able to pick up the phone and call somebody and get an answer right away. So we don’t provide them with passive service as a DevEx team, right? We are trying to be really active with them.

So one of the ways we do this is with our monitoring. It’s not a thing where we just put something up and we say, “Hey, you can check the monitors and see if there’s any…you know, if you’re getting some slow responses, just go and check.” Instead, we have to be able to call them and let them know, “Hey, just so you know, this is down, here’s how we’re working to fix it, and we really appreciate you. Thank you so much.” If we try and be passive, then they get…we’ve gotten some angry phone calls. We’ve had to learn that lesson the hard way. Another thing with this is that DevEx really becomes a lot more about that whole team because these customers do want the onboarding plan. They do want that implementation strategy. It’s not just…you know, they don’t care if your docs are really great. They still want to have the pro services to go with it.

So DevEx really becomes one piece in the entire relationship process. The second thing is that big boats turn slowly and so our sales cycle is usually 6 to 18 months. And this really changes how DevEx fits into the entire flow of the experience. So what I mean here is that, for instance, when we were assigning a new customer, we had our initial couple of sales talks with them, then we didn’t hear anything for a while. They weren’t really doing any meetings. We were wondering what’s going on and then we see, “Oh look, somebody’s come onto the website, they’re looking at our stuff,” and so that gave us the opportunity then as DevEx to notify the sales team, “Hey, we’ve seen some movement from them. You should reach out again.” We reached out. We discovered that it was the CIO of this enterprise who had been looking at our docs to figure out whether this was actually a valid company to invest in or not, right? Did they want to actually partner with us or not?

And so being able to handle that slower sales cycle means that the responsibilities you have throughout it are actually much more varied because it’s not a quick send. You know, it’s not about creating the email drip campaign, “Thanks so much for signing up, get started.” It’s more, “Thanks so much for signing up,” and then making sure that the sales team actually has the tools they need in order to continue to close that deal. And I guess I’ll add to this, right? With the CIO coming to our website that we’ve got different personas that we’re not just trying to serve the straight up developer persona.

In these enterprises, and sorry to the first speaker, what we’ve found with our customers is that the developer who was actually coding does not have a lot of influence. There’re a couple levels removed. And so we have to make sure that our docs are able to talk to that person who’s down on the ground doing the work but also to be able to talk to the decision-makers who are up top.

Another lesson that we’ve learned in doing enterprise DX is that they’ve got really complicated equipment. These are companies where when they installed their mainframes they were cutting edge. And they then moved on from there to install more and more technology and at this point is… I had one person who described it to me as a giant spaghetti monster. Right? You’ve got systems integrating with older systems, integrating with newer systems, and now they’re coming to us and they’re saying, “Hey, APIs, cloud, right? All the same thing and we can do stuff with you that’s really cool.” And we’re like, “Yes, we are cloud-based. That’s great. We would love to work with you.” And then they say, “Can you send us the SoapUI projects to help us get started?”

And we have Postman Collections and we have tutorials and we have all this stuff but they ask for something like that and we say yes. We have to be able to speak in their language. Also with this is thinking about the fact that those developers who are using the tools that you’re designing started by being maybe mainframe administrators or infrastructure engineers, right? They’ve got a background that isn’t all about the latest and greatest technologies. Back to what Donnie had mentioned also about the 9 to 5 engineers, you’re seeing a lot of those at these companies.

So you have to make sure that you are really aware of what they need. Sometimes it’s a different kind of explanation about what’s going on about how to use your things. We’ve had some implementation challenges in the past because of this gap. And so we’ve learned really also to be able to say to our customer, “Hey, we think that for this technology we would really like to send somebody to your site to help you implement. We think that this is going to be better if you have our support.” And you really have to look at it as a partnership, not as a consumption of your APIs.

On top of this, because of these complicated technologies that they’ve got because of these tangles, were getting a lot of different questions about what we do. It’s not necessarily just, “Oh, these are our capabilities. It’s really cool. Get started.” It’s about security. For Allstate, for instance, they wanted to know how we were transmitting our data for our API gateway into our back edge. And I think we were using SSL encryption at the time, and they said, “Oh, but that’s not secure for us. We don’t like that. Can you upgrade to VPN?” And, you know, they are getting into the nitty-gritty of our technology at that level. It is really about…because, for them, a security breach, even if it’s with a vendor, is a disaster. So you need to make sure that your equipment, that your setup, is really going to hit the priorities that they care about, right? They wanna know about integration.

Stability is not about 9-9s, it’s about 6-9s. They’re also asking us at the API, like, what’s the business value of us partnering with and AP-…with, like, using APIs, consuming APIs. It’s very different questions, I think, than what you get when it’s more about, “Oh, these are our capabilities and we’re really good at doing our core competency.” It’s about these added things that they have their concerns about.

And finally, enterprises, as I said, they’re huge, right? So one of my favorite stories is that we have been, you know, improving our SDK and fixing bugs. And so we’ve been versioning it and I think we’re now at 1.12 and we had this customer on board at maybe 1.5 or 1.6. And they keep complaining about the bugs. And then we say, “Well, we fixed those, and like that bug we fixed in 1.7 and that bug we fixed three versions ago.” And you need to upgrade the SDK. And they said, “Oh, well, the thing is that we’ve worked with our resource manager.” And that, by the way, is the person at the enterprise who decides which engineers are going to be working on which projects next. And she said that the next available slot we have to upgrade the SDK is in January of 2018.

So you really have to think about the way that these companies work. A lot of them are also in a waterfall, right, where you’ve got this flow of give us your specs, give us your docs. We will integrate that into our plans. We will then code it out and then we will have this be done and so it will take several months. What this means for DevEx is that we actually become the center of release management as well in a way that despite…you know, we’ve got our engineers and they’re all like, “Oh, we’re CICD. This is great. Like we’re gonna release everything all the time and upgrade and it’s gonna be wonderful.” And we have to go, hold on a second because that’s not actually what our customers are ready to handle. How can we do this in a way that still gets those changes out, gets things moving, but doesn’t end up with something where we’ve got a customer that needs to do an upgrade in six months. And we have to, you know, we’re now too many versions ahead of them or we’re now creating problems for them because of these changes that are happening.

So it’s this fine balance between keeping things moving but also making sure that everybody in the organization understands what exactly the challenges are that you’re facing. So with the DevEx Rockstars, which is the name of my team, hint, if you’re ever in an enterprise, brand your internal team so that people know a little and they can like explain what you do. Because DevEx is really something where, you know, a lot of people coming out of Allstate were not really familiar with it. So we went and got a logo. But we really viewed DevEx as a hub.

So what we’re doing, right, we’re creating those tools for the sales managers to know what their customers are doing. We are helping the product teams really understand how it is that their products are being consumed by this specific group of users. We are working with support to help them understand what SLAs are expected of these enterprise customers who are used to, again, being able to pick up that phone. If there’s, you know, a high-level problem, one of my customers told me, “Oh, well, usually if there’s a problem with our Microsoft thing, if it’s production-level, we’ll pick up the phone and get somebody back to us in 15 minutes.” It’s a really hard SLA to meet.

We work with marketing to explain to them how to talk to developers as opposed to how to talk to the business owners who are on the other side of that IT versus the business fence. And it’s a really different role for us. It’s not about that outbound marketing as much. It’s not about that tutorials and hackathons. It’s really about supporting all the other teams that interact with developers, helping make sure they understand what is going on with our users.

And so, for that, you know, our team at this point is still pretty small, but we’ve got myself in product management, we’ve got two people running our developer portal and doing the website. We have an API champion who is really this person who is helping coach the product teams and helping with a lot of the technical implementation part of having people think through how to make sure that the product is enterprise-friendly. We’ve got some API administrators who are also helping create these and actually build out the tools. And then I also consider my UX partners to be absolutely critical on my team because a lot of these insights would never have been able to be found without their help. And I can’t say enough strong, wonderful things about having UX on your team.

So are you ready? You can absolutely go after the enterprise from a canoe. Go for it, but just make sure that you actually have thought through all these different needs. Enterprises are very, very skeptical of smaller companies. They want to make sure that if they’re choosing to partner with a vendor that the vendor is going to be able to support them in every way that they need. So you need to be able to convince them that you’ve thought about all of these things before you actually go out and sell.

And so, just to summarize, right, enterprising is make sure that you’ve got the ability to give them the high quality of service that they’re used to. Concierge, white glove, not self-service. Be patient because they move really slowly. And just because you haven’t heard anything in a while doesn’t mean you’re off the list. And also remember that this is a monitory patience as well, right? If you’re doing a long sale cycle, how does that change your business?

Account for their technology stack. Make sure that you are thinking through the challenges that they face, specifically with having this multi-layered technology stack and how that changes the way that you present your products and your tools. And, finally, make sure that your change management and your release cycles are really done deliberately in a way that they’re going to be able to embrace and not a way that’s going to scare them off.

So thank you guys very much, I appreciate you being here, and if you’ve got any questions, please do let me know.