In today's episode we sit down with Venkat Venkataramani to talk about his role as a co-founder and CEO of Rockset.
In today's episode we sit down with Venkat Venkataramani to talk about his role as a co-founder and CEO of Rockset.
In this part 2 of our two part interview, we dig into leadership mindset and leading a company during difficult times.
Thank you to New Relic for sponsoring today's episode!
Make managing and analysis of complex digital architectures work for you. Check them out at NewRelic.com to become a full access user with 100GB per month totally free.
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
If they're motivated enough to bring it in almost every case that I've worked with, they're motivated enough to be part of the solution. And you just have to empower them and support them and actually commit to addressing the issue. And it invariably makes the company and the organization stronger if you have that mindset. Welcome back to the second part of my interview with Venkat Venkataramani. That was just a piece of what you're going to hear in this episode. And I encourage you to go back and listen to the first part of this interview if you missed out on it. My name is Jonathan Cottrell. You're listening to Developer Tea. My goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. And I think Venkat can help you do that because he has led through crisis after crisis. And that's some of the things that we talk about. We talk about bikers. We talk about the world. We talk about the world. We talk about the world. I hope you will tune in very closely and listen to what Venkat has to say. Let's get straight into my interview with Venkat Venkataramani. There are certainly times that I've experienced discussions with engineers where they were bringing up the discussion as a matter of principle rather than a matter of practicality. So in other words, they didn't like that we were using a particular... I don't know, framework or something, right? And so they would voice that concern. And in my mind as a manager, I'm hoping that we come away with some kind of action to take. That's my hope is that for somebody to voice a concern, hopefully there is either a discussion that resolves the concern. This framework actually does. It's not just a question of, oh, this is going to work well for this particular job because of X, Y, and Z. Oh, okay. We're good to go, right? That would be a good outcome. Another good outcome would be, oh, you make a good point. So I think there's certainly these two outcomes that we could have. We could either have an outcome where we resolve the differences and we continue on the path that we had planned. Perhaps you're missing a piece of information I provided or I'm missing a piece of information you provided. And then we resolve. Somehow and nothing changes other than our mindsets or something else changes. We decide to review our options again. We say, oh, you're right. This framework does have a shortcoming or, you know, perhaps we don't know everything we need to to make this decision thoroughly. But sometimes, and this is perhaps unique to engineers, sometimes engineers want to have this discussion almost as a point of, of philosophical debate rather than action. And I'm curious if you've ever seen this in other parts of, of your business or with a team that you're working with. If there's kind of a bike shedding that happens, right? Where you're, where you're kind of going over the subject over and over and trying to get everything right or trying to get your point made. But really there's no action particularly that anybody is, is, uh, uh, trying to shoot for in the, in the discussion. I totally hear you have been on both sides of that, you know, uh, in terms of being part of, uh, you know, discussions where it was happening with no clear. You know, consensus and the whole thing kind of like just festers for a while. The project doesn't go anywhere. I've also been on the other side where, you know, it's been managed well. I think it all came down to, uh, clarity around the process of. Decision-making right. I think basically in any situation, if there's going to be a big change coming up, uh, if there isn't clarity on who gets to own it, uh, who is responsible for that transition, for the change, for that new project to be delivered on time and with high quality. Um, if it's not clear who is owning it, and then they get to make those decisions and it may, you make it very clear. Other people can contribute. And add, uh, you know, be part of the discussion, but the final decision comes to the key person driving that. And then that is clear. Um, you know, then I think, uh, you know, things move forward and all these discussions at the end of the day, uh, you know, makes, you know, hopefully informs the key decision maker, make a better decision. Uh, and, uh, you know, you, you know, even if you disagree, you disagree and come at and, and, uh, try to do, you know, do as a company at your best job. And. Yeah. You're giving it a real. Sure. You're giving it a real shot so that we have a, you know, not a self-fulfilling prophecy or anything like that, but actually have a valid result, whether positive or negative. Uh, the, the, the places where I've seen it fail are the person introducing a very complex change, very complex kind of like re architecture type of stuff. Yes. They are the ones driving it, but it has ramifications way beyond their, what they immediately control. It changes the way how the operations team man, you know, do on-call, they changes the way the, how, you know, product teams just product management, like it, it has ramifications way beyond their immediate, uh, you know, uh, circle of responsibility. And they really want to push through the project and they very quickly get to a point where you say, look, I'm going to go do it. Um, it's your job to convince me not to. Right. Like that's when I feel like, you know, you kind of like the whole collaboration breaks down. Uh, and I think those are the kinds of, uh, situations which are much, much tricky, you know, in a larger organization to deal with when your project has unintended negative consequences to a whole bunch of teams around you, uh, that you're not fully weighing, uh, you know, in your decision-making process. But in most places it's avoided by just making it clear. Uh, on who's responsible for making the decision and making sure that their decision only affects that portion of the thing that they're responsible for. Uh, but then that is not clear or that cannot be achieved is where I think a lot of these, uh, you know, the stereotypical bike shedding, you know, discussions happen because, uh, you know, one organization wants to make a change that has a dire and negative impact on a whole bunch of other teams. Right. Yeah. Yeah. This is, I think the, the core of what you're saying is so, um, often forgotten that having a shared decision-making, uh, process and not even a process, it can be a shared decision-making philosophy values that you share. Um, all of these things play into coming to consensus because if you don't, so, so let's play this out a little bit, right? Right. If you don't have a shared decision. Decision-making protocol, right? Whatever that is, if it's values, if it's soft or if it's highly technical, if it's a algorithm that you take your business follows, or, uh, maybe you determine some goals and if you can't, you know, tie a particular action back to those goals, then, uh, it's off the table. There's a lot of ways to do this, but if you don't have it and you find yourself in a discussion or, or a heated kind of debate between two options. Okay. Then the reason. The reason is that the logic that's being provided, right? The, uh, kind of the logic that's provided on either side of that may be completely valid, right? On both sides could be totally valid and there's no way to kind of cut between those, right? And so both sides feel like if you choose one or the other, because they are, you know, everybody agrees that there's not one that's clearly winning over the other one, that there's some kind of favoritism involved. Maybe there's politics involved. But you can clarify this so much, you know, so much easier if you do have a shared decision-making protocol. So I'm interested, um, if, first of all, if you agree with, with that, but secondly, you know, how do you develop better decision-making in particular shared decision-making frameworks with your teams? Yeah, I think it's very, very hard. I think honestly, I have never seen a big company get this right. Um, you know, like. I actually think if you have a natural tendency to want to build consensus, to make any decisions, you will never get anywhere. I mean, it's just not going to happen because consensus is almost like a natural, you know, it's going to happen very naturally when you're very small. So you don't really need to even think about it too much. Uh, there's only four people that are key, you know, in, in every decision, you know, so like, you know, you, you, you talk it out and you quickly figure out what to do. And as you get larger. And larger, you know, you, you do the same things, you know, you, you want people to be accountable, uh, have KPIs and the team level of the org level. And, you know, the, you know, when you have more and more people accountable for certain, you know, for, for what they own, you've just empowered a lot of people to say no to things. Except it's very hard for people to say yes to things when it risks their KPIs. Why would I do it? You know, that's kind of like my, uh, team success and my reputation on the line and my team's reputation on the line. And so. So I think it's very, very, very hard to achieve, uh, in a big company. And this is why I would say a star. This is why startups continue to outcompete and win large companies. So I think if somehow a larger organization can, uh, not get into this, uh, uh, you know, Consensus building or the lack of consensus, uh, you know, becoming a roadblock for innovative projects that cuts through. A bunch of different organizations or, or, or, or, uh, you know. Teams. Um, you know, if larger organizations can figure that out, I really think, uh, startups have no chance. So I, I, I haven't seen any large organization get this right. Um, you know, the Amazon talks about disagree and commit, and there's kind of like values that could be. You know, inculcated and, and, and, uh, the way, you know, AWS teams, you know, the two pizza teams and tough stuff, you know, are a ways to kind of mitigate this by not creating. Large organizations that can say no to things by creating a large number of small teams that can own the entire decision on the entire product end to end and move fast. And so that's the only pattern that I've seen that actually comes anywhere close to becoming a practical way to build a large company. Uh, that still has that kind of innovative mindset and, and, uh, and, uh, quick decision-making. So there, I think it's not really, uh, uh, a consensus mindset. It's just not hard to build consensus because you're just only trying to agree. Uh, you know, get like, you know, five decision makers to agree on something when it is like 15, forget about it. Uh, you know, it will be a design, uh, you know, when it is 15, it's like already gone. And by the time you're 20, like you might as well go find another job to get anything done. Um, so that's kind of like what happens. And this is why people who want to build and get stuff done. They don't want to work at a big company. They want to work at a company like Roxette with 30 people, because whatever you imagine you can. You know, you can work on it and you know, you don't even ask for forgiveness or permission. You just do, you just go and do it. Uh, you know, if you see a problem. And so I think, um, yeah, I think it's just really hard. I think, uh, it's, it's almost, I would say if a, if a big company says, oh yeah, we had a very consensus building culture. Uh, it almost means that they don't innovate, uh, because innovation by, you know, it's also called disruption, you know, and you can't disrupt. Uh, you know, without having a controversial point of view, uh, and, and those things are the ones that get shut down first in a, in a consensus consensus culture. Yeah, that's, that's a really good point that, you know, if, if you're looking to make your team better, then it's very unlikely that, uh, consensus is going to do that. Right. That, um, design by committee is notoriously, you know, is a negative thing, right? Yes. Um, we don't say design by committee and designers say, oh yes. That's, that's what I want. It's very, very rare. Um, so I, I want to push on this a little bit because I, I think there's, there's something interesting here about how, how do these big companies operate if they can't build consensus? Um, and I, you know, part of your point is that, oh, well, it's, you know, one of, one of the things that Amazon does as an example is they don't rely on large teams. They rely on small teams and those small teams can, you know, potentially build consensus. Or if they can't, then it's a small enough bet that it fails and that's okay. I'm, I'm interested in what you think about, you know, how do we coordinate large efforts cross team like this? Because you can see this, uh, uh, actually happening. Like, for example, if I rewind a few years ago, uh, back to, I don't know, maybe 2015 or 14, even a lot of Google's products. This is a simple example. We're very different UX. We're very different from one product to the next. Right. It was, it was very clear that they hadn't, um, had a project to kind of unify the design systems and, and, uh, the UX across all of their products. And I'm, I'm curious if you think that that is, um, you know, that kind of problem is a risk of having all of these teams that kind of have ultimate autonomy over what they're doing. Right. Is, is that you don't really have a. Consistent delivery or consistent product as a company, if you do that. But secondly, um, I'm interested to know, you know, is there a way, because I believe, um, that if you were to look at consensus from the perspective of, uh, trying to win each other over in debates, right. And logical argumentation, that's one kind of consensus. Another kind of consensus might be democratic consensus, right. Is enough people. Say that they agree with this particular direction, then we're going to go that direction. Um, so there's some kind of governmental way that we might handle this. There might even be a merit, uh, meritocracy, um, where somebody who has worked on this the longest, or who has the most experience in this area, they may, uh, help drive the decision or have more weight in the decision. So I'm interested to know, you know, on both of those fronts, I know I've asked you a bunch of questions back to back here, but. Hmm. Um, uh, the, the first question is, do you think that, uh, the small teams may produce inconsistent results between them, uh, which could kind of create a fragile overall system? And then the second question is, are there other ways to generate good decisions beyond just argumentation? What kinds of ways do you think we could make better decisions together? Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah, I think really interesting topics. So the first one, look, I think I've worked at larger companies and or companies that got very, very big. It wasn't large when I started and like, you know, and it's boring. It's just really boring. It's everything is slow. Anything that is, quote unquote, disruptive. Again, as I said, there isn't no, there isn't anybody you can go around and say, all right, if this fellow says yes, we can do this project, except that there's a lot of people that can say no, it's not clear who can say yes, because it's disruptive. So it's just boring. And, you know, just to, you know, kind of like proof by example, give me one startup that has less than 100 people, where do you have the problem? Where you can't do something and like, you know, so like, what is the framework that the startup using? No, it's like, make the goals very clear on what the company needs to achieve. And everybody can actually see the machinations of every aspect of the company. And there's clarity in terms of how, you know, the marketing efforts are going, how the sales efforts are going, and, you know, how we're doing in product and engineering and what have you. And when people can wrap their head around the whole machinery and how the, you know, where the bus is going, you know, they can do amazing things. Yeah. Nobody needs to tell them what those are, and they are paying attention, they're smart, and they figure it out. And so I really think it's like when you lose sight, when the product and the organization gets so big and so complex, that nobody can wrap it, you know, put it in their head on how all these pieces come together to make this thing successful. Like, you pull an engineer, you know, out of the blue, you know, you know, like working on the front lines of any given product, you know, at Google or Facebook and ask them. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. in my life that makes sense to me, that I think is scalable. The flip side you asked about is kind of like the UI, kind of like a consistency and like, you know, does it feel like one product or a whole bunch of fragmented things? You know, look, some products really need it and some products don't, right? You know, like AWS is one of those brilliant examples where at the end of the day, every product is an API first thing. It's not a UI first thing. And there are certain functions like marketing and design can be shared. But for the most part, the teams, you know, the GMs and the product and the engineering, everything is kind of like owned in a, you know, it comes together in, and so all the decisions are making happens very, very quickly and they don't need to build consensus with anybody else other than the folks leading a particular service or a particular part of AWS. I think, which is amazing. I think, I think that's a, that's a great model. But it only works in certain products, right? I think it'll be very hard to achieve, you know, pull that for every product where a consistent experience across all parts of the product is kind of very, very important. And so, so certain products and systems and platforms lend itself, you know, to be managed that way and they should take full advantage of that. And I think AWS is a shining example of that, in my opinion. And certain things don't, and those companies will always struggle, I would say, to innovate at maximum. We're going to take a quick sponsor break and then we'll come back to our interview with Venkat Venkat Armani. Monitoring a complex digital architecture takes a dozen different tools and troubleshooting means jumping between tons of dashboards and data. And that's why today's sponsor New Relic wants to change that and have designed everything for you that you need in three products. The first is a telemetry data platform, which creates a fully managed, schemaless time series database of all of your data from any source. The second is full stack observability for analyzing, visualizing, and troubleshooting your whole stack. And finally, applied intelligence that seamlessly automates anomaly detection and incident intelligence correlation using AI and ML. In other words, it's not just logs. It's not just getting alerts. It is much smarter than that. It's much more complete than that. And it's through your full stack. This is the way that you can get a handle on all of those errors, all of the performance data that you need. It's all in this one solution, I guess, three solutions. But under this one platform of New Relic, best of all, you can get it for free. There's no host based pricing and no constant upsell for more functionality with 100 gigabytes a month to one full access user. Head over to newrelic.com to get started today. Thanks again to New Relic for sponsoring today's episode of Developer Tea. I'm interested in understanding, you know, if you had, I typically ask this question for engineers, but I want to ask it more for team builders today for today's episode. If you had to give just a, you know, 30 second, clip of advice to people who are responsible for building teams, whether it's managers, maybe a founder, CEOs, those kinds of roles, what would you tell them? Be the shit umbrella. You should be invisible when the team is working really well. And you need to be front and center when in times of crisis, right? Take all the blame and none of the credit. And that's the ideal, you know, that's kind of like what, you know, that person in a leadership position doing their job in like 100% at level, you know, 10 or level, you know, at 100%. It can never be achieved, to be honest. But if you can get close enough, I think not only that the world's best individuals want to be part of your team, but they would work with you for the rest of their lives, for the rest of their career. Wherever they go, they're going to be part of your team. And they'll follow because they know you are invested in their success. And you're invested in their well being and happiness. And, you know, you're not going to be hugging the limelight and what have you. So yeah, be the shit umbrella and proudly so. That's excellent advice. I can imagine that there are engineering managers out there who know what this feels like. And I'm actually interested in one more question about that. Because you mentioned this, this kind of strange sense that I've gotten over my career, the invisibility. And this is this is me kind of playing the devil's advocate. How is it possible to show up to work to be productive, to be there every day, but also to remain invisible? What are you doing during that time? So invisible is not that you don't appear to work right invisible is about make sure that you know, you you give credit to always what it's due. At the same time, you may have taken the plunge and replaced your evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution is time to shine the spotlight, you are, you know, conspicuously absent and not because you're somehow manipulating because you genuinely believe that you have very little to do with it. And the team, you know, the team actually did that work. And so they deserve the spotlight. But when things don't work out, then suddenly you should suddenly, you know, your mind should warp itself and say, oh, shit, that's my responsibility. They, you know, the cannon pointing in the wrong direction was my fault. Now, when the cannon really fired and hit the target, you should kind of like say, oh, my God, that's an amazing cannon. Look how accurate that is. But when it's pointing in the wrong direction, it's like, oh, shit, I was the one, you know, that asked them to work on this in the first place. And so it's kind of my fault. And so when that lacks is kind of when you get into, you know, when leaders don't act that way, it's kind of like when things get very, very tricky. And so, yeah, I think, you know, it's not invisible. You know, being invisible doesn't mean you don't show up to work. It's really like there are going to be moments when, you know, either the hot seat is going to be present in front of you or a spotlight is going to be presented in front of you. They both are warm and glowy. You need to sit on one and be, you know, absent on the other. And that's kind of like really what matters. So I 100% agree with this, this perspective. For the sake of the people who are in middle management right now who are listening to this, I want to talk about what seems like the risk of this approach. And I want you to kind of walk me through why it's not a risk. All right. So I'm assuming that it's not. All right. Let's start with that. But taking on that persona of somebody who is a manager that they also report. To somebody, they're not at the top of the kind of the org chart. If we take this approach of not taking credit and being fast to take the blame, then it's possible I can imagine a scenario where it's possible that if I have a bad boss, especially if I have a manager that's that I report to that doesn't necessarily share that philosophy, that they will see. As an impediment or perhaps they'll see me as unnecessary, that the team is doing great. But anything that I ever hear from this manager is negative. Why is that? First of all, do you believe that that's a risk? And secondly, what do we do about it? That is 100% of risk. I absolutely agree with that. And I think especially when you are like a frontline manager or one of them, you know, as you said, a middle manager, you really it's very hard for you to kind of like change the culture of the company and how people look at it. I mean, like you have to adapt to it. And honestly, at that point, you have a choice. You know, you know, if I find myself in that situation, you know, ever, you know, I would say, again, it's probably the engineers kind of job security arrogance. But I will quit. I will not be able I will not be happy in that environment because that culture is not there. I will quit. I will not be able to I will not be happy in that environment because that culture is not there. I will quit. I will quit. I will not be happy in that environment because that culture doesn't suit me. And that, you know, what is celebrated in that environment and what is considered a taboo doesn't align with my worldview. And so I'll never be happy. And so I might as well do myself a favor. So, you have a choice to quit or, you know, do still what you believe and not be recognized for it and be okay with it. So, I think these are all very tough choices. I think, ideally, I think, you know, I would say, you should think about it. before you take the manager in a role transition, you should think about it. And do I really want to be, you know, a manager in this environment, in this culture? Also, before even taking the job, you know, some of these things are harder to figure out in the interview process and whatnot. So you have to kind of like do a little bit of extra work and spend more time with more people that would be your future colleagues and future manager. But I think you can actually figure this out even before you accept an offer. But there are definitely kind of like markers, like some of the things that we've covered in this program that you can try to ask and discover to figure out if this culture is going to be constructive or not. And so philosophically, I think a leader in any position or, you know, I also don't want to confuse leaders with managers. I think management and leadership are two orthogonal and important roles, but they don't have to, often, oftentimes, you know, at Roxette and other places I've been part of, I intentionally separate the two. The leads are different. The technical leads are different from the people managers and, you know, and the different, but primary and secondary responsibilities kind of like shifted. But I think, you know, coming back, I would say the thing that I would talk about in terms of, you know, what we do, you know, in leadership, any position of leadership, it kind of like go back to the basics. You know, what's a leadership? It's like, you know, the scope of what you're responsible for is way more than what you can do by yourself in a 24-hour period every day, right? So like, that's what gives you in a position of you being able to take ownership of something much, much larger than what you can do by yourself. And so if that's the definition of leadership, then that means you need to get, you know, really the power of, what you can do or the capacity of your team really goes down to how amazing a team you can bring together. Now, if you have the kind of core philosophies that I'm talking about, then you will be able to bring together a world-class team and out-compete whatever other team that is part of your organization or out-win and out-perform anybody's expectations there. And if the organization doesn't have the, you know, can't see, you know, white from black and right from left, then, you know, you really shouldn't be working there, in my opinion. But any organization with any sense will be able to see who are those winning teams and will be able to, you know, give more and more responsibility to them because they clearly have more capacity than what they're doing right now. And so I think kind of like going back even to the fundamentals, I really think it's hard to change the culture, but, you know, of a company. So if you're really stuck, you know, it's going to be, very hard for, there's no real clear, easy, and there's a lot of risks, as you point out. But in many, many situations, it may seem risky, but in practice, at the end of the day, if you can show better results than, you know, your peer teams and whatnot, you know, the recognition will come, the rewards will come, you know, pursue excellence, pursue bringing together an amazing set of people and support them to do their best work of their career. And I really believe the rest will take care of itself. It's almost like karma or something, you know, it will take care of itself. Hmm. Yeah. Yeah. It's kind of this interesting dichotomy between, you know, practicing the values that you want to practice and that kind of being a forcing function, right? You're kind of forced to find a place that will accept them. If you practice them and your organization doesn't tolerate it, then in a way, they've, you know, they're not going to be able to do it. So you've kind of done yourself a favor, right? You're now, you're kind of forcing yourself to find another opportunity that might tolerate your value or may align with your values a little bit better. Correct. So rather than trying to, you know, ask around, what are the values you can kind of practice yours? And if it turns out or practice your philosophy, and if it turns out that the organization tolerates it and perhaps even begins to adopt your philosophy as well, well, that was a good bet. If it turns out that they don't, it's probably also a good bet, right? It's a good loss because to our very beginning conversation, that is exactly what the growth mindset is about. It's about not trying to, you know, stick with whatever is true today as if it will be true forever. Just believing that the job that you have today needs to sustain you indefinitely is not only unrealistic, but it's also limiting, very likely, for most people. And I think that's the key. And I think that's the key. And I think that's the key. And I think that's the key. And I think that's the key. Whatever job they have today, they will not keep forever. It's incredibly rare, especially in this career path. So, you know, I think that that is a really critical message here. The growth mindset plays through all of this discussion. I'm really glad we started out with that conversation. Awesome. Thank you. I think this has been a fun conversation. I really enjoyed all the questions and the discussions and hope your listeners enjoyed this too. Thank you so much for joining me on today's episode, Venkat. Thank you. Another huge thank you to Venkat Venkataramani for joining me on today's episode of Developer Tea and on the last episode of Developer Tea. I was very thankful to have this excellent discussion with him. I hope you enjoyed this episode. If you did, I encourage you to subscribe in whatever podcasting app you're currently using. We have more interviews coming up between now and the end of the year. We've got a lot of new stuff coming up. We've got a lot of changes happening to the podcast and I hope you will tune in to hear more about those as they happen. But a lot of new things are happening with this podcast. We're not going away. We're not going away. That's the important thing. So I hope you will subscribe so you don't miss out on those updates, those changes to the show. Thank you so much for listening. This episode was produced by Sarah Jackson. Of course, today's sponsor was New Relic. We can't do this without our sponsors. And New Relic is going to help you. Understand your application with much better insight. Head over to NewRelic.com. Thanks so much for listening to today's episode. This episode and every other episode of Developer Tea can be found at spec.fm. My name is Jonathan Cottrell. And until next time, enjoy your tea.