Designing for Enterprise Success: Hiring Strategies and Scaling Insights

Daria Tarawneh at UXDX EMEA. Video: https://youtu.be/mgYvIF9sq20

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

From architecture to enterprise UX

[00:00:07] Hello everyone. I'm really glad to have you all here, especially in these morning-ish sessions. Again, my name is Daria. I'm living currently in Berlin. I started my career in this field as a designer, as a lot of you. I don't come from a design background. I actually have an architectural degree. I come from an architectural background, and when I started working in the industry, I really didn't want to be an architect. So I stumbled upon UX, like a lot of you here.

[00:00:39] What happened is I started working for a gaming company, and that's where I realized, "Oh, there's this interesting thing called UI. I had no idea what that is. Oh, Photoshop, that's cool. How do I do this? Buttons, mm, nice." And then from there, I ended up somehow in New Zealand. I started a company in New Zealand. That's where I learned a lot about UX and how to build products. Ended up moving to Japan, opening offices in Manila. And now I'm living in Berlin.

[00:01:09] Before joining Miro, I actually worked for eight years at Amazon Web Services. For those of you who don't know what Amazon Web Services or AWS is, it's a heavily technical product. It's the cloud compute service from Amazon. If you're using the internet, you're probably using AWS. So that's a little bit about me. But let's move on to why am I exactly here and why did they bring me on the stage?

[00:01:37] Before I start my talk, can I get a little bit of a sense of the room? How many designers do we have? I'm going to try to see, it's very difficult to see here. Ooh, nice. How many designers who work in a SaaS product? Cool. How many of you work specifically for a technical persona, like an admin, a security engineer, engineer? I cannot really see in the back. How many of you are interested in this field? Good hand. Nice. I hope I see more hands by the end of my talk. Thank you, Josh.

What enterprise means for UX

[00:02:18] Imagine this. Imagine you get a job and somebody tells you you get 50,000 users or 100,000 users who are going to be using your product, and your company and your client have dedicated support. They will be helping you. You will have an easy way to research. You're going to have all this dream. Sounds amazing, right? The reality is very, very far, because that comes with a huge challenge.

[00:02:48] Before we dive into the challenges, let's talk a little bit about enterprise. Not this enterprise. And now that I got your attention, this enterprise. UX enterprise, and this is more or less the definition that I like to give. The definition is very vague and it varies. Nobody really knows what enterprise is. In some companies, it's about the size of the company. In other companies, it's what this company does. But it's very vague.

[00:03:15] But when it comes to UX specifically, enterprise is very different from B2B or B2C or even platform, because it stands within this crossroad of everything in the middle. And the sole purpose of what you're trying to do is you really try to improve productivity and the satisfaction of the users at scale. And at scale is really important here, because for those of you who work on enterprise products, you're very familiar with rows and tables that probably would be like 100, 500, or even 1,000 rows. And then you have to deal with all the complexity of oh, how do I search? How do I filter? Even these simple things like search and filtering become super complicated when you're dealing with it at scale.

[00:04:01] The second thing is it is a professional environment. For those of you who work on enterprise, you're probably working on internal tools or tools that are used by experts specifically. And everything you do, you're trying to make their work more productive, and you're trying to automate a lot of these manual workflows. Some examples of companies that work in this field: HR management systems, any cloud solutions, ERPs, CRMs, internal tools. Some of the biggest companies that operate in this field, you've got Oracle, you've got SAP, one of my favorites, and some of the newish kids in town, you have Salesforce and you have Workday.

[00:04:46] This. Yeah, I feel very privileged coming after Chris on this stage and telling you this is a product. Somebody built this and somebody's using this. That's the reality of what we do. This is SAP. This is how they used to build products for their customers. Let's not pick too much on SAP, it's not very cool. Let's go for AWS. This is 2011. That's not very far ago. We're not talking about the 80s or 90s. And that's what customers used to do. This is how enterprise products used to be built. Why? Because they thought that, oh, nobody goes to jail for building a horrible product.

[00:05:29] Well, let's say things became a little bit different in our field. This is Asana. I don't know if anybody works in Asana, but I'm a big fan of what they've done with their admin console. Because things changed. We no longer accept products that look horrible or look bad. Chris was talking about beauty, and that's not only talking about beauty within the B2C world, but there's also beauty in the enterprise, in the B2B world. Yes, our work is mostly forms and mostly tables, but that doesn't mean they cannot be usable. So we went from CLI to actually building proper products with buttons, and you can see the difference between the first and the last. It's drastic. This is where we came in the last 15 years.

What the internet changed

[00:06:24] So what exactly happened? The internet. Thank you, the internet, with everything that came up with it, like this cool invention. What happened is a lot of these products like SAP, or if you're working with Oracle, they used to be apps that get installed on a physical machine. You buy the license, the app gets installed. Some of these machines were not even connected to the internet. So of course, you build a product and this product is used by somebody and they cannot get out of it. This was the reality.

[00:06:59] However, when the internet came, now we have a lot more products and there's a lot more offering. The perception has changed and the expectations from your users also changed. From a technical perspective, now you don't have to install an app. You could use the app or you could use your software online. Which for us meant that we can update software. We could experiment. We could release something and take it back because ooh, we made a really big mistake. So that would change, and that's how things changed the perspective of how do we build software.

[00:07:43] And that came with a big opportunity for designers. Historically, these products were built by engineers. And no offense, but they're really good at coding, but not exactly good at designing, as we saw before. So that opened a big field for us to go into this design world and get a seat at the table.

[00:08:07] However, that seat at the table doesn't come without any challenges. It's not free. And to be honest, when I started working in this field, my first reaction to what I was doing, I really felt this is mission impossible. I cannot do this. I don't know how to do this. There was no saying that I can go and have a book that I could read and say, "Oh, this is how you design products in the technical world on enterprise." Or, "Yeah, this is how you should do it." That was not very attainable for us. Some of the challenges that I'm going to go through are challenges of my own personal experiences and what happened to me during my career.

The only designer in the room

[00:08:44] This is your face when you would first onboard to a company if you're working on enterprise, and you're completely clueless. Literally, what am I looking at? I remember my first job, in my first week at Amazon, and I was sitting there, and they were sitting in a room and they were discussing a product with a lot of VPs and CTOs and a lot of high people. And there's just me. Hello, I'm the designer here in the room. They just got a new designer. I think all of AWS had probably 30 designers in a really a lot of people in the company. 30 designers, and I'm one of them.

[00:09:24] And I'm just sitting there in the room and they were throwing all these acronyms above my head and I had no idea. And if you are in that situation, you're sitting there like I was: I'm scared. I had all my insecurity firing up everywhere, and I'm just sitting there hoping to be very invisible, and oh my god, I hope somebody would not ask me a question. Please, I'm not even here.

[00:09:46] And then my manager looked at me and he said, "Oh, Daria, what do you think about the user experience?" And I kid you not, my heart stopped. And I thought, "I'm going to get fired. I don't know what I'm saying. I don't know what I'm doing." And I just composed myself and I thought, we need to do something about this right now. We need to answer something. And I just said, "Really good question. Let me ask you another question. Who is the user? Who are we designing for? Can you tell me a little bit more?" And they all froze. And they all started giving me different answers. And nobody could answer my question.

[00:10:25] And that was the moment that I realized, wait a minute. Wrong slide. Wait a minute. Ignorance is actually a blessing. I could do this. They don't know what they're doing. They know the technical parts, but they have no idea what products they are building. This is a great opportunity.

[00:10:46] So I really had to learn at that moment things like this. These are just some of the acronyms that I had to learn at that point. For those of you who were in the talk yesterday from Kelly, she was talking about dancing the dance and getting tattoos. Yes, I have tattoos, but that was not the point. I really needed to know all of these terms. I needed to understand when they were talking about data residency, cloud computing, authorization, authentication, optimization, roles. For me, all of that was gibberish. I had no idea what they're talking about.

[00:11:19] And I realized, ignorance is a blessing. If you're working in this field, you really need to be an alcoholic [?]. All these stupid questions where you raise your hand, "I have another stupid question." It's not exactly a stupid question. It's a very valid question and probably nobody can answer that question in the room.

Who is the user: customers versus users

[00:11:39] So let's go back. Really, who is my user? Working in enterprise, the user is really complicated. You have two sets of users. You've got the customer, what we call a customer, which is the person who's giving you money, paying your salary. This is the business unit that signs the contract, that makes the purchasing decisions, and that makes their decision based on legal contracts. They make their decisions based on recommendation, pricing. There's a lot of factors.

[00:12:11] And then you have the poor user who's actually using the product. And hopefully they're not really suffering, but their main job is to get this done. They're busy, they require software that is very efficient. And if you have a feedback button in your product, the person who clicks on feedback, that's the user. That's who's giving you the feedback.

[00:12:32] Most of the feedback that we get from the user category is feedback around UI, feedback around certain functionality improvement. But the feedback that we get from customers is mostly about features. We need this feature. We need additional security. We need additional compliance. And that can make it a little bit complicated because you're working with the engineers, you're working with the PMs. You think the priority is this. Your boss, your manager, your business unit is working with the customer and they have a completely different priority. And that makes it difficult to juggle the two priorities.

[00:13:06] Add another layer of complexity to this, which goes into the company size, the sector. Of course, designing for a government is very different than designing for a tech company. It becomes very different. This is an example of a project I worked on that was directed toward the DevOps persona. The DevOps persona was such a new thing in the field at that time. And nobody knew exactly where they are, what exactly they're doing.

[00:13:37] So we were going back and forth a lot with the management because we couldn't agree on priorities. My managers were saying, "They don't care about UI. They're only automating. They're only using code." And designers were saying, "Oh, no. Well, the research is very different." What we realized is that when we were doing the research, we were actually bringing people, customers or users, from different backgrounds. We had the customer and the user. We had the technical user and the non-technical user.

[00:14:05] So what we did, we realized that we could segment them on two axes: the size of the company, small and large, and how mature they are in the cloud. When we looked at it, if they have high maturity, you've got the startups of the world if they are small. If they are large, then you're talking about tech giants, which is the Airbnbs of the world, Ubers. And they have a different way of doing things. If you're looking at a large company with low cloud maturity, then you're looking at governments. So you design a little bit different for them. I'm not saying this works for every company or for every project, but for this particular project, this segmentation worked. And this segmentation saved us a lot of cost in terms of building the right product for the right persona and getting alignment around what needs to be built.

Research and legacy in enterprise

[00:14:56] Research. For the researchers in the room, when it comes to enterprise, that's a completely different story. Because things that you know, like AB testing, heat maps, even metrics, UI metrics, they simply don't work. Why? Because a lot of these customers have bought the license already and the license is installed, and the customer sometimes is forcing the user to use a particular product. So it's not exactly their decision to make. So when you're doing AB testing, you're not going to get really good data from it.

[00:15:34] The second reason is these companies print marketing materials, printed tutorials for their internal users. So if you're playing around with the UI and changing the UI every other day because you're testing, what they have learned is different from what they have seen. So instead of making them more productive, you're actually shooting yourself in the foot. So research can be a little bit more tricky.

[00:15:58] Does that mean it's impossible? No. It's actually more accessible. Because even though sometimes contacting the customer could feel like another Mission Impossible situation, internally you have a lot of tools. You can rely on the user feedback that comes from a feedback button, or you can rely on your customer support. These are subject matter experts who are constantly talking to customers. You can talk to account managers who are on the phone daily with your clients and they're asking them questions, and you can get a lot from them.

[00:16:36] Business units and sales, these are amazing because you can listen to their calls and understand what other features the customers are asking for. What do you need to build in order for you to be able to sell or to be able to increase adoption? This will give you a really good grasp on what's happening on both ends, on the user end and the customer end, and how to prioritize and balance these two needs.

[00:17:05] Legacy. Oh my god, if somebody tells me you have to deal with another legacy or you have to uplift another legacy, probably I will have a heart attack, but this is the reality of what we do. We're constantly building, or we're constantly changing a certain interface to another one. Why? Because a lot of these enterprise customers, they got to where they are at the moment because they bought other companies. There's a lot of acquisitions. Or they hacked things around and then they kept building on top, on top, on top, on top, and then 50 years later you have code that's worse than a spaghetti bolognese at this point. But that would be probably one of the first things you will deal with.

[00:17:51] And there's so many different ways of how to deal with legacy. There's many different paths, and that's probably a two-hour talk by itself. But I want to talk about one that I've worked on, specifically in AWS. We uplifted the previous horrible screen to one that's a little bit less horrible. But this took five years. And imagine bringing 2,000 teams or 2,000 products into one particular design system. So that was one way of doing it. We're doing the same thing at Miro at the moment. We're uplifting our admin to something a little bit more usable and a little bit more comprehensible, where you have more space, where we can handle a lot more information on the UI.

What I look for in a portfolio

[00:18:45] So, how do I get here? As a designer, personally, you really have to be okay with having a not very pretty portfolio. That's the fact. So you just have to bring a different perspective to your portfolio. Probably you're not going to have beautiful screens. Most of the time you're dealing with NDAs, so it's not as easy and it could be a little bit complicated.

[00:19:13] What I look for when I'm hiring designers, and what I will say if you want to go in this field, what you need to show is, I need to see the problem very clearly. I need to see exactly what was before, what was after, what was the workflow that you dealt with and then you automated. That's really important because that's the core of your job. I'm not expecting to see beautiful UI, tables, wizards, platforms. But I want to see how you got there. What kind of work have you done? A lot of the work that you're doing is mostly service maps rather than actual UI work. I want to see that. I want to see the flow iterations.

[00:19:52] And then I want to see the business impact. Why do I say the business impact? Because in this position, defining business impact is very clear. And I will go into metrics in a little bit. But this is a page of my own portfolio. And that's how it looks. Doesn't look really good, but trust me, this gets me jobs.

[00:20:11] This is a product that we worked on at Amazon, and this was one of the most powerful products. That screen that you see on the right, this was the UI. And that UI took two years to make. Why? Because this UI allows you to onboard multiple services or deploy multiple services at the same time. And that was very, very, very difficult. So what we've done, we took all of this manual process and we automated it. And what we show the customer is: dear customer, this is what I'm going to do for you. The only thing you need to give me is a target. And what I'm going to do in the background is I'm going to do all these workflows. I'm going to give you best practices and standards, and you will have an environment to deploy within minutes.

[00:21:00] This was really successful. And that tells you how you can take a really complicated process and make it very simple. I believe that the best products that you work on, if you work on enterprise products specifically, is a product that has one button. Do it. And if you want to be even more successful, you should not have a UI, because if we do our jobs properly, customers don't have to go to a UI and then actually try to muck around with a UI. Things should just work.

Metrics and building the team

[00:21:32] Some of the metrics that we deal with. Ooh, I didn't realize I have two minutes. Speed up. You're dealing a lot with engineering efficiency. A lot of the work, especially if you're working on legacy, your best metric, this will be your voice: we're reducing engineering time. I found this metric specifically very powerful, and it helped me a lot in terms of securing resources for legacy products. Because, if you want to believe it or not, no company wants to say... Nobody wants to go on the stage and say, "Well, look at us. We went from a really horrible experience to an amazing experience." This doesn't get you on stage. But this metric was very powerful.

[00:22:14] Customer support use cases: the number of support use cases you have reduced, because that is time. Adoption rate. Time saved, which is also one of my favorites. I've worked on a product that saved 10 seconds from a salesperson's workflow. And imagine, 10 seconds is not a lot of time, right? Imagine that salesperson doing 50 cases a day. Multiplied by seven, you have a hundred customer support. Can you imagine how much time and effort you've saved at that point? And of course revenue. A lot of the work that you do has a very clear dollar sign to it. And if you can, include these in your portfolio, because that's what we're looking for. This is what we are actually looking at when we're looking at your impact.

[00:23:02] Finding designers is very hard. There are jobs, a lot of jobs, when it comes to enterprise. And finding the right designer who's willing to adopt that mental model, who's willing to take the sacrifices with not having a great portfolio, is very, very difficult. And the way I deal with this, or the way I try to get a cohesive design team, this is my own way I look at my design team. The designer skill matrix is I look at what designers I have and what skills I need. Just purely soft skills and hard skills. Who do we have on the team? Who do we need?

[00:23:44] And then for every project requirement, I look at the design skills that are needed. But sometimes you work on projects where the complexity of the project is mostly stakeholder complexity, because in a legacy product, well, you're basically replacing an existing system, not very hard, right? But you're probably dealing with 50, 30, more stakeholders. And other projects, if you're doing insights, if you're doing a dashboard, you probably need somebody with very strong design skills. So that's how I try to balance the designers, the skills that I need, and what projects we have.

[00:24:26] So, I hope I didn't scare anybody. And I hope I see more hands. But enterprise design is hard. It comes with a lot of challenges. However, it's very rewarding. As I mentioned, I did a very small quick search last week and I wanted to gauge how many job openings there are for enterprise designers in Europe specifically. And there were a lot. So you probably would not get a hundred job opportunities. You're probably only going to get like 10. But if you build your portfolio properly, you're probably going to get 10 interviews. So your success rate will be 100%. This is my talk. Thank you.

Q&A

[00:25:14] Host: A round of applause for Daria, everyone. I want to come and stand over here, so I can see you properly this time. I love it. This resonated massively with me. I used to work in UX research for software development tooling, and was in an interview at a point where one of my colleagues was trying to take this with a software engineer we were talking to, and they legitimately turned around at the end of the question and went, "I think we need someone more technical in the room," and basically hung up the call. Very challenging space to work in.

[00:25:43] Host: It particularly resonates with me when you said you realized you were the design expert in the room. And you're in a field that is very technical first, and so you don't feel like an expert in the room, but you have something to bring to the table. Tell me a little bit more, before we dive into questions of ours, about how that realization was for you. How that changed things, and how you instill that in new designers coming into the enterprise space, that they have a skill that is expert, but maybe not at the fore.

[00:26:13] Daria: For me, that was eye-opening. The fact that I thought that I was an expert, and then you go into the room, and you're like, "Ooh, I'm so scared." And then you realize, "Wait a minute, I have another superpower that I could use." So I tried to get my designers to ask more. Of course, we hire a little bit more technical designers, or designers who have the appetite to be technical, but I always push them. We have this mental model in the team: break things. Ask for forgiveness, don't ask for permission. Go ahead, break things. Do things that you're not supposed to. And if something doesn't work, we're just going to take it back and fix it. It's okay. Nothing is unremovable. Nothing is unfixable.

[00:26:58] Host: I love that. Okay. Awesome. Great question here. How do you encourage engineers or end users in these enterprise spaces to give honest feedback?

[00:27:10] Daria: Ooh. Usually, this is how it goes. If they like your product, they're not going to say it. If they hate your product, they're going to give you tons of feedback. So they don't need encouragement to know what is not going well. But what you probably need encouragement in is trying to instill a little bit of confidence in yourself and say, "It's not that bad." When you hear a lot of comments from customers and they say, "Oh, this is not working. And this is not working." Yes, this needs to be fixed, but that doesn't mean everything is not working. And with engineers, what I find very helpful is get them to use the product. Dogfood your engineers, and that's when they get this moment like, "Oh my god, this is not easy to use." "Yeah, of course. That's what we're trying to fix." But, yeah.

[00:27:52] Host: Amazing. Again, a very pertinent question. You mentioned a couple of things here. Change took several years. One, you mentioned five years. How are you keeping your designers motivated when progress is that slow towards making a difference?

[00:28:08] Daria: Ooh. Very, very hard. Very difficult. I think it's very rewarding. Yes, it takes years for something to come out. But when it comes out, people are talking about it. This is very, very rewarding. And it takes a little bit of patience. And I had my own personal fan moment, if I can say it. I was working for Amazon, and we spent two years building that screen. And I was there in a conference, an AWS conference, and a guy came out to me and he's like, "Oh, I love your product." He didn't know who I am. I just was in the booth. And he was like, "I love your product. This is amazing." And we started talking, and like, "Where are you from?" And he's like, "I'm from NASA." I'm like, "Oh my god." I had this fan moment like, my god, you're doing my dream job. And he said, "You're my dream job."

[00:28:56] Daria: So I think yes, it takes a lot of patience, but when you hear these comments of how you actually impact people's lives, that's worth it. And yes, it takes patience and you need to have a lot of resilience to be able to do this job.

[00:29:12] Host: And also, NASA is a fan of you.

[00:29:15] Daria: Imagine. I was all over the roof.

[00:29:20] Host: Fantastic. All right. Here we go. You've obviously been in the design space for a while. You've built up through quite a complex area of design that is hard to get into, I would guess, because of the technical aspect. What advice to junior designers?

[00:29:36] Daria: Ooh, a couple of ones actually. What I see a lot with the junior designers is, with the portfolios, I see a lot of screens, which is great. Mockups are amazing. Prototypes are amazing. But they always lack, or they don't put, how did they get here. My expectation is to actually see a process. Sometimes I want to see the different iterations. And that's what I see lacking in a lot of portfolios at the moment. So my advice: put the process. The process is more important than the screens, because I can teach somebody how to do good UI, or the company has design systems. So I don't really have to design tables or fields. They're available for you. I want to see that you're able to take a problem and then take it from a complex to an easy to understand problem. I want to see that, and that's my advice. Put more energy and effort into this.

[00:30:29] Host: Cool. Skills can be taught. Mindset needs to be shown. I love it. Excellent. You spoke a lot about the pain of legacy code. I've again also been in the sort of organization that turns around and goes, "If this breaks, no one for 10 years in the company has known how it works."

[00:30:47] Daria: Yeah.

[00:30:47] Host: It's dangerous. How do you recommend managing that kind of legacy code whilst you're also trying to be lean, trying to design well in an MVP fashion?

[00:30:56] Daria: There are so many ways that this can be done. There is no one way or one size fits all. I've seen it done in some projects in Amazon where we actually lifted features or lifted a particular product from legacy to new, and we always had this feedback button. So this feedback button was really important, and the go back button was really important. And that was very difficult because the two products will stay there for a certain amount of time. So as a designer, you're designing for the old experience and the new experience, and that's devastating. But that's really necessary in such technical products, because as I mentioned, customers have marketing materials, I have a lot of materials, and you need to onboard them slowly.

[00:31:48] Daria: I've seen it in other ways where it's done by experiences. So you just have a journey and then you uplift the journey. In other ways, you just want to stop development, clean the code, and then build new. Other features we built, we just removed chunks of legacy and all the custom components, and then we injected new components. It really depends on what you are dealing with, and it depends on how fast you want to go on the market, depends on what state you are in the product. Can you afford to stop development and not release features? There is a lot of ways and pros and cons for every way, and I'm happy to talk more about that from what I've seen works and what doesn't work.

[00:32:29] Host: I love that. I'm also now convinced you're not a designer, you're a researcher, because you used a researcher's favorite phrase, "It depends," when answering a question without actually giving an answer. I love it.

[00:32:38] Daria: Everything depends. Whatever it is, it does depend. Everything is contextual. Nothing in our space is simple. There is complexity in everything we do. You have to understand the context.

[00:32:51] Host: Ooh. Prioritization, a big one. How do you manage this one? There are user needs. There are customer needs that might be different. You have lots of metrics for business impact. How do you pick which one to prioritize?

[00:33:04] Daria: Ooh. So the way we prioritize, or the way we should prioritize, is based on customer impact. What a lot of times happens is that you start ignoring the user feedback and you say, "Well, this is not important. It's okay. They're dealing with this, and let's prioritize building features." And other times you flip the coin and say, "Well, we need to fix all of these user problems. We need to fix filter and search." It's always filter and search that are a problem everywhere. Always. It's like, "Well, you need to fix that because people cannot use it." "No, we need to build features."

[00:33:42] Daria: So having one without the other doesn't work. The company needs to move. So you need to build features in order for you to sell, in order for you to get a salary. That's one. The second thing, you cannot just be quiet on all this customer feedback, user feedback, when they're saying the search and filter doesn't work. So it needs to be a balance. And as a designer, this was one of the most difficult parts. How do you prioritize search and filter? And what I found works very well: create a big noise around it.

[00:34:08] Daria: Your management will listen to whales. When I say whales, it's your biggest customers. You might have few of them, but they're paying a lot of money. So their voice is very loud. So what I found very useful in order to get some of these fixes is I find who are the big customers, and then I go to my management and I don't say "I think this is," or "the user thinks this is." No, no, no. "NASA wants this fixed. Would you jeopardize a NASA contract for not fixing this? It's up to you. I'm fine with both decisions, but how about Airbnb? Would we not fix it for Airbnb? They're paying millions."

[00:34:45] Daria: So I found these arguments work very well in terms of bringing that user voice, because a lot of the management or decision-makers or the C-suite, they look at the customer request and they want to get the features out without actually looking back and going to the debt that we've accumulated. So this was my trick. I don't know if there's any more tricks, but that's what I've seen work, both in startups, mid companies, and in corporate.

[00:35:14] Host: It's similar to what someone mentioned yesterday, highlighting the risk of not following the insights that you've got. Everyone, Daria.

[00:35:22] Daria: Thank you.