Lessons from the fires on Mount Zoom!

Benjamin Dean
Benjamin Dean
DevRelCon Earth 2020
30th to 10th June 2020
Online

Having worked in developer relations for eight years, Benjamin Dean felt confident in his experience in the profession. Then, not long after joining Zoom to build their DevRel programme, coronavirus changed the world and thrust Zoom into the lives of billions of people.

Here Benjamin shares how his team not only survived but thrived during an intense growth spike, including what worked, what failed, and the biggest lessons they learned.

Watch the talk

Key takeaways

Takeaways coming soon!

Transcript

Benjamin Dean: Hello. My name is Benjamin Dean. I'm the now platform, product manager for Zoom. For the past two years, I've been the principal developer advocate for Zoom, and it's been a heck of a ride with Zoom. And today, I'm here to present with you some of the lessons from the Zoom developer program that we've learned through throughout all this, not not just past few months, but not the past couple years as well.

So in case you're not familiar, Zoom has a marketplace. It's at marketplace.zoom.us. And that this is a marketplace as our central hub for all the published apps that our third party developers, build as well as our customers and ourselves. It's a place where our our customers know that they can trust the applications that are there to be to help drive their business. We've seen growth over the past couple years since we first launched, in 2018.

Really solid growth. Just even before 2020, we've seen really solid growth. You know, by the 2019, we were already at 200 apps. But then, you know, 2020 happened, and we we doubled in size in in in the within six months, actually, two and a half times the size. And then even in the last past month, the past thirty days or so, we we've we've added another 100 Appstar to to marketplace.

So we're we're up just over 600 apps right now. And all this, of course, is built on the Zoom platform. The Zoom platform powers marketplace. It also powers our products. And this is this is where developers come into play, and the DevRel piece really comes into shine.

You know, who the people who are using marketplace and our developer platform, it it's important to know who they are. Right? You have to know who your audience is. The biggest lesson that we learned is making sure we understand who our audience is it is and keeping them in focus. So we have our customers.

We have our customer developers. So that would be we've got customers who don't have developers. Right? They're gonna be the people who consume the apps on marketplace. We've got the our customer developers.

Those are typically, like, technology startups or more advanced or larger sized businesses that have developers on staff to build apps for the to power their own business needs. And we've got our marketplace developers who or third party developers who builds specifically to publish apps on marketplace. And, of course, we have our ISV partners, people who integrate the Zoom experience deeply into their applications. So one of the things just over the first the 2020, as you all know, has been pretty explosive. There there's been a lot of sleepless nights for folks at Zoom, but it's it's all done out of a passion and love for our customers and our company.

We keep our customers at focus. We care about them. You know, you may have heard about our company in the news once or twice about you know, or may maybe even you've used Zoom. But we've we've seen, you know, explosive growth, you know, unprecedented. I've I've worked at a handful of companies, lot of large enterprises helping to lift off platforms, and I've I've I've never seen growth like what's happened in 2020.

You know, to see see see the numbers that we have posted here is has been both a kiss and a punch. It's been a blessing and a curse. So it's it's wonderful to have that kind of growth. It's also like, you know, oh my god, growth. You know, you feel overwhelmed with what's coming at you.

The volume of requests start to massively ramp up. Your queue becomes backlogged. You you start feeling like there's there's no light at the end of the tunnel, when when you first go into this. You know, you you're champion. You're running with this, with the scale and the demand of what's happening, but you don't realize that there is a light at the end of the tunnel.

It's just becoming the new normal, that that this is starting to show itself as the new normal to us. Throughout all this, Zoom has been able to keep the lights on. It's been pretty impressive. You know, I've I've really enjoyed working with the engineering team at Zoom, our developers, our third party developers, our customers, and and and they enjoy working with our technology. And it all comes down to the critical components of scale, you know, making sure that we're measuring twice and cutting once on things, having everything instrumented properly, making sure that our data is well structured, it's resilient, having all the necessary pieces in place to be able to deal with disaster recovery because, it's been, you know, there there's moments where you you're playing whack a mole with different instances of, software that may be running in different locations, especially when you're talking about distributed systems.

And the data that powers all that needs to be stable. You have to be able to have trust and confidence in that data, and all of your KPIs and metrics that you build from that have to be fundamentally sound, and to instrument those properly and monitor things and know when you have issues that are, occurring, notifying you with alerting appropriately, making sure that you're filtering out things that aren't necessarily important, and, of course, safety and security. Right? How how do you keep all this data, all this information safe and secure? This is a huge lesson that Zoom as a company has learned, not just DevRel, but, our entire organization has learned how critical it is to put forth, and forethought the customer and developers security of their data and the safety of their experience.

Your your your product goes beyond just being a product when you're talking about interaction. It's not like, you know, regular SaaS app where you just go in and you're clicking buttons to do things. It's actually interacting with people. So the safety of how those people interact over video communication platform like Zoom is critical. We we also had a we had a problem with DevRel originally with onboarding just because we had so many people that were coming in.

Our docs really saved our life. Right? We had to we had to find a way to be able to scale outwards. And our getting started guides and our documentation as a whole, we were constantly tweaking that to improve, learn what we found from different people, and improve that to reduce the friction. And what we found over the course of time is we saw more and more developers who were signing up successfully with and needed less and less support over the course of time.

So speaking about our documentation, this is the number one lesson I think that the Zoom developer relations program has learned is documentation is everything. Documentation saves lives. Documentation keeps you sane. It helps your community to know what to do. And if your docs aren't clear, if you're not constantly iterating over the top of your documentation, improving it, and communicating through your documentation, getting your documentation closer to your product, getting your documentation closer to what matters to people, then it's you're you're not gonna grow, and you're gonna find that the support cases are gonna rise through the moon over the course of time.

We also have our developer forum that was unbelievably helpful in being able to provide a a dialogue between Zoom developer advocate team and our thousands of developers that there's there's only, you know, a couple handfuls of the developer advocate team at Zoom, but there's a massive amount of developers who were out there, and they all had questions. But our forums and the documentation together provided a frontline defense that allowed us to mitigate the the onslaught of requests that were coming inbound. It also helped to provide a public, location where we were able to take the learnings from one to one support request that we would see receive privately from developers and handle developer support at scale by publishing docs. Every time we would get an answer, our team would publish that information back to the documentation or into the developer form. Or if it was if we knew the answer was already there, we could just redirect people to the answer where it was.

So between the documentation and dev forum, these two weapons are are are are are shields, if you would, that they help protect you and your team, especially when you're just getting started. You know, with Zoom when 2020 came into play, our team was really only about a year and a half or so old. We we only we didn't have as many people as we do even now. So to deal with the the volume of information and and requests for meetings, both internally with with our peers, especially with our sales team and our business development and customer support team, that that there were a lot of inbound information. We had to train them to go to these resources and learn to use these tools to help serve themselves.

That's the whole idea here is how can you teach the man to fish, and that's what these tools help do. So I I wanted to make sure to not just present my perspectives here. I have one of mine in here, but I wanted to share what some advice from some of the other team members. Give them an opportunity to be anonymous or provide their information, and the folks who I spoke with asked to remain anonymous. But, the the first person here, unbelievable developer advocate based out of Denver.

And he says the the the problem was the overflow of support cases. We had so many support cases that were coming in that that we weren't sure what to do, and it was because we had disconnected or poor documentation. The expectations weren't set properly with developers. So we this is where we iterated, improved, consolidated the docs, and we've set those clear baselines for expectations with everybody, and we're able to guide them back in with those pointers. His quote here is really important.

Have your docs and pricing plans be super clear so developers can self serve and not rely on those support channels to get things done. That that's that's really what it all comes down to. How can I get things done and and be able to achieve the goals that matter for me as a as a developer building on the Zoom platform or on your platform and for for your DevRel teams case? So making sure your docs and your plans and information is present, public, and available, and and and it's it could be found. Is it indexed?

The the this this developer advocate right here, he he shared something that was really, really important through this because there has been an unbelievably large amount of hours worked by the Zoom staff across the entire company. Everybody at Zoom has worked unbelievably hard to help achieve some amazing, results and goals for everybody and keep the lights on for the world. It's it's been a pleasure and a privilege, and and it's been harrowing at times. The problem here being, as he's described, burnout, feeling overwhelmed, anxiety, stress. You may be feeling the same things if if you're working in DevRel and the this tsunami of work is coming at you.

And he he says the root cause is really overcommitting. Right? It's overcommitting yourself. It's overcommitting to trying to help achieve everything. I mean, we're natural people pleasers as developer relations people.

We wanna say yes. Right? We wanna do these things. We wanna help. But, ultimately, the solution comes down to learning when and how to say no and and managing your time properly.

Prioritization is everything. And when you're under super high stress like this, ruthless prioritization is even more critical, and managing your time is unbelievably important. His quote here, I learned how and when to say no. While this may seem like a negative thing, it taught me that if you say yes to everything, the value of that yes goes down over time. That that's that's an amazing lesson.

This person is a a very young developer advocate. He's been doing a phenomenal job, unbelievable work, and and he he's highlighted something with great wisdom here. So make sure to take that to heart. That's that's really important to understand. The last piece of advice, last lesson that was learned, the this is for me, actually, as as a developer advocate.

But, the the biggest thing that I think that I found is this, that the problem is there's wasted knowledge and information, and avoid of indexing that gets result that results in repeated efforts of individual people trying to find answers. And and and the issue here is about knowledge, learning how to do something either for yourself as a developer advocate or as a member of a company, an employee of a company, or how do you help your developers from the outside in learn about what's inside of the black box enough to be able to do what they need to do? And the root cause is because when we're investing time and energy to find answers individually for ourselves, either through by engaging with our engineering team or engaging with support or a product manager, or in diving deep with a customer to figure out is there an actual issue here, and if there is, documenting that and providing that information upstream. If we don't centralize that experience and that knowledge, then it becomes wasted energy, and and somebody else has to do this all over again. Document everything you can.

Make it indexed. Make it searchable. Tribes are awesome. Right? Having a tribe of people that you work with that all the pistons are firing, it's absolutely amazing.

But tribal knowledge kills. Having to go to a specific person to get the information because they haven't documented things or because or having people keep coming back to you because you haven't documented things, it doesn't work because you don't scale. You you can't be the lights can't be on twenty four seven, but your docs can. So those are some of the biggest lessons that we've learned the DevRel program at Zoom. Hiring I'm gonna add a couple extra things.

Hiring the right people who are passionate about your company and passionate about developers and and people who wanna make a difference. And and they wanted and they have good, strong cultural fit to your company, hiring those people is the single most important thing you can do for your DevRel team. We've we've got a team of amazing developer advocates at Zoom, and many of them are first time developer advocates. And but they've risen to the occasion. They've done phenomenal work, and it has been an honor and a pleasure to work alongside of these people.

And and if you'd like that opportunity, we have some positions available on zoom.us/careers, and and it it would be an honor to have an opportunity to interview you as well.