Cloud-first Clarity: Evolving Infrastructure for Enterprise Clients with Asana head of Engineering

Sauna and we will be joining us for this interactive roundtable for the next 35 or so minutes. We will be discussing cloud first clarity Evolving infrastructure for enterprise customers and then before we get kicked off, just a few housekeeping notes that we need to get through. So to submit a comment, response or question to the speaker, you can use the Zoom Chat in the bottom toolbar of your screen. If you'd like to speak directly to the speaker, please make sure your camera is on and then you can raise your hand and unmute yourself appropriately. This will be an interactive 35 minute session and we encourage you to keep your camera on and audio muted for the remainder of that beginning portion. And these sessions will be recorded and available after the event. And with that, take it away.

Hey, I'm excited to be here and looking forward to the conversation. We'll see how this roundtable format goes. I'll be trying to get some of your comments and inputs in as we as we go along. So as far as how we'll go through the topics, I'm going to be talking about enterprise support, what experiences I've built up over the past seven years at Asana and I was at AWS building DynamoDB before that. So I'll talk through some of my learning about building for large customers. I know we'll have participants with varied experiences, so your input is welcome as we go along dealing with a lot of windows and technology here. So we'll see how this actually plays out and we'll also have space for discussion. In the end, as you can see on the agenda, the areas that I'm interested in talking about are first, building infrastructure for security and reliability, creating consistency and controls for admins, building data isolation and connecting customer data with other products that your customers use. So moving along here. So when we think about infrastructure and we think about reliability, having strong security controls and high uptime is key for customer trust. And there is an overlap in requirements that comes with high scale. And there are also specific requirements that come in because of enterprise customers. I won't for this particular segment, I won't try to differentiate a lot between those. If you are building for enterprise, you have to deal with both of those anyway. In terms of I expect that you're from different stages in your journey thinking about customer size. When it comes to security and reliability, my answer to the question of when is the right time to focus on these is pretty much all the time, including when you're just starting out. The way I see it, if you're building SaaS, odds are that you'll be holding very important customer data. And regardless of what you build, if your customers are using you, you are a threat vector for attacks on your customers. We've seen a bunch of that in recent months and years and I don't expect that to stop. So given the stakes, I believe we have an ethical and moral obligation to ensure that our systems and practices meet and exceeds any claim that we make about security and reliability to our customers. So want to give you a few examples of things that we've built and been asked to build over time as we have talked to larger customers service larger customers. One of them is formal SLAs around uptime. Of course you are building for high availability. If you're building SaaS, software people expect it to be available at all times. But as you talk to more customers who are using you for mission critical type applications, you will see formal SLAs show up in contracts and the exact terms will obviously be a business decision. But you'll need as you're building infrastructure, as you're building the product layers, you need to be confident in your uptime and you also need the ability to measure uptime and you need the ability to probably measure uptime on a per customer basis so you know that you're meeting your contractual obligations. So these are some of the things that kind of escalate over time in terms of what your capabilities need to be. Another important piece is customer visible real time status of your platform. And this has become more and more table stakes. As customers adopt SaaS, they expect to be able to see what has historically been your uptime when you've had events and then communication about events and incidents as they are happening is also something that is just your best practice in my mind and also something that is becoming more common in table stakes. And so I think that putting these in early is important. And as you mature and have more specialization, creating this visibility for customers also drives more collaboration between your customer ops teams and infrastructure and tech ops teams. And I think that's a good thing to have those communication channels. So, so you are both getting visibility into how customers are experiencing a particular degradation in your service or outage, and also for you to be able to communicate back what you found so far, what your ETA is, et cetera. Another aspect is backups. Of course, if you're a technologist, backups are just a tool in your toolkit for increasing reliability and durability. And as you grow, be prepared for customer expectations around backups. You probably start off thinking of Backups mostly as how long does it take us to recover the whole application. But as you run into larger customers, you will hear requirements around backup periodicity, location of your backups, retention, are you holding on to that data too long, etc. You hear all of these. Building flexibility around how you do your backups and how you manage your backups is pretty important. Another thing that over time we started to do is not just have the design that knows how to recover from backups, but actually put that into practice and test out our ability to recover just from backups.

Can I ask a question?

Yeah, sure.

What do you start thinking? Because we're talking about security, about things like that are a little more table sticks like SOC 2, some of those things that are more on the compliance side.

We'll talk a little more about compliance later as well. But overall I think it is very much dependent on your customer set as well as the type of application you're building. If the things that you are trying to replace already have compliance as stable stakes and everybody has it and you will not even get your first customer trial, you have to build it even before your first customer tries you out. For Asana specifically, I think we probably were well into. Tens of millions of dollars business before we did SOC 2 type 2. So we had more of a Runway before we had to do that. And we've recently done ISO 27, which is more. As our European customers have become larger, that's become more of a requirement. We are actively looking at more vertical ones related to government or finance or healthcare. And it just depends on your customer set which of these you will prioritize. Couple of thoughts here. One is, I think that when you do compliance, my advice is don't just check boxes and try to say we are compliant with X. Actually build in the controls because the spirit behind that compliance is good. One, it actually increases your security if you build in the right controls while building compliance. Second is consider ongoing costs. Not just what does it take for us to get compliant on X, but then what does this mean for our engineering culture and what does it mean for ongoing maintenance of that certification? So you might add certification that for example, requires three levels of review before any of your code can go to production. Just hypothetically. And that might be pretty easy to get that checkbox saying, okay, we implemented that control, but you might be forever then slowing down your development velocity. So definitely a consideration as we think about compliance. And that's something we evaluate value that we'll get from getting a particular certification. Cost of getting IT and ongoing maintenance for it. Cool. So in terms of yeah, going further into this so cloud infrastructure providers provide great tools to manage encryption, so definitely something that should be on your mind and something you should be actively working towards. In many cases it is just a question of turning on a configuration in AWS or GCP to get encryption in place. Again, my recommendation is to think about your encryption strategy holistically. How is your data encrypted at rest, how is it encrypted between services, what's the granularity of encryption that you're using, etc. One important thing to mention again, as technologists it's easy to focus on the design and architecture and infrastructure of your application, but things like office network and physical security are just as important as you think about overall your security. And when the first customer questions and expectations around our office security came in, I was surprised to hear customers care about it. But now I ask our vendors the same question. So it is because it's such a big threat. So it's pretty important to start thinking about these and have active plans because they're important to protect your data and your customers data. If folks have thoughts about efforts related to security and reliability, I'd be happy to hear those before we move on. All right, I will. I will move on, but feel free to chime in on chat as well. So talking a bit about Admin controls so many SaaS products like asana are built for adoption directly by teams. They don't require it to install and manage. However, as your product gains traction, it becomes an important stakeholder in how your product is used inside the customer shop and the needs of IT will vary by geography, by vertical, and there'll be customer specific needs and requirements. Just to give you some examples of things that we've built for our IT user segment, user management, basic deprovisioning, provisioning, but then for larger customers, more grouping of customer, more grouping of users and roles. What active integrations are present and what are allowed is another thing that you'll want to build controls for. So you might have an integration and you might be very excited about it, but some of your customers might be much less excited about that particular integration. They don't want TikTok videos to appear directly in your product and they might want to shut that off. So giving launch away launch your integrations but give admins control on what can happen. Privacy, security settings, data export, all these are things that might not be in your initial product requirements, but as you start thinking more about it, they should become Part of your requirements.

I'm going to ask, I'm going to dig in here if that's okay because I find this. So Sara, I think from the beginning you guys built for the team, right? Like you did both. I know a lot of SaaS companies, especially now with product led growth, they built for the individual and then they get roped into bigger deals, more team user management. Right. What suggestion do you have if you're in the ladder? If you're not as lucky as Asana, you're not as forward thinking. You didn't think about like that flexibility from day one.

Right.

Like we're like what recommendation do you have for those folks?

Start now. Okay, that would be my recommendation is you are where you are and sounds like you have traction, sounds like you have those individual users. So at this point start thinking about what it will take and it is a journey and you can bring your customers along. I'll bring it back to this as I wrap up actually. So let's move on and then come back to this. So one thing I think about a lot and have continued to is data isolation and basically SAS. One of the key things that makes SaaS attractive other than removing the operational burden from your customers is multi tenancy because it makes makes your offering more efficient. And as your customers become larger, there actually is an opportunity to isolate customer data without giving up efficiency. With isolation, I mean you provide more scalability, performance security for individual customers by putting their data in compartments. You can reduce noisy neighbor problems for performance, for example, and make customers feel more warm and fuzzy about your architecture because they can see that their data is protected maybe on a different disk, on a different database with a different encryption key. There are various ways of isolating different customers data, but all of those tools are helpful in providing isolation for one customer versus another. We've been on a long journey as we've built out our application layers. One of the interesting things, I won't go into details on this picture, but one of the things that we were able to do because we had data isolation between customers is provide the ability for customers to place their data, for example in an EU data center as opposed to in the us. That was a strong requirement from some of our European customers. But building that out even while having data isolation wasn't trivial because we had to join data in some cases with a centralized database. And in those cases, so what we had to do was build out a service. Instead of a direct data store join, we had to build out a service that provides membership information, cross region so these are the kind of things that you will have to do as you mature from full multi tenancy architecture built around providing layering to isolate customer data to actually separating out the customer data more vertically across your layers. The final piece is connecting data. And what I mean by this is thinking about how your customers are using not just your product and application, but actually what is the ecosystem of products that you're. Oops. Yeah, what's the full ecosystem of products that they're using? And so according to Asana's Anatomy of Work survey and index, on average workers switch between 10 different applications and they're actually doing the switch 25 plus times a day. And I think that's actually an underestimate when we talk to people, I probably switch between applications more than 25 times. Enterprises are dealing with thousands of applications that employees want to use. So connecting your app and connecting your product to other applications allows the value that you're adding to be more accessible through more services. So build an API early. Start thinking about your developer ecosystem so that you are helping others build on top of your product, not building each of these integrations out yourself. And as you think about enterprise, there will be specific security needs. So SIEM audit logs, DLP loss prevention basically are important tools for customers to secure their usage of your product. So I'll go to my key takeaways as I've thought about enterprise broadly and then we can have more of a discussion. So one of the first things is to have empathy for your customers broadly, but specifically for your large customers. The IT folks you are working with, the buyers all have an obligation to protect their data. And when they are thinking about the value your product is adding, they're also looking at to control and protect their data and minimize risk while getting the value that you offer. My experience is that they are opinionated about their needs because you're not the first vendor that they're dealing with. But in many cases, and in most cases, they're often willing to discuss how their goals could be met. If you are able to find the right people within those organizations to have those conversations with, I highly recommend having starting with what is the problem you're trying to solve and then how can our product change or how you can use existing capabilities to minimize the risk that you perceive. The second thing is that even though admin use cases are a much narrower set, usually for products, than the product that you're building overall, they are customers. They are using your product directly. And to have the right experience for enterprise, it pays to Treat admins like first class customers, do user research, understand their workflows and and build to provide to make their customer experience as smooth as the customer experience of the functional elements of your application or of your product. And the last piece is that for any company you're dealing with hundreds of things that you could be building. It's hard to prioritize asks from your largest customers along with the rest of your roadmap. So it feels like you leave one behind. One rule of thumb that we've developed is basically that we will listen to customers. We will reorder our roadmap to prioritize things if we are getting strong input from customers, but we won't build one off features that nobody will use for any particular customer. We'll only build things that we think are on the roadmap. They are the right thing to build for us, for our product, for many customers, not individual kind of solutions. And we found that our largest customers are usually just the tip of the iceberg. They are pulling us in a direction, but it's not for an individual use case. Those needs actually show up in many future engagements. So we might say no once, but by the third time we hear it, we're like, okay, this is a trend, let's talk about it and let's maybe rework our plans to build this in early. Those are my main takeaways and I'm happy to switch to questions and your thoughts about what you've experienced as you build for enterprise.

Awesome. Just a reminder that you can ask questions in the chat or you can raise your hand, unmute yourself, jump in on the conversation.

Any other questions or any battle stories to share. Happy with either.

How do you prioritize which ones to tackle when you're resourcing? Let's assume you're a 10, 15, 20% startup. You know, you should do security, you know you should do SOC 2, you should do team management built for the admin, but at the end of the day, right, you have maybe two, three engineers. Like how do you know which one to do this quarter next month versus two years from now.

Yeah, I mean this is, it's not an easy question. It's something that we grapple with at our scale and I have grappled with when we were at the stage you're talking about as well. So it's a journey. I think there's a couple of things to think about. One is existential risk, right. If you, there are ways in which you could lose customer data which would just end you as a company. And so thinking through how can we leverage the security offerings maybe of our cloud provider, how can we get help use the resources that maybe your cloud provider provides. They might have solutions, architecture, architects that can help you validate that the way you're building doesn't have massive holes right at the beginning. You're building right from the beginning. But you don't need a dedicated security effort on day one. Finding product market fit is probably way more important than that. I think the most painful decisions come down to this could be the largest customer we've ever had. And that number, the dollar value associated with that keeps growing as you grow. So it's not like that decision becomes any less painful as you grow bigger. And you just have to know when to say no as well. And you have to learn how to say yes and get to yes with the customer and you have less leverage when you're smaller and maybe a little more, but not a lot more as you get bigger. And one other interesting thing is that the largest customers, when they are writing you six figure, seven figure checks, they really want to test out whether you will be a strong partner with them. So some of their asks might be ways to see how you engage with it and they might be very willing to negotiate on timelines of delivery. So I think engaging with the spirit of what we call co creation is important, where you and your customer working together saying, okay, clearly you see value in our product, clearly you have needs that we don't meet yet. What can we do so that you're comfortable with the usage? And that might be on their end specifying what usage is allowed right now and what they will unlock if you do XYZ things. So there's multiple ways to go after it, but it's not, it's a very nuanced decision usually and it's hard to say no, but you should sometimes.

Awesome, thank you for that. We have time, I think for about one more or so questions. So if you have some questions, feel free to drop them in the chat. What do you think is one of the most common misconceptions about building for enterprise?

It's a good question. I definitely haven't done a survey to know what this might be, but I think it might be that one of the misconceptions is that if you're building for enterprises, you are building point solutions for individual customers and you essentially need to have a service component where you are just customizing your application multiple times, once for each customer. I think modern SaaS is much more deploy in any customer. And I think that is the holy grail for achieving true scale. Some applications might definitely be more suited for deeper customization. But I think for most companies, I would advise at least thinking, what is the problem this company is trying to solve, this customer is trying to solve with their ask? How does that overlap with similar concerns that other large customers will have? And how can we solve this problem that doesn't just solve it as a custom solution for one customer, but solves it broadly for a set of customers? I think you'll build a more scalable business if you think that way.

What a great answer. If there are no other last minute questions, final moment.

This is great. Thank you.

Awesome.

All right. Thank you so much, Prashant. This has been amazing and such a great session. We have a lot more great content today and I will see you all in the next session.

It.