 Thank you everyone, and thank you for coming to this session. I appreciate it. So let's talk about this. Let's talk about how we can create a data engineering culture, and as you see the subtitle there is, this is a crucial step. If you don't create this data engineering culture, here's the problem. You won't be able to maximize your ROI from data. So here's our itinerary for the next few minutes. We're going to start talking about what a data engineering culture is. Then we're going to talk about some stories. As he just mentioned, I've consulted pretty extensively. I'm going to share a few stories of both what happens when things are good and what happens when things are bad. Then I'm going to share how we can create that data engineering culture, and finally I'll share some common reasons why I've seen companies fail. So to start off with, here is a number that you probably haven't seen, and you probably won't see in most people's talks. Eighty-five percent of big data projects fail to get into production. That's a big, big problem. That is a very big number. A lot of you probably have a statistical background. You don't need a statistical background to understand the implications of this number. We have a really, really high failure rate with big data. I've written about it before, and I would say that this is one of our dirty little secrets within big data is how often we fail, and as a direct result of failing, we don't actually create value. If you don't believe me about the source, this is actually a number from Gartner, and the minified URL is right there. So let's flip that around and let's say, okay, I don't want to come across as a wet blanket, but 15 percent of companies will actually get some value from big data. And those companies that actually do this get significant amounts of value. The business value that you can get from big data, from being able to process your big data, isn't just a, let's say a 1x or a 2x ROI, it's actually far more than that. We're talking about 10x, 20x. In some cases, 100x value that they get from being able to process their data. But, and that's the big but, we have to get into production first. We have to be one of those 15 percent of projects that actually make it into production. So given the two ends of the spectrum that we just talked about, the 85 percent failing, the 15 percent being successful, how do we get to that 15 percent of success? Well, we have to create a data engineering culture, and that is exactly what we're talking about in this session. How do we create this data engineering culture? Well, first, let me define what I think a data engineering culture means. It means a culture where the value and importance of data engineering is recognized at all levels of the organization, and that all levels is actually key and important. If you're a data engineer here thinking, oh yes, I understand the value of data. I understand that data engineering importance. Hey, that's easy. I'm preaching to the choir at that point. You're here at this conference. But if you talk to your CXO, if you talk to your VP, or even if you talk to your direct manager, or perhaps a layer above that, and they say data engineering, don't know it. Don't need it. Then we have a problem. We have to have this notion at all levels. Conversely, if we talk to the CXO, they may not know exactly what you do, but they should at least have some knowledge of what you do as a data engineer or the necessity. And the reason we need to have that is we need to have these top-down manifestos or these top-down directives of saying we're going to do AI. Well, here's the issue. In order for you to do AI, in order for you to do machine learning, you do require that data engineering first. And so as these CXO levels give these mandates, they need to say, in order for us to do that AI, in order for us to do the machine learning, we have to establish that data engineering team. So here's a manifestation for perhaps you as a manager, perhaps you as an engineer, or even a data scientist. One of the manifestations is the right ratio of data scientists to data engineers. I can give you a range, and generally your range is one data scientist to about two to five data engineers. At some companies, there is one data scientist to zero data engineers. That is a really out-of-wack ratio. Those sorts of ratios are going to give you problems, because there are no data engineers, and we'll talk about what that means. Now, what we really want to do is we need to have enough data engineers behind our data scientists to support them in order to support the data products. And we're going to see a visualization of this in just a second. And here's another visualization of what I'd like management and managers all over the world to know. It's that early success or early failure of big data projects is mostly management. It is a management issue where if you were to talk to most managers or perhaps to most teams, what they would come back and they would say is, we failed because Technology X didn't do something. The technology didn't do this. The technology wasn't fast enough. Well, the reality is that the technology was not even the issue at that point. Usually, these teams fail at a point before they even hit a technical issue, because yes, there are technical issues. There are caveats. There are problems with these open source technologies, but teams aren't hitting them yet, because they aren't even in production to hit them. That's the issue. And so what we have is we have a problem where generally it's the management that's causing or the root of these issues. Here we can see management there being the blue, and we can see that team creation is where we have a lot of the problems. The project start is where we hit a lot of the problems. It's only after that first release that we then move off into saying, hey, this is now we have proved out the team. We actually have a correct team. We actually have the right people. We have the right people in the right seats, for example. And we prove that once we do our first release, as we do our second release, as we do our nth release, then we see that we have the right people. But up to that point in time, we don't know if we have the right people. And this is why we have that management being responsible. It is management's job to find and put the right people in the right places. Some people say this is putting the right people in the right seats on the bus. Well, when management fails like this, the management team has not put any data engineering people into the seats on the bus. They say we're going to do data science, we're going to do AI, and it's just 100% data scientists. That's the wrong issue. That's a issue where management set the team up wrong. And why is this? Maybe this is just Jesse's crazy ideas. Well, in looking around for this and researching this, I found that Google actually had talked about this same issue. If you don't believe me, there is the minified URL right there. So if you ask a data scientist who has never been in the real world, never worked at a company, or if you talk to a company, a CXO who doesn't understand what the team looks like, what does a data scientist do? Well, they create machine learning models. They create these artificial intelligence. How much of their data do they spend that? Well, 110% of their day is spent on creating this. Well, if you talk to a data scientist, what do data scientists who have been in the real world say, oh, well, I don't spend that much time creating that model. And it's because I have to spend my time on all these other things. And this is the exact diagram that Google created. If you look right there, that black box is the small amount of time spent on by a data scientist on the actual machine learning model. It's all this periphery stuff that is what soaks up the data scientist's time. And the biggest issue is that data scientists may not be the greatest people or the greatest usage of their time to do all these periphery things. As I'm doing case study research for a book that I'm writing, and one of the things I'm finding consistently is that the highest performing teams have realized this and have their data engineers handling the periphery or these other things, these other parts of data science that is required for data scientists so that the data scientists aren't spending their time on this. So why would you want to create this data engineering culture? Well, companies that don't have their data engineering in place are going to underperform. And maybe your companies in this situation, you may be sitting there thinking, but we have a data engineering team and we have a data science team and we have this data pipeline. Well, guess what? You may be only getting to a very, very low level of value because you may not have all of the right people there. You may be actually be underperforming on what is actually possible. And I hit this pretty often, whereas when I work with a company, I'll be able to see they're not doing this, this, this and this. And it isn't just this technical issue. It's also a business issue. It's also a utilization issue. Or they may actually just outright fail. There may be different levels. And these companies may not actually realize that they're underperforming. These are the worst types that, as you talk to them, they say, hey, yes. Yes, we do have our data. We have productionized this. We have productionized that. And then they stopped instead of actually iterating, iterating, iterating. And that is how they're going to keep from underperforming. One thing that I try to tell people is you've come to conferences, at least at this one, one of the issues with conferences is that a data scientist will come up and say, hey, this is what we did. I meant company X. This is what we did. How many times have you ever seen a company doing a case study actually say, or a data scientist say, and I'd like to throw out some thanks to the data engineering team who made this possible? Have you ever seen that? I've sat through a lot of conference talks. I've sat through a lot of case studies. I've seen that on very, very rare occasion. And part of the reason for this is maybe the person giving the talk either forgot or sometimes, especially the companies in the San Francisco Bay Area and Silicon Valley, it's just assumed. For example, when I walked up and I started doing some of my interviews with these companies, and I said, hey, did you know that some of the companies don't have data engineering and don't recognize the value of engineering or data engineering, it's complete news to them. It's completely crazy because they realize the intrinsic nature of, and the symbiotic relationship between the two parties that it's crazy that you would have a try to do machine learning or artificial intelligence without having your data engineers behind them. This is so important. So the reason I bring this up is as you hear these case studies, somebody may not have specifically said, and this is only possible with data engineering. So I'm bringing this to the fore. And to do this, I have created this meme. You may have seen it. I would love to come into a company and see this meme up there. And you may be familiar with the myth of Atlas and Greek mythology. Atlas was responsible for holding up the sky or celestial spheres or whatever you want to call it. And in many ways, our world would not exist if it weren't for Atlas holding up the celestial spheres. It would be a very different thing. And I liken this to data engineers and data scientists, that relationship, where data science is only made possible because the data engineers really hold them up on their shoulders and enable them. And this is what is really important about what data engineers do. Data engineers are the creators of data products. Data scientists are the consumers of data products. Without one, without one or the other, you can't really achieve the highest level of value in your business. If you don't have a data engineer creating the data product, then your celestial sphere, your world crashes down. You can't create that business value. And if you don't have the world or the data scientists, then you can't create all these nifty machine learning models. You can't do that advanced analysis. The two are interrelated. If you want to read more about that, I have the minified URL to a post I wrote talking more about this. And it's called Why a Data Scientist is Not a Data Engineer. And I go through some very specific examples of my experience over time showing here is why a data scientist is not a data engineer. And here in general, I don't hear data scientists say that they're doing, I don't hear data engineers saying that they're a data scientist. But what I do hear sometimes is a data scientist saying that they're a data engineer. Now to be clear, there are some data scientists that I've met who I would say, man, there are some of the best data engineers I've ever met. But we're talking about outliers here. We're talking about way, way outliers. The vast majority of data scientists are not very good data engineers. I would, or for that matter, programmers, or for that matter, distributed systems experts, there's quite a few different issues there. So let's talk about some culture stories. What happens when a company lacks a data engineering culture? Well, here's an example. One of my clients was actually having their data scientist stop. So here we had an issue where we, I was going around and I was visiting that client. We walked around to their data scientists and we started talking to them about their projects, what the status of their projects were, why the projects were having problems. And what we found out was that the data scientists would hit a point in the project where they would hit a technical inflection point, where they could not technically, on their own, make any more progress. And what they were doing was silently failing. They would basically stop at that point. So they had spent maybe six months, hit that technical limitation that they had, and stopped. Which is a terrible, terrible thing. Well, guess what? Those technical limitations were due to lack of data engineers. It was a group of data scientists trying to do something that was highly technical, highly data engineering. Had they had data engineers, they would have been able to make progress. In pretty short order, we walked around and started totaling up the business value that was being dropped as a direct result of this. And we hit $30 million, $40 million U.S. very quickly. That company was leaving millions, tens of millions of dollars on the table because they lacked a data engineering culture. And they were spending all sorts of time and losing all sorts of time for their data scientists. And as a direct result of not having any data engineers, data scientists are not very good at doing the data engineering work. It's just the nature of that beast. So one of the manifestations here is that, hey, some of these tasks, virtually impossible, or data, it just isn't a data scientist's ability or training or knowledge base to be able to choose the right tools for the job. I've hit a lot of companies where I'll talk to the data scientists. And the data scientists will say, hey, X is running slow. This particular thing I'm trying to do is running slow. Well, it's very clear that they're using the wrong tool for the job. But to them, they're using the right tool for the job. This is why you need a data engineer. A data engineer would think about the system that they're using, the tool that they're using, and say, hey, you're using the wrong tool altogether. The issue there is that data scientists was taking about an hour per, in that case, query. Well, that query should have been taking a second or less. As a direct result, those data scientists were incredibly, incredibly inefficient. They were doing nothing every single day because it took them too long to hypothesize and turn around a hypothesis. It wasn't the data scientist's fault. I believe it was management's fault for not recognizing that and getting that data engineering culture in place. And that was why I was brought in. So let's flip it around. What does it mean when we have a data engineering culture? In this case, we have the ability to accelerate things. We can actually accelerate our data science. As you think about these two skill sets, they're different. That was the whole reason for that post, that on the one hand, we have data science, and on the other hand, we have data engineering. And there's a common misconception most management, even to an extent, data scientists think, hey, I can code, therefore, I'm a data engineer. Well, the unfortunate thing is that their level of coding is not there. Their level of coding is not at the high technical bar that's needed to be a data engineer. So by having that data engineer in place, we're actually able to turn around those queries much faster. We're able to find the right tool for the job. We're able to make our data scientists either much faster, much more productive. There's a lot of things that we can do there. Another thing is that we can use our data engineers to democratize this data. You might have heard this very often, this term used. Companies want to democratize their data. Well, by doing data democratization, it's a buzzword that management has kind of latched onto. Hey, if we put the data out there, then people will just come and analyze it and we'll find this incredible ROI. Well, it works at some companies, but those companies that it worked at were the ones who had a strong data engineering culture where the infrastructure was already, the data products were already, that the person coming in to do some sort of analysis didn't spend two, three weeks, four weeks, just trying to set their system up and trying to set and understand the data. They were able to get in very quickly, see what was happening, have the data engineering team help them with that. And as a direct result, here's what our manifestation looks like. Our data infrastructure stops being our bottleneck and stops being a problem in data projects. This is the major difference I saw as I started interviewing companies about how they worked and how they worked between their data science and data engineering teams is that the companies with strong data engineering culture weren't talking about we can't do X or Y. They were talking about how they were accelerating, how they were trying to improve that even more. So let's talk about how we can go and create this infrastructure, this data engineering culture. To do this, let's start with the definition of who's on this team. For one, we have data engineer and my definition of a data engineer is a software engineer once again, underscore software engineer who has specialized their skills in big data and distributed systems. This is very important. They need that background in software engineering in order to be able to specialize in distributed systems. And then we have our data scientists. I define data scientists as someone who has augmented their math and statistical skills with programming to be able to analyze data. The technical bar for data scientists is much lower. Their value, the value generation by data scientists is much more around the analytics and that sort of problem solving, being able to frame a question. Data engineer is much more around how do I create these systems that can scale. The two are very, very different. And there's one other common title that's being used or that is often in these at larger companies and this is DBA, database administrator. It may be several different forms. You may have data warehouse engineer. You may have something like that at your company. This is another person who is going to maybe a, or title that may be giving you some actual problems. So we'll talk about that in a second. But another post that you could read that I wrote for a Riley, it's called data scientists versus data engineers. And I go even deeper into what the differences between these two titles are. So what sort of thing would you need on your team in order to, to create a good data engineering team and have good data engineering culture? The first two are the most key ones, distributed systems and programming. You might say programming software engineering, kind of, kind of similar things. Not everybody can understand distributed systems. Having taught distributed systems pretty extensively, I can tell you not everybody understands the complexity. I believe, and I've written posts about this saying, distributed systems, big data systems is 10 times more complex than small data. And this distributed system skill, if you don't have this, this is going to be a really key failure within your team. If you're trying to use big data and you don't understand distributed systems and big data, more than likely your code is inefficient and won't scale. And there's some major problems there. We also need to have people who know how to program. We need to have people who can do, in this case, for data engineering team, small analysis, simple analysis. They'll need to be able to communicate visually. Show me a, a, a chart, show me a dashboard. They'll need to communicate verbally with the rest of the organization. Here is what sort of data sets we have. Here is what sort of things we need to, to, to do. We also need a project veteran. Guess what? When you have a team that is brand new to big data, your team, this beginner team, is going to make the worst and absolute most terrible mistakes, which we'll talk about in a second and later on. It is, it is very, very key that you have a project veteran. Another one that may be weird is schema. We'll talk about a little bit about schema in a second. And as always, since we're in software engineering, we still have to have domain knowledge. We still need to understand what is the domain that we're even working in? Are we in finance? Are we in this? Or are we doing that? We have to know that to be able to create the right systems for it. So let's talk about some of the common reasons that I see teams fail with big data projects. One of the key ones and one of the most common ones I've seen is that the entire team is made up of DBAs. Now, DBAs, this is kind of my shorthand for any SQL-focused title. This is data warehouse. This is database administrator. This is, this is quite a few different titles. ETL, developer, SQL developer, very similar titles. Okay? So they're only ability to program and I don't have enough fingers to air quote program. I don't think that SQL is programming because it is not a lateral move to a compiled language. People do say it is a programming language. I disagree because I've tried to teach SQL-focused people how to program. It is not a lateral move. So what we have to do is we have to start saying, okay, well, this team that doesn't know how to program, we can't actually have them start creating these distributed systems. They can use distributed systems to an extent, but they can't create data products like they should. And that's a key issue that we have. In management, and this is usually a management failure, it's usually management thinking, okay, we're going to do a big data project. Let me look around the company. Okay, looking around the company. Hey, there's this team that does a lot with data, data warehouse. That's the one. We're going to locate our big data project right there in data warehousing. And so they'll think, hey, it's this logical extension. I'll just put it there. But it's not. I've worked with far too many teams, far too many data warehouse teams to be able to say, hey, your data warehouse team is the right place to do your, to put your work, your big data project. It is not. Do not put your data warehouse, your, your data, big data projects in your data warehouse. And the reason for this is twofold. One is that complexity increase that I just mentioned. I wrote an entire post on O'Reilly talking about why big data is so much more complex. And it is right there. Another thing is that it's not just a skills gap, skills gap meaning, hey, the person has the ability, they just haven't had the time to acquire this. No. It's, it's actually and they're not able to acquire those skills. They're not able to acquire the programming skills and they're not able to understand the systems creation. And these two is a double whammy where that team can go nowhere. I've seen far too many big data projects go nowhere because they were located in the data warehousing project or the data warehousing team. Another common reason for failure is that they're just set up for failure. Once again, it comes back to that complexity. Management does not understand this 10x complexity increase. And so what they'll do is they'll create this beginner team. They'll say, they'll look around the company, cobble together a bunch of beginners and say, okay, beginners, go learn this big data thing and we're going to be successful right out of the gate. Well, hey, even if you have really smart beginners, it's still going to take six months. I've seen it take as much as a year for pretty smart people, intermediate level people to be able to feel comfortable with us. I have a, personally, I have a pretty decent, had a pretty decent background and distributed systems before I went into big data. It still took me about three to six months full time to really feel comfortable with it. So it is not a, it is a nontrivial amount of time. It is a nontrivial amount of things to do, to deal with. And one of the manifestations of that complexity is that you're not just learning one technology, like you were with small data. Maybe you were, maybe there's three or four, maybe there's two. With big data, you're having to deal with 10, 30 different technologies just to get a solution together, just to get your data pipeline out. And that is where one of the key differences. So I was talking about one, one of the issues with case studies. As you watched either case studies at a conference or perhaps on YouTube videos, they leave out a lot of things. So if you ever see somebody's talking about how successful where they were, how just right out of the gate they just nailed that big data project, well what they didn't tell you is a few things. How many experts, how much export resources were they provided? Was there a consultant or a team of consultants that were on site and they're there to take that credit? Hey, that's a big deal, that's an important thing to know. Another thing is if they didn't have that team, that consulting team, what was the starting proficiency? Was this a lateral move? Were they a bunch of MPP data, MPP experts already and they started learning big data? Did they already have this massive background and distributed systems or were they small data and went to that big data? That's a very different level and a very different lateral move. Is it completely lateral or is it way up? Did they, was there a 10x complexity increase for the team or was there a 2x complexity increase in the team? They also may not say how much time it took them to get there. One of the things I found interesting is Uber has really been the only one I've ever seen be really honest about how long it took them to achieve some of these levels and there's a great post on that where they talk about their architecture over time and they talk about how it was truly iterative for them to hit. So we'll talk a little bit about this in just a second. Another one is that no one understands schema. This is an issue that happens and you sitting there you may think, well, schema, that's really stupid. Why are you spending my time wasting my time talking about schema? It's because schema problems do not affect you on day one of release. If you're in pre-development right now, you're thinking, man, that guy's crazy. What is he talking about this? It happens six months, 12 months after. It's because you can't lay down petabytes of data, terabytes of data and then change it if you don't understand schema right and that is the key. Part of what a data engineer, part of what I think the value, the business value of a data engineer is that they expose a data product. If that data product is not exposed with proper schema, they have not exposed the data product correctly. The rest of the organization, the rest of the business cannot make good use of the data product as a result. Now one of the key things or one of the interesting things here is that DBAs have this skill. Oftentimes there are software engineers who don't have this skill. There's a specific question I ask. Software engineers by and large don't understand this and it's usually the DBA in the room who understands this. So you might be thinking, hey, didn't you just say all DBAs was bad? Well, I did say an entire team made up of DBAs not going to go anywhere. Now here's the issue is you may want to have one, maybe two DBAs on the team to fill out some of the other skills that may not be on the team and in this case schema may be one of those. Another one is veterans. If you don't have a project veteran, you need one. A project veteran is somebody who's actually done, put their distributed system, put their big data system into production. Now they're not there to be a curmudgeon. They're not there to be some old guy saying, wagging their figure at you, saying, no, don't do that, don't do that. They are there to tell you, don't do that, do this. That is a key difference. Don't do that, do this. And when you're up at a whiteboard, you know what the easiest change, the cheapest change to do? The most expensive change is taking a system that's already in production and fixing it. That is the most expensive change. Your easiest change is to be up at a whiteboard where your project veteran has recognized a deficiency in your design and erases that and changes it up on a whiteboard. That is your cheapest. Your ROI on that is incredible. As you think about and as you design systems, remember that systems aren't just the, here's a system, here I just need to program it. Remember that a good system has to be developed and not just be theoretical, it has to be inoperational. It has to work in the real world. And that's another thing that your veteran will do for you, is help you understand, oh yes, that's somebody's theoretical thing, but in reality it doesn't work very well. Here's the way we do this in the real world. That's what you pay your veterans the big bucks for. Another issue can be that the project is too ambitious. This is an issue where management has went to a conference like this and said, oh yeah, I saw that company and they had this incredible architecture and they put their architecture diagram on that and I took a picture of it with my iPhone and here you go, go implement that. And you look at that and there's boxes and boxes and boxes and boxes. Now here's your issue. You can't go from a zero team that has zero big data experience to doing these holy grail sorts of things. And it's because the person who gave that talk may not have told you, oh yeah, it actually took us ten years and it may have taken us six iterations to go through that so that we can get to that level of those number of boxes. That is a key distinction. And as you start to create teams, as you start to create beginner teams especially, you need to be able to have time. You need to be able to give them the time to go from beginner to intermediate to more advanced. There is definitely a progression and teams that are expected to go from zero to really advanced can't make that progression. They just sit there spinning and spinning and spinning. And as a direct result, I think that there's a momentum. I think that there is a velocity. You've probably heard of velocity in coming from an agile perspective where there's a burn down rate and we increase our velocity. Well, I believe that there's a similar velocity for data teams and for data products, where if you have a team that is just a beginner and you put something that's so advanced, it's going to take them three, five years to do. Where what you have to do and what's really important for management to do is to be able to honestly look at the team and say, hey team, you can't do that yet. We'll get there, but we're going to do this more simple thing first. And this is where we need some evaluation. And this is even more key and honest evaluation. You may have hired these people. These people may be your friends, but you need to be able to honestly say, honestly, does your team have the skills, list of skills that I just had, the abilities, the use cases well-defined, the resources. Those resources are anything from training to consulting, all sorts of different resources, actual people, actual butts and seats. If you want something this big and you only have one person, two people to do that, guess what? You're not going to get something this big. You're going to get something this big. Then we have gaps. Well, what sorts of gaps are there? I mentioned these gaps, but this is another thing that takes some real honesty to do. You honestly have to be able to say, does your team have a skills gap where it is possible for them to acquire? They just need some time and resources to do that? Or is an ability gap where on their best day, they can't get there. They'll never be able to learn how to program. They'll never be able to understand distributed systems. This is a really tough call that you as a manager will have to make. Another thing that's important is that data engineering teams aren't just made up of data engineers that are predominantly made up of data engineers, but there may be some other titles up there. If you'd like to read more about that, I wrote a book called Data Engineering Teams. That's the minified URL if you want to read that book. Some teams say that they don't need help. There may be some reasons behind that. They may have a small data mentality. This isn't that complex. Or asking for help may be an admission of failure in their eyes. Or we do everything in house, not invented here. Those are three really big issues that you want to avoid. And as a result, you'll want to take a really honest look at that team. What help does the team need to get from here to here? And it may be they may need actual outside help. They may need somebody to come in and train them. They may need consulting at various levels of consulting. It could be that you have to hire somebody to come in and write all the code. It may be that you need somebody to come in and tell the team how to write the code or some architecture review. Or you may need actual mentoring. You may need somebody to come in and help sort out a whole bunch of issues and help them help you do that, help you accelerate in that way. So when should you fix a big data problem? If your team is experiencing problems, when should you fix it? You should fix it as early as possible. Because the earlier you fix it, the cheaper it's going to be. However, you can, it's never too late to fix things. It's just going to get more and more costly for you to fix them. So with that, I will open it up for a question. And if you want to ask your question in Spanish, I speak Spanish as well. Como gustan. So once again, any questions on this? Thanks for that. Jesse, any questions out there? We have one, no he's just covering his eyes. Don't shock me like that. Oh my god, we have one over here. Fatima, we have a question up here. Keep your hand out, that's it. So what is, the question was around the proportion of data scientists to data engineers. I wrote about that in my data scientists versus data engineers post. I believe that that ratio is one data scientist to two to five data engineers. Simply because the vast majority of what's being done, as you saw from that Google thing, is the majority was around the data engineering part. It is not around the data science. Okay. Any other questions out there? Spanish or English? I think that's us. All right. Well, thank you very much, Jesse. Thank you. You have a round of applause for Jesse.