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 Cutrell, I'm listening to Developer Tea, and 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 bike shedding in this episode. 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 have experienced discussions with engineers, where they were bringing up the discussion as a matter of principle rather than a matter of practicality. In other words, they didn't like that we were using a particular framework or something. So they would voice that concern. 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 work well for this particular job because of X, Y, and Z. We're good to go. That would be another good outcome would be, you make a good point. So I think there are 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 provide it 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 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 philosophical debate rather than action. And I'm curious if you've ever seen this in other parts of your business or with a team that you're working with if there's a bike shedding that happens where you're 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 trying to shoot for in the discussion. I totally hear you have been on both sides of that in terms of being part of discussions where it was happening with no clear 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 it's been managed well. I think it all came down to 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. If there is in clarity on who gets to own it, who is responsible for that transition for the change for that new project to be delivered on time and with high quality. If it's not clear who is owning it, and then they get to make those decisions. And it make you make it very clear other people can contribute and add, you know, be part of the discussion. But the final decision comes to the key person driving that and then that is clear. Then I think things move forward and all these discussions at the end of the day, you know, makes hopefully informs the key decision maker, make a better decision. And you know, even if you disagree, you disagree and come at and try to do as a company at your best job and in 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. 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 staff. Yes, they are the ones driving it, but it has ramifications way beyond what they're immediately control. They change the way how the operations team, you know, do on call. They changes the way the how, you know, product teams just product management, like it has ramifications way beyond their immediate, you know, 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. Your job, it convinced me not to write like that's when I feel like, you know, you kind of like the whole collaboration breaks down. And I think those are the kinds of situations which are much, much tricky in a larger organization to deal with when your project has unintended negative consequences to a whole bunch of teams around you that you're not fully weighing, you know, in your decision making process. And most places it's avoided by just making it clear on whose responsible for making the decision and making sure that their decision only affects that portion of the thing that they're responsible for. But then that is not clear or that cannot be achieved is where I think a lot of these, you know, the stereotypical bike shitting, you know, discussions happen because, you know, one organization wants to make a change that has a, you know, a dire and a negative impact on a whole bunch of other teams. Yeah, this is, I think the core of what you're saying is so often forgotten that having a shared decision making process and not even a process, it can be a shared decision making philosophy values that you share. 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. If you don't have a shared decision making protocol, right, whatever that is, if it's values, if it's soft or if it's highly technical, if it's algorithm that you take your business follows or maybe you determine some goals. If you can't, you know, tie a particular action back to those goals, then 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 heated to kind of debate between two options, then the reasoning provided, right, the kind of the logic that's provided on either side of that, maybe 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. And it's just interested, if, first of all, if you agree 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. 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 need to even think about it too much. That's only for people that are key, you know, in every decision, you know, so like, you know, you talk it out and you quickly figure out what to do. And as you get larger and larger, you know, you do the same things. You know, you want people to be accountable, have KPIs at the team level at the org level. And, you know, when you have more and more people accountable for certain, you know, 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 team success and my, you know, 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 in a big company. And this is why I would say this is why startups continue to outcompete and win large companies. So I think if somehow a larger organization can not get into this, you know, consensus building or lack of consensus, you know, becoming a roadblock for innovative projects that cuts through a bunch of different organizations or or or, you know, teams, you know, if large organizations figure that out, I really think startups have no chance. So I, I haven't seen any large organization get this right. You know, the Amazon talks about disagree and commit and there's kind of like values that could be, you know, inculcated and and the way, you know, AWS teams, you know, the two pizza teams and top, you know, or a waste to kind of mitigate this. By not creating large organizations that can say, notice things by creating a large number of small teams that can own the entire decision, own 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 that still has that kind of innovative mindset and and and quick decision making. So there, I think it's not really a consensus mindset. It's just not hard to build consensus because you're just only trying to agree, you know, get like, you know, five decision makers to agree on something. When it is like 15, forget about it. You know, it'll be a design. You know, when it is 15 is like already gone. And by the time you're 20, like, you might as well go find another job to get anything done. 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 Rockset with 30 people because whatever you can imagine, you can, you know, you can work on it. And you know, you don't even ask for forgiveness of permission. You just do. You just go and do it. And if you see a problem. And so I think, yeah, I think it's just really hard. I think it's almost, I would say if a big company says, oh, yeah, you have a very consensus building culture. It almost means that they don't innovate because innovation, but you know, it's also called disruption, you know, and you can't disrupt, you know, without having a controversial point of view. And those things are the ones that get shut down first in a consensus, consensus culture. Yeah, that's, that's a really good point that, you know, if you're looking to make your team better, then it's very unlikely that consensus is going to do that. Right. That design by committee is notoriously, you know, is a negative thing. Right. We don't say design by committee and designers say, oh, yes, that's, that's what I want. It's very, very rare. So I want to push on this a little bit because I think there's, there's something interesting here about how, how do these big companies operate if they can't build consensus. 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 interested in what you think about, you know, how do we coordinate large efforts cross team like this because you can see this. Actually happening like, for example, if I rewind a few years ago, 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 from one product to the next. And it was, it was very clear that they hadn't had a project to kind of unify the design systems and, and the UX across all of their products. And I'm curious if you think that that is, 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. A consistent delivery or consistent product as a company, if you do that. But secondly, I'm interested to know, you know, is there a way because I believe that if you were to look at consensus from the perspective of trying to win each other over in debates, right, and logical argumentation. And 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. So there's some kind of governmental way that we might handle this. There might even be a merit, meritocracy where somebody who has worked on this the longest or who has the most experience in this area, they may 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 the first question is, do you think that the small teams may produce inconsistent results between them, 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, even in those larger scenarios? Yeah, I think really interesting topics. So the first one, look, I think I've worked at larger companies and our companies have got very, very big. It wasn't large when I started and like, you know, and it's boring. It's just really boring. Everything is slow. Anything that is quote-unquote disruptor, 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 going to be a disruptor. 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 you have the problem. Where you can't do something and like, you know, so like, what is the framework that that's not up 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 then 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. Nobody needs to tell them what those are and they are paying attention. They're smart and they figured it out. And so I really think it's, 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, 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, a Google or Facebook and ask them what will happen to Facebook or Google if you don't go to work for a year. Like you just don't show up and, you know, let's say they will continue to give you salary for whatever reason, some, some, you know, some setup. And do you think like you'll have any impact, they won't be even able to tell you what impact you'll have. Yes. It's so complex. It may be that is impact. Maybe that isn't who knows, but the point being it's very hard to see that because it's just, it's just gotten so big and so complex as an organization that I think, you know, it's, it's like very hard to see how this little gear or the little call here actually matters. And it's like if the machine continues to chug along and when you, you know, you know, by induction, Google doesn't need anybody, right, but it's not really true. Right. And so, so everybody has an impact, but it's kind of like very, very hard to quantify. And so, but you come into a 30% company and you can see everybody, you know, you can see, you know, is is is can see the whole machinery and participate. And so, so the long and short answer of that is it's very hard to achieve in larger companies, which is why the AWS like kind of two piece a team is the only approach that I have, you know, in contact 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 consistency and like, you know, does it feel like one product or a whole bunch of fragmented things, you know, look, some products really needed 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 or the product and the engineering, everything is kind of like owned in a, you know, 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, a particular part of AWS, I think which is amazing. I think I think that's a great model. But it only works in certain products. Right. I think it'll be very hard to achieve or pull that for every product where a consistent experience across all parts of the product is kind of very, very important. So, so certain products, lens 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 massive scale. We're going to take a quick sponsor break and then we'll come back to our interview with thinkat, the Katarmani. 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 manageable, schemalist 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, so like it's 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. At 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 asked 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 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 Shadam Brahla. 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, 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. And whatever they go, 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 hogging the limelight and what have you. So yeah, be the Shadam Brahla and proudly so. That's excellent advice. I can imagine that there are engineering managers out there who know what this feels like. 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 give credit to always manage deal and you don't go and represent that your team's work as it's your work. It's the mindset. And so you're always getting your tech leads and engineers and other, you know, product managers in your team to go and present that massively successful product. And you're not the one presenting look at how awesome you know our strategy is that, that you know, save the company and you know, forget about all of that. You know, get, you know, when it is time to spot, you know, 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 actually, 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, we, it's the canon pointing in the wrong direction was my fault. Now, when the canon really fired and hit the target, you should kind of like say, oh my god, that's an amazing canon. Look how accurate that is. And then 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 I kind of my fault. And so, so when that lacks is kind of when you get into, you know, when leaders don't act their way is kind of like when things get very, very tricky. And so, yeah, I think, you know, it's, it's not invisible. This and you know, being invisible doesn't mean you don't show up to work. It's really like that 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. I 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 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, right, if I have a manager that's that I report to that doesn't necessarily share that philosophy that they will see me as an impediment or perhaps they'll see me as unnecessary that the team is doing great. 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? There is 100% of risk. I absolutely agree with that. And I think, especially when you are like a frontline manager or one of the, you know, as you said, 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, 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 doesn't suit me. And that, that, you know, what is celebrated in that environment and what is considered a taboo doesn't align with my world view. And so I'll never be happy. And so I might as well do myself a favor. So, 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, you know, I would say you should think about it before you take the manager in a role transition, you should think about it. 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 oftentimes, you know, at a drug set 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 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 in any position of leadership, it kind of like go back to the basics. You know, what's a leadership is 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. 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 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 outcompete whatever other team that is part of your organization or outwin and outperform. So 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 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 give more and more responsibility to them because they clearly have more capacity than what they're doing right now. 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 PR teams and whatnot, 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 is almost like karma or something, you know, it will take care of itself. Yeah, yeah, it's kind of this interesting dichotomy between 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 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. 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 in their careers, whatever job they have today, they will not keep forever. It's very incredibly rare, especially in this career path. So, you know, I think that that is, that is a really critical message here, the growth mindset plays through all of this discussion and really glad we started out with that, with that conversation. Awesome. Thank you. I think this is 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, Vinka. Thank you. Another huge thank you to Vinka, Vinka Ramani 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 and 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 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 newreleic.com. Thanks so much for listening to today's episode. This episode and every other episode of Developer Teacan be found at spec.fm. My name is Jonathan Cutrell and until next time, enjoy your tea.