Month: January 2020

This article is the first in a series about how to get started with Zoom in an enterprise environment. Including the enterprise relationship, Zoom’s sales team, and how Zoom develops its product.

Preamble – Working in Today’s Cloud Ecosystem

Unlike the old school days of when everything was just a box in your server room. Working with cloud services requires a fundamentally different approach to managing technology. There is no ‘internal’ data center that you own everything end-to-end by default. Where you just spin it up the new server, join the domain/LDAP, and install the software. To give perceptive, every assumption & procedure in that last sentence is totally different for cloud services. Let me explain.

Spinning Up the Server

This is the one that everyone loves about cloud services. Not having to manage hardware! WOOHOO! Let the cloud providers negotiate with AWS, Azure, and GCP. Just hope they don’t put their eggs just in just a single basket. Chaos Monkey for the win! However there is another side to this coin. Your application is now not on your prestigious internal network, or in your micron rated filtered data center. This means there is not a usually built-in security advantage or optimized internal packet flow. The way you approach the security of your company data is going to be different. Because you are now no longer owning everything. You now need to create relationships with the companies with the app’s you are consuming. To make sure they actually have proper security practices. Not to mention being properly audited by Infosec Swift’s loyal followers.

Join the Domain

Since this server was on the network. In more cases than not, it was a windows box that was joined to the domain. This means you already had access to a gaggle of tools around access controls, management, and communication options. When working with cloud services today, you need to bring your directory to the cloud. Thankfully there are SAML/SCIM based services like OKTA, and Azure AD it makes this possible, and can be pretty straightforward to do. More on this in another article.

Installing the Software

The most advertised feature of the cloud is not having to manage the day to day operations of the application. It’s always online and up to date. The downside is that you are now signing up to get on a train that never stops, and it will constantly move forward. You don’t get to control when new features come out, setting your own downtime, or owning your upgrade windows. Meaning you now need to subscribe to all of the support notifications by the app host to see when they are breaking things. You are now forced to commit time on your calendar for application lifecycle management. Instead of this always being on your own time terms.

Most importantly above anything else, your relationship with the application vendor has now fundamentally changed. You are now paying them every month or yearly for a piece of software. If you don’t pay… they will cut you off instantly. Your leverage of being able to say, no we are not spending a single more penny until X,Y, or Z feature is developed or fixed is now far more complicated. You now have a relationship more akin to your telecom provider. Where you are now are thinking about your lifecycle around contract terms, and having to build in six months of overlap if you want to switch away. But with the additional problem of these services are usually not commodities.

Don’t get me wrong, I agree with Ben Thompson & James Alworth on the Exponent 159 Podcast where they talk about this re-arrangement of the value chain in the context of MongoDB and Microsoft. It’s amazing that you now only have to worry about the application itself, and not all the infrastructure bits behind it. However you are now a partner with the service. This means you are not just a consumer of software/hardware on your own terms. You now are apart of their service. Always understand that. You need to clearly understand your provider’s motivations, incentives, and business model to make sure you are not going to be blind sighted in the future. I recommend listening to Scott Galloway’s advice of that you should always read a company’s IPO’s S-1 (If recent) and public company’s routine SEC filings for the real picture of a company. In Zoom’s case a lot of what I say below about their engineering team is clearly and only disclosed in their SEC filings.

Starting a Enterprise Relationship with Zoom

My favorite part of cloud services is that there is practically zero marginal cost for the cloud providers get you setup in their service. Chances are you already have users already consuming Zoom and expensing it to get their job done. With Zoom, if you are a business that wants to enable Zoom for more than 50 users, you will always need talk to their sales team to get started. This is for your benefit, believe me. Not unique to Zoom, working with the sales team is your key relationship you want to support and foster with your technology providers.

Charles Bryels – Account Manager Extraordinaire

Why?

• Pricing! – Good pricing is obtained by negotiating with your account manager. Like everything else you buy in bulk. Pricing goes down the more you buy. Everybody wins!
• Free Trial – If you want to kick the tires. Zoom will pretty much always give you the time to do a proper evaluation of all features before your buy.
• Lab Accounts – Always get a lab environment if you are supporting more than 1000 users. Zoom will not have an issue with it. Rather it’s the opposite. Zoom will be very thankful as this is where you can reproduce issues with them without it hurting. This matters even more when you have multiple integration points into Zoom.
• Feature Requests – All major feature requests and communicated via the account team (via JIRA ID’s), and it matters a lot.
• Beta Program Access – This is how you get signed up for beta programs to get ahead of the game. This also gives a more direct link to the product development team. This enables you to give feedback more directly in the time that matters most.
• Support Escalations – A great account manager knows all the key people in the company and will move mountains to get your needs met.
• Free Swag! – We all know that swag can be considered currency in some places. Or more importantly if anyone has any Theranos Merch, please contact Christina Warren ASAP!
• Customer Advisory Council Access – If you are in the fortunate enough to be considered for it. The CAC is where existing group of select customers convene on a regular basis to advise the company on industry trends, business priorities and strategic direction. This gives you access to long term strategy under NDA, and enables you to help make the product better.
  
• Please Note – If you are not a large customer you may only get a subset of these resources. How does Zoom define a large customer? Any customer that has more than 100k of monthly recurring revenue or 5000+ users.

To get started, click on the contact Zoom Sales button below to start the relationship:

Always a good suggestion is to use the additional information text box to convey some key information. This will make the process better and more importantly more efficient for you. The initial person that looks at this is typically in the inside sales team which is typically the most junior people in the sales team. It’s best to make their lives easier by giving them some initial information:

• What you are using now to solve your real time communications needs and what you are looking for in a product?
• Give an overview of you company and what it does in a few sentences – This is to route you to the right account team quicker.
• How many users you plan on enabling?
• Why you are looking at Zoom?
• Tell them you were referred by SoakLabs 🙂

After getting the relationship started by submitting the form. You can then move ahead getting started with the initial enterprise account setup. You can either do this by getting acquiring trial licensing on the account so that you can try out the various features for a period of time via sales. Or you can just lay down a credit card as well, but you will still need help from them getting the enterprise features setup. The next article will be on this.

Zoom’s Enterprise Sales Team

Like pretty much all technology companies, Zoom has a fully staffed sales and support team to help you in using their product. In fact this whole team makes up the majority of the people working at Zoom today. Understanding how enterprise sales works will help immensely. The people you will work changes depending on where in journey you are with Zoom. This journey is divided into two parts: Pre-Sales & Post Sales.

Pre-Sales is the time before you sign and purchase the large contract. This is the time where you evaluate the product, get internal stakeholder/executive approvals, start a proof of concept, perform the security assessment, and really kick the tires of the product.

Post-Sales is the time after you sign the contract to use Zoom. This is the time Zoom will support you in implementing the product, supporting the cutover process, helping technically, support/features escalation, and training. Again please note if you are not a large customer. You may only get a subset of these resources described in this article.

I recommend reading Mastering Technical Sales, The Sales Engineering handbook, by John Care & Aron Bohlig. This book is geared towards the Sales Engineer which I find is a good perspective. Yes I understand this book is not 20 bucks, however it’s money well spent as understanding the sales process can save you both significant time in the process, and literally 100’s of thousands of dollars off the final price tag.

Zoom’s Team Members in Order of Appearance

Inside Sales Representative/Operations – This is the person that will first look at your sales request you submitted using the link above. They will typically reach out promptly to have a quick 30 minute Zoom meeting with you to talk about the five questions I highlighted above. Their job is to connect you with the right Account Manager based on your size, company vertical, and location.

Account Manager (AM) – Owns the Zoom relationship with you. Is the primary person you interface for negotiating the contract, additional licensing, getting resources, and everything in the previous section. They are responsible and on the hook for facilitating and maintaining a successful relationship with you. They are in it for the long term. This person will make or break your relationship with Zoom. The great ones are hard to find. If you are not getting a good experience with your Account Manger, please make sure to reach out to a Zoom Executive if the relationship is not there. In Pre-Sales, the account manger will have you work with their sales engineer for all things related to Zoom. In Post-Sales, the AM will transition you to work with your CSM. Just remember at the end of the day your AM is still a sales person at heart, and still works on commission (Based what I read in their 10-Q, the monthly recurring revenue (MRR) number or what a customer pays monthly for Zoom is the key sales metric).

Sales Engineer – Mainly a Pre-Sales role, the SE goal is to technically inform you about Zoom, answer any general questions, and guide you through the process of getting setup with Zoom usually in the proof of concept phase. They are your point person in pre-sales for all technical/usability questions.

Zoom Executives – If you need to facilitate meetings with your executive team and have a need to talk in CIO platitudes or just to have executive level discussions, Zoom can provide that. Just make sure you get a fancy acrylic business card from Zoom’s CIO to complete the experience.

Solutions Architect – These are your technical experts you can work with on serious technical designs or features that your SE or CSM can’t answer. Each architect typically focuses on different areas of the product. This means you will usually work with a few. They are also you conduit into product management for feature requests and issues

Customer Solutions Manager (CSM) –  Your trusted advisor and account operational lead post sales. This person is assigned to your account once your sign a contract. They become your go to person for all operational tasks including on-boarding, deployment, facilitating meetings with experts, feature requests, support escalations, and more. They will also help with training and coordinate training resources.

Professional Services Organization – The PSO team can also be engaged for more high touch engagements. This includes Webinar & Large Meeting ‘Operator’ Production Support, Zoom Rooms Conference Room Install (Remote, Assist, or a Full A/V install), Zoom Phone Cutover, and they are now getting into Managed Services around Zoom Rooms as well.

Support – Zoom’s support team is great for the end user and level 1 and 2 questions. However for any technical issue that cannot be resolved in a self service manner or bug that is an engineering issue – You need to submit a support case and then escalate via your CSM. More on this in another article. However Zoom is currently working this year to improve their Tier 3 ‘ Microsoft Premier’ type support offerings (I hope).

Zoom Engineering

Zoom’s development takes place in two major places. At their offices in San Jose, California, and in multiple offices in China. Internally Zoom is really organized into two very specific company silos: Sales/Support/Operations and Engineering. This is not a unique to Zoom. However there is a very big divide where the engineering teams are kept intentionally in their lane to stay the most productive. Zoom has three distinct ways to connect engineering into the company: Through Eric & the executive team, their product managers, and JIRA. That’s it. Understanding how Zoom operates is critical for any feature request, support issue, or production change that you need. As if you do not navigate this process the right way, your request will die with the account team, or with support.

Zoom has a worldwide workforce. Their engineering team is divided between multiple very different time zones. For Zoom to get work done, they use a system called JIRA. Now what is JIRA? Well at its core, JIRA is a system that tracks and manages work. Zoom uses JIRA for at least three distinct things: feature development, change management, and bug tracking. This means aside from the executive team where I am sure everything is done via side deck; all work is started, assigned, and tracked via JIRA. The product managers use it to create new JIRA ‘issue’ tickets describing a feature in detail that needs to be developed. This is sometimes called a user story. This ticket might be broken down by engineering into specific engineering chunks of work to get done. When a product release happens, a bunch ‘issues’ are combined into project that is then committed and released. The operations team uses JIRA in the exact same way. If you need a SIP Trunk setup. Your SE will submit a JIRA request with the details, and the work will be completed. Lastly it’s the same way with support. If your support issue cannot be resolved by anything a customer has access already via the website/API/configuration plus a little more. Support will also submit a JIRA ticket for the issue into engineering to be looked at.

To sum up my point here…. If your engineering feature request, change management, or reproducible bug does not have a JIRA issue ID. IT DOES NOT EXIST. Also support tickets (Zendesk) are NOT JIRA Issues. Yes there is a link between the two systems, however they are separate.

Who has access to JIRA that you can talk to? You CSM, SE, SA, and some senior support people. That’s it. Account managers do NOT have access to JIRA. In practice it’s your CSM’s job to track all of your JIRA related issues for you. That is what separates the best CSM’s from all the others. They know that they need to be experts in JIRA (& Zendesk) to both find information, and to get things done. For a large customer who has 1000’s of seats for Zoom, it’s typical to have dozens of issues being tracked by your CSM. Or if you are me it’s more like 100’s. Sorry Mike!

How Do I Submit Feature Requests/Bugs/Changes?

Feature Requests – First work with your SE/SA/CSM to make sure you understand both your needs and how it fits into Zoom. The closer you match Zoom’s though process the better. Second once a feature is identified it needs to be explained into a user story and justified with the jobs to be done framework. Finally once all the information is assembled your CSM/SE/SA will create a JIRA issue (or duplicate, or add on to an existing issue) for your request. Make sure you get the ZOOM-XXXX JIRA ID.

Change Management – Any backend changes that need to be done for your account will usually be processed by your CSM/SE. They will usually have a form that needs to be filled out and then submitted into JIRA.

Problem or Bug – For any support case, first you need to engage support. You need to clearly reproduce the issue in production for support to to escalate to a senior person for them to create a JIRA Issue. Please note that Zoom is running into the same issue that Microsoft has. Their support team is great for level 1/2 issues. However once it reaches a certain point and need to escalate to engineering to look at. The issue can and does get lost in the mix. Especially if the issue is not service impacting in a major way. This is how I think Zoom’s major security bug in the news was lost in the mix last year. If your issue becomes a JIRA ticket. You will need to ask for it the JIRA ID and then escalate and track with your CSM so that it actually gets looked at and prioritized. The bad news is that support will not be of any help in this scenario right now (Prove me wrong Zoom!). As the support team metrics for success are not setup for tracking cases that get passed too JIRA. In fact they have every incentive too close or to put those cases in a special category like ‘hold’ as it will breach SLA’s otherwise.

Zoom Product Management 

Studying Zoom’s product management takes a large amount of kremlinology. Yes I know who is number one at Zoom. It’s says as much in the SEC 10-Q report every quarter:

“Our success depends in a large part upon the continued service of key members of our senior management team. In particular, our founder, President and Chief Executive Officer, Eric S. Yuan, is critical to our overall management, as well as the continued development of our products, services, the Zoom platform, our culture, our strategic direction, engineering, and our operations in China. All of our executive officers are at-will employees, and we do not maintain any key person life insurance policies. The loss of any member of our senior management team would harm our business.”

Zoom SEC Report 10-Q Q3 2019

However figuring out product direction is a very much more complicated process. Yes, Oded Gal is the Chief Product Officer, and yes he has assembled an amazing team of product managers including Nitasha Walia, Cyntina Lee, Jeff Smith, Vi Chau, Abhishek Balaji, Mila Krivoruchko, and many more. All of these people are amazing don’t get me wrong. It is also the number one reason to go to Zoomtopia every year is to talk with them, and the engineers that come as well. Well aside from watching Janine Pelosi working magic. Such a brilliant marketer. However the real mystery is how those requirements get translated and approved by engineering? As all of these product managers are in San Jose, and there are over 700 engineers or a lot of the entire engineering team that does not reside there. How features and bugs get prioritized is complicated to say the least. Moreover knowing where the product is really going is probably the biggest mystery of them all.

Now being a product manager is probably one of the hardest jobs there is. As you are fundamentally steering a ship of people with little guidance, into the unknown. There is a very big reason why Apple forced most of their engineers to move to Silicon Valley for decades. It’s because managing people is very hard. Yes obviously that Zoom uses the tools its created to breakdown geographic barriers. However going back to the analogy of kremlinology, Zoom is a mystery of what incentives are actually the ones that matter in how engineering works on the product.

In conclusion, my only advice is the one in the previous section. Make sure you have a JIRA issue ID. If you don’t, the request does not exist. Also make sure your friends and peers at other companies duplicate those JIRA’s issues. Just like at Apple, when they say file a Radar. It’s the best visibility the development team has on what is really happening out there in the real world.

-Kevin