Vox

Leitura de 37 min

Leading A Team During Difficult Times w/ Venkat Venkataramani (part 2)

Summary

In this second part of the interview, Venkat Venkataramani delves into the practical challenges of decision-making within engineering teams and larger organizations. He discusses the phenomenon of ‘bike shedding’—where engineers engage in philosophical debates without aiming for actionable outcomes—and emphasizes that clarity in the decision-making process and clear ownership are key to moving projects forward. Venkat argues that a relentless pursuit of consensus can be detrimental, especially as organizations grow, as it often stifles innovation and slows progress.

Venkat contrasts the agility of small startups with the inertia common in large corporations. He points to Amazon’s ‘two-pizza teams’ and the ‘disagree and commit’ philosophy as scalable models that empower small, autonomous teams to make fast decisions and own outcomes end-to-end. However, he acknowledges this model works best for products like AWS, where APIs are primary, and may be challenging for products requiring a highly consistent user experience across many teams.

A significant portion of the conversation focuses on the role of a leader. Venkat offers a memorable piece of advice: leaders should act as a ‘shit umbrella’ for their team. This means being invisible when things go well—giving all credit to the team—and being front and center to take blame during crises. He elaborates that this is a mindset of genuine belief in the team’s work and taking ultimate responsibility for failures.

The discussion also tackles the real risks for middle managers who adopt this philosophy in cultures that don’t value it. Venkat is pragmatic, suggesting that if a company’s culture celebrates the wrong behaviors, it may be a sign to leave. Ultimately, he advocates for practicing your leadership values authentically; this will either attract a team that excels and gains recognition or reveal a misalignment with the organization, prompting a necessary career move—a reflection of the growth mindset discussed earlier.

Recommendations

Companies

  • Amazon (AWS) — Highlighted as a shining example of a large organization that uses the ‘two-pizza team’ and ‘disagree and commit’ models to maintain innovation and speed at scale, particularly for API-first products.
  • Rockset — Venkat’s company, mentioned as an example of a small (30-person) organization where individuals have high autonomy and can see the impact of their work across the entire company.

Concepts

  • Bike Shedding — The phenomenon of teams spending disproportionate time debating trivial or philosophical details of a project, often without aiming for a concrete decision or action.
  • Disagree and Commit — A philosophy, cited from Amazon, where team members can voice disagreement but once a decision is made, they fully commit to executing it as if it were their own idea.
  • Two-Pizza Teams — Amazon’s model of creating teams small enough to be fed by two pizzas. These teams are autonomous and own a product or service end-to-end, enabling faster decision-making.
  • Shit Umbrella — Venkat’s metaphor for leadership: a good leader shields their team from external blame and politics (‘shit’) while giving them all the credit for successes.

Topic Timeline

  • 00:01:13 — Engineers debating principles vs. practicality — Jonathan opens by describing scenarios where engineers raise concerns as matters of principle rather than practicality, like disliking a framework. He outlines two desired outcomes: either resolving the concern through discussion or deciding to re-evaluate options based on new information. He then asks Venkat about the phenomenon of ‘bike shedding’—endless debates without a clear action goal.
  • 00:03:36 — Clarity in decision-making ownership — Venkat responds that the key to avoiding endless debates is clarity around the decision-making process. He stresses that for any significant change, it must be clear who owns the decision and is responsible for the outcome. Others can contribute, but the final call belongs to the owner. This allows for ‘disagree and commit,’ enabling the team to move forward and test ideas properly.
  • 00:05:05 — Challenges of cross-team impact — Venkat identifies where this model breaks down: when a complex project led by one team has major unintended consequences for many other teams (e.g., changing on-call procedures). In these cases, collaboration can fail if the driving team adopts a ‘convince me not to do it’ attitude. These are the trickiest situations in large organizations and often where ‘bike shedding’ debates fester.
  • 00:07:03 — The need for shared decision-making values — Jonathan builds on this, suggesting that without a shared decision-making protocol, philosophy, or set of values, teams can have two perfectly valid but opposing arguments with no way to choose between them. This leads to perceptions of favoritism or politics. He asks Venkat how to develop better shared decision-making frameworks.
  • 00:08:49 — Consensus as an impediment at scale — Venkat states it’s very hard and that he’s never seen a large company get it right. He argues that a natural tendency to build consensus prevents progress at scale. As companies grow and create accountable teams with KPIs, you empower many people to say ‘no,’ but it’s hard for anyone to say ‘yes’ to cross-team projects that risk their own metrics. This is why startups out-compete large companies.
  • 00:10:37 — Amazon’s model and small autonomous teams — Venkat cites Amazon’s ‘disagree and commit’ and ‘two-pizza teams’ as a pattern that comes close to solving this. By creating small teams that own a product end-to-end, you limit the number of decision-makers needed for consensus (to about five), enabling speed and innovation. He contrasts this with the impossibility of getting 15 or 20 people to agree.
  • 00:13:35 — Coordination vs. autonomy and decision types — Jonathan pushes further, asking if full autonomy leads to inconsistent products (like Google’s varied UX in the past) and if there are decision-making models beyond pure argumentation, such as democratic or meritocratic systems. He asks if small teams create fragile overall systems and how to coordinate large, cross-team efforts.
  • 00:15:58 — The boredom of big companies and visibility — Venkat reiterates that large companies become ‘boring’ and slow, especially for disruptive projects. He uses a thought experiment: an engineer at a giant company might not know if their absence for a year would have any impact, illustrating the loss of visibility into how individual work contributes to the whole. In a 30-person company, everyone sees the entire ‘machinery.’
  • 00:19:05 — When autonomy works and when it doesn’t — Venkat addresses the consistency question, stating that the autonomous team model works brilliantly for API-first products like AWS, where shared functions like marketing and design are minimal. However, it’s harder for products where a consistent cross-product user experience is critical. Companies requiring that will always struggle to innovate at massive scale.
  • 00:22:23 — The 30-second leadership advice — Jonathan asks for a 30-second clip of advice for team builders. Venkat’s immediate answer: ‘Be the shit umbrella.’ A leader should be invisible when the team is working well and front-and-center in a crisis. Take all the blame and none of the credit. He says achieving this ideal is how you attract and retain world-class talent who will follow you anywhere.
  • 00:23:58 — Defining ‘invisible’ leadership — Jonathan asks for clarification on being ‘invisible.’ Venkat explains it’s a mindset of giving credit where it’s due—having team members present successful work, not taking the spotlight yourself. When the spotlight is warm, be absent; when the ‘hot seat’ is warm (for blame), sit on it. It’s about genuinely believing the team did the work and you are responsible for failures.
  • 00:26:27 — Risks for middle managers — Jonathan raises a critical risk for middle managers: if they take blame and give away credit, a bad boss might see them as an impediment or unnecessary, only hearing negative reports. He asks if this is a real risk and what to do about it.
  • 00:27:42 — Navigating cultural misalignment — Venkat fully agrees it’s a risk. He says it’s hard to change a company’s culture from a middle-management position. If you find yourself in that misaligned culture, you have a choice: quit, or stay and practice your values without recognition. He advises figuring out the culture before taking a management role by spending extra time with future colleagues.
  • 00:30:08 — Leadership fundamentals and pursuing excellence — Venkat returns to leadership fundamentals: it’s about owning a scope larger than what you can do alone. Your capacity depends on building an amazing team. If you practice the ‘shit umbrella’ philosophy, you’ll build a world-class, high-performing team. Any sensible organization will recognize this and give that team more responsibility. Pursue excellence and support your team, and the rest (recognition, rewards) will follow.
  • 00:32:27 — Values as a forcing function — Jonathan synthesizes this into a dichotomy: practicing your values acts as a forcing function. If the organization tolerates or adopts them, it was a good bet. If not, it’s a ‘good loss’ that pushes you to find a better-aligned opportunity. This ties back to the growth mindset—not being attached to your current job forever, as career paths inevitably change.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2020-11-11T10:00:00Z
  • Duration: 00:35:39

References

Podcast Info

Transcript

[00:00:00] they’re motivated enough to bring it in almost every case that I’ve worked with, they’re motivated

[00:00:04] enough to be part of the solution. And you just have to empower them and support them and actually

[00:00:10] commit to addressing the issue. And it invariably makes the company and the organization stronger

[00:00:16] if you have that mindset. Welcome back to the second part of my interview with Vincad,

[00:00:25] Vincad or Armani. That was just a piece of what you’re going to hear in this episode. And I

[00:00:32] encourage you to go back and listen to the first part of this interview if you missed out on it.

[00:00:37] My name is Jonathan Cottrell. You’re listening to Developer Tea. My goal on this show is to help

[00:00:42] driven developers like you find clarity, perspective, and purpose in their careers.

[00:00:46] And I think Vincad can help you do that because he has led through crisis after crisis. And that’s

[00:00:54] some of the things that we talk about. We talk about bike shedding in this episode. I hope you

[00:00:58] will tune in very closely and listen to what Vincad has to say. Let’s get straight into my

[00:01:06] interview with Vincad or Armani. There are certainly times that I’ve experienced discussions with

[00:01:13] engineers where they were bringing up the discussion as a matter of principle rather than

[00:01:19] a matter of practicality. So in other words, they didn’t like that we were using a particular

[00:01:27] framework or something. And so they would voice that concern. And in my mind as a manager,

[00:01:36] I’m hoping that we come away with some kind of action to take. That’s my hope is that

[00:01:45] for somebody to voice a concern, hopefully there is either a discussion that resolves

[00:01:51] the concern. This framework actually does work well for this particular job because

[00:01:58] of X, Y, and Z. Oh, okay. We’re good to go. That would be a good outcome. Another good outcome would

[00:02:04] be, oh, you make a good point. So I think there’s certainly these two outcomes that we could have.

[00:02:13] We could either have an outcome where we resolve the differences and we continue on the path that

[00:02:18] we had planned. Perhaps you’re missing a piece of information I provided or I’m missing a piece

[00:02:24] of information you provided. And then we resolve somehow and nothing changes other than our mindsets

[00:02:30] or something else changes. We decide to review our options again. We say, oh, you’re right. This

[00:02:36] framework does have a shortcoming or perhaps we don’t know everything we need to make this

[00:02:42] decision thoroughly. But sometimes, and this is perhaps unique to engineers, sometimes engineers

[00:02:51] want to have this discussion almost as a point of philosophical debate rather than action.

[00:03:01] And I’m curious if you’ve ever seen this in other parts of your business or with a team

[00:03:09] that you’re working with, if there’s a bike shedding that happens where you’re going over

[00:03:15] the subject over and over and trying to get everything right or trying to get your point

[00:03:20] made, but really there’s no action particularly that anybody is trying to shoot for in the

[00:03:28] discussion. I totally hear you have been on both sides of that in terms of being part of discussions

[00:03:36] where it was happening with no clear consensus and the whole thing just festers for a while.

[00:03:43] The project doesn’t go anywhere. And I’ve also been on the other side where it’s been managed

[00:03:48] well. And I think it all came down to clarity around the process of decision making. I think

[00:04:00] basically in any situation, if there’s going to be a big change coming up,

[00:04:04] if there isn’t clarity on who gets to own it, who is responsible for that transition,

[00:04:12] for the change, for that new project to be delivered on time and with high quality.

[00:04:18] If it’s not clear who is owning it and then they get to make those decisions

[00:04:22] and you make it very clear, other people can contribute and be part of the discussion,

[00:04:30] but the final decision comes to the key person driving that. And then that is clear.

[00:04:36] Then I think things move forward and all these discussions at the end of the day

[00:04:42] hopefully informs the key decision maker to make a better decision.

[00:04:48] Even if you disagree, you disagree and commit and try to do as a company your best job and

[00:04:55] in giving it a real shot so that we have not a self-fulfilling prophecy or anything like that,

[00:05:00] but actually have a valid result, whether positive or negative.

[00:05:05] The places where I’ve seen it fail are the person introducing a very complex change,

[00:05:14] very complex re-architecture type of stuff. Yes, they are the ones driving it, but it has

[00:05:20] ramifications way beyond what they immediately control. It changes the way how the operations

[00:05:27] team do on-call. It changes the way how product teams do product management. It has ramifications

[00:05:34] way beyond their immediate circle of responsibility and they really want to push through the project.

[00:05:44] And you very quickly get to a point where you say, look, I’m going to go do it.

[00:05:52] It’s your job to convince me not to. That’s when I feel like the whole collaboration breaks down.

[00:06:01] I think those are the kinds of situations which are much,

[00:06:04] much tricky in a larger organization to deal with when your project has unintended

[00:06:12] negative consequences to a whole bunch of teams around you that you’re not fully weighing

[00:06:19] in your decision-making process. But in most places, it’s avoided by just making it clear

[00:06:25] on who’s responsible for making the decision and making sure that their decision only affects

[00:06:31] that portion of the thing that they’re responsible for. But then that is not clear or that cannot be

[00:06:37] achieved is where I think a lot of the stereotypical bike-shitting discussions happen

[00:06:44] because one organization wants to make a change that has a dire and negative impact on a whole

[00:06:52] bunch of other teams. I think the core of what you’re saying is so often forgotten

[00:07:03] that having a shared decision-making process, not even a process, it can be a shared decision-making

[00:07:11] philosophy, values that you share. All of these things play into coming to consensus.

[00:07:20] So let’s play this out a little bit. If you don’t have a shared decision-making protocol,

[00:07:26] whatever that is, if it’s values, if it’s soft, or if it’s highly technical, if it’s an algorithm

[00:07:32] that your business follows, or maybe you determine some goals and if you can’t tie a particular

[00:07:40] action back to those goals, then it’s off the table. There’s a lot of ways to do this,

[00:07:45] but if you don’t have it and you find yourself in a discussion or a heated debate between two

[00:07:52] options, then the reasoning provided, the logic that’s provided on either side of that may be

[00:08:00] completely valid. On both sides could be totally valid, and there’s no way to cut between those.

[00:08:09] Both sides feel like if you choose one or the other, because everybody agrees that there’s not

[00:08:16] one that’s clearly winning over the other one, that there’s some kind of favoritism involved,

[00:08:21] maybe there’s politics involved, but you can clarify this so much easier if you do have a

[00:08:28] shared decision-making protocol. I’m interested, first of all, if you agree with that, but secondly,

[00:08:36] how do you develop better decision-making, in particular, shared decision-making frameworks

[00:08:43] with your teams? Yeah, I think it’s very, very hard. I think, honestly, I have never seen a

[00:08:49] big company get this right. I actually think if you have a natural tendency to want to build

[00:08:58] consensus to make any decisions, you will never get anywhere. I mean, it’s just not going to happen

[00:09:03] because consensus is almost like a natural, it’s going to happen very naturally when you’re very

[00:09:10] small, so you don’t really need to even think about it too much. There’s only four people

[00:09:14] that are key in every decision, so you talk it out and you quickly figure out what to do.

[00:09:21] And as you get larger and larger, you do the same things. You want people to be

[00:09:27] accountable, have KPIs at the team level, at the org level. And when you have more and more

[00:09:34] people accountable for what they own, you’ve just empowered a lot of people to say no to things,

[00:09:40] except it’s very hard for people to say yes to things when it risks their KPIs.

[00:09:44] Why would I do it? That’s kind of like my team’s success and my reputation on the line and my

[00:09:51] team’s reputation on the line. And so I think it’s very, very, very hard to achieve in a big

[00:09:55] company. And this is why I would say this is why startups continue to out-compete and win

[00:10:01] large companies. So I think if somehow a larger organization can not get into this

[00:10:11] consensus building or the lack of consensus, becoming a roadblock for innovative projects

[00:10:17] that cuts through a bunch of different organizations or teams. If a larger organization

[00:10:26] can figure that out, I really think startups have no chance. So I haven’t seen any large

[00:10:32] organization get this right. The Amazon talks about disagree and commit, and there’s kind of

[00:10:37] like values that could be inculcated and the way AWS teams, the two pizza teams are ways to

[00:10:49] mitigate this by not creating large organizations that can say no to things by creating a large

[00:10:57] number of small teams that can own the entire decision, own the entire product end to end and

[00:11:03] move fast. And so that’s the only pattern that I’ve seen that actually comes anywhere close

[00:11:08] to becoming a practical way to build a large company that still has that kind of innovative

[00:11:14] mindset and quick decision-making. So there, I think it’s not really a consensus mindset.

[00:11:22] It’s just not hard to build consensus because you’re just only trying to get like five

[00:11:28] decision-makers to agree on something. When it is like 15, forget about it. When it is 15,

[00:11:35] it’s like already gone. And by the time you’re 20, you might as well go find another job to

[00:11:40] get anything done. So that’s kind of like what happens. And this is why people who want to build

[00:11:44] and get stuff done, they don’t want to work at a big company. They want to work at a company like

[00:11:48] Rockset with 30 people, because whatever you can imagine, you can work on it and you don’t even

[00:11:55] ask for forgiveness or permission. You just do, you just go and do it if you see a problem.

[00:12:00] And so I think, yeah, I think it’s just really hard. I think it’s almost, I would say if a big

[00:12:07] company says, oh yeah, we have a very consensus building culture, it almost means that they don’t

[00:12:12] innovate because innovation is also called disruption. And you can’t disrupt without

[00:12:22] having a controversial point of view. And those things are the ones that get shut down first in

[00:12:29] a consensus culture. Yeah, that’s a really good point that, you know, if you’re looking to make

[00:12:37] your team better, then it’s very unlikely that consensus is going to do that, right? That

[00:12:44] design by committee is notoriously, you know, is a negative thing, right? Yes. We don’t say design

[00:12:50] by committee and designers say, oh yes, that’s what I want. It’s very, very rare. So I want to

[00:12:57] push on this a little bit because I think there’s something interesting here about how

[00:13:02] do these big companies operate if they can’t build consensus? And I, you know, part of your point is

[00:13:08] that, oh, well, it’s, you know, one of the things that Amazon does as an example is they don’t rely

[00:13:15] on large teams. They rely on small teams and those small teams can, you know, potentially build

[00:13:21] consensus. Or if they can’t, then it’s a small enough bet that it fails and that’s okay. I’m

[00:13:27] interested in what you think about, you know, how do we coordinate large efforts cross team like this?

[00:13:35] Because you can see this actually happening. Like, for example, if I rewind a few years ago,

[00:13:42] back to, I don’t know, maybe 2015 or 14 even, a lot of Google’s products, this is a simple example,

[00:13:50] were very different UX from one product to the next. And it was very clear that they hadn’t

[00:13:57] had a project to kind of unify the design systems and the UX across all of their products.

[00:14:04] And I’m curious if you think that is, you know, that kind of problem is a risk of having all of

[00:14:15] these teams that kind of have ultimate autonomy over what they’re doing, right? Is that you don’t

[00:14:20] really have a consistent delivery or consistent product as a company if you do that. But secondly,

[00:14:29] I’m interested to know, you know, is there a way because I believe that if you were to look

[00:14:35] at consensus from the perspective of trying to win each other over in debates, right, in logical

[00:14:43] argumentation, that’s one kind of consensus. Another kind of consensus might be democratic

[00:14:50] consensus, right, is enough people say that they agree with this particular direction, then we’re

[00:14:55] going to go that direction. So there’s some kind of governmental way that we might handle this.

[00:15:01] There might even be a meritocracy where somebody who has worked on this the longest or who has

[00:15:09] the most experience in this area, they may help drive the decision or have more weight in the

[00:15:15] decision. So I’m interested to know, you know, on both of those fronts, I know I’ve asked you a bunch

[00:15:20] of questions back to back here. But the first question is, do you think that the small teams

[00:15:29] may produce inconsistent results between them, which could kind of create a fragile overall system?

[00:15:38] And then the second question is, are there other ways to generate good decisions beyond just

[00:15:46] argumentation? What kinds of ways do you think we could make better decisions together,

[00:15:51] even in those larger scenarios? Yeah, I think really interesting topics. So the first one,

[00:15:58] look, I think I’ve worked at larger companies and or companies that got very, very big.

[00:16:04] It wasn’t large when I started and like, you know, and it’s boring. It’s just really boring.

[00:16:11] It’s everything is slow. Anything that is, quote unquote, disruptive. Again, as I said,

[00:16:17] there isn’t no, there isn’t anybody you can go around and say, all right, if this fellow says,

[00:16:21] yes, we can do this project, except that there’s a lot of people that can say no,

[00:16:25] it’s not clear who can say yes, because it’s disruptive. So it’s just boring. And, you know,

[00:16:32] just to, you know, kind of like proof by example, give me one startup that has less than 100 people

[00:16:38] where you have the problem, where you can’t do something. And like, you know, so like,

[00:16:44] what is the framework that the startup using? No, it’s like, make the goals very clear on what

[00:16:48] the company needs to achieve. And everybody can actually see the machinations of every aspect of

[00:16:53] the company. And there’s clarity in terms of how the marketing efforts are going, how the sales

[00:16:58] efforts are going, and, you know, how we’re doing in product and engineering and what have you.

[00:17:02] And then people can wrap their head around the whole machinery and how the, you know,

[00:17:05] where the bus is going. You know, they can do amazing things. Nobody needs to tell them

[00:17:12] what those are, and they are paying attention, they’re smart, and they figure it out. And so

[00:17:16] I really think it’s like when you lose sight, when the product and the organization gets so big and

[00:17:22] so complex, that nobody can wrap it, you know, put it in their head on how all these pieces come

[00:17:27] together to make this thing successful. Like, you pull an engineer, you know, out of the blue,

[00:17:33] you know, you know, like working on the front lines of any given product, you know, at Google

[00:17:39] or Facebook and ask them what will happen to Facebook or Google if you don’t go to work for a

[00:17:44] year? Like, you just don’t show up. And, you know, let’s say they will continue to give you a salary

[00:17:51] for whatever reason, some setup. And do you think like it’ll have any impact? They won’t be even

[00:17:58] able to tell you what impact it’ll have because it’s so complex. Maybe there is impact, maybe

[00:18:04] there isn’t. Who knows? But the point being, it’s very hard to see that because it’s just

[00:18:10] gotten so big and so complex as an organization that I think, you know, it’s like very hard to

[00:18:16] see how this little gear or the little cog here actually matters. And it’s like if the machine

[00:18:22] continues to chug along, by induction, Google doesn’t need anybody, right? But it’s not really

[00:18:28] true, right? And so everybody has an impact, but it’s kind of like very, very hard to quantify.

[00:18:33] And so, but you come into a 30% company and you can see everybody, you know, you can see, you know,

[00:18:42] can see the whole machinery and participate. And so the long and short answer of that is

[00:18:48] it’s very hard to achieve in larger companies, which is why the AWS like kind of stoopies a team

[00:18:54] is the only approach that I have, you know, encountered in my life that makes sense to me,

[00:18:59] that I think is scalable. The flip side you asked about is kind of like the UI kind of like

[00:19:05] consistency and like, you know, does it feel like one product or a whole bunch of fragmented things?

[00:19:10] You know, look, some products really need it and some products don’t, right? You know, like AWS is

[00:19:17] one of those brilliant examples where at the end of the day, every product is an API first thing.

[00:19:21] It’s not a UI first thing. And there are certain functions like marketing and design can be shared,

[00:19:29] but for the most part, the teams, you know, the GMs and the product and the engineering,

[00:19:37] everything is kind of like owned in a, you know, it comes together in, and so all the decisions

[00:19:42] making happens very, very quickly, and they don’t need to build consensus with anybody else

[00:19:47] other than the folks leading a particular service or a particular part of AWS.

[00:19:52] I think which is amazing. I think that’s a great model, but it only works in certain products,

[00:19:58] right? I think it’ll be very hard to achieve, you know, pull that for every product where a

[00:20:04] consistent experience across all parts of the product is kind of very, very important. And so

[00:20:08] certain products and systems and platforms lend itself, you know, to be managed that way,

[00:20:13] and they should take full advantage of that. And I think AWS is a shining example of that,

[00:20:17] in my opinion, and certain things don’t, and those companies will always struggle,

[00:20:23] I would say, to innovate at massive scale.

[00:20:28] We’re going to take a quick sponsor break, and then we’ll come back to our interview with

[00:20:31] Venkat Armani. Monitoring a complex digital architecture takes a dozen different tools

[00:20:38] and troubleshooting means jumping between tons of dashboards and data, and that’s why today’s

[00:20:44] sponsor, New Relic, wants to change that and have designed everything for you that you need in three

[00:20:50] products. The first is a telemetry data platform, which creates a fully manageable schemaless time

[00:20:57] series database of all of your data from any source. The second is full stack observability

[00:21:02] for analyzing, visualizing, and troubleshooting your whole stack. And finally, applied intelligence

[00:21:08] that seamlessly automates anomaly detection and incident intelligence correlation using AI and ML.

[00:21:16] In other words, it’s not just logs, it’s not just getting alerts. It is much smarter than that. It’s

[00:21:22] much more complete than that, and it’s through your full stack. This is the way that you can

[00:21:30] get a handle on all of those errors, all of the performance data that you need. It’s all in this

[00:21:37] one solution, I guess three solutions, but under this one platform of New Relic. Best of all,

[00:21:42] you can get it for free. There’s no host-based pricing and no constant upsell for more functionality

[00:21:51] with 100 gigabytes a month to one full access user. Head over to new relic.com to get started

[00:21:58] today. Thanks again to New Relic for sponsoring today’s episode of Developer Tea.

[00:22:04] I’m interested in understanding if you had… I typically ask this question for engineers,

[00:22:14] but I want to ask it more for team builders today, for today’s episode. If you had to give

[00:22:23] just a 30-second clip of advice to people who are responsible for building teams,

[00:22:30] whether it’s managers, maybe a founder, CEOs, those kinds of roles, what would you tell them?

[00:22:36] Be the shit umbrella. You should be invisible when the team is working really well, and you need to

[00:22:47] be front and center in times of crisis. Take all the blame and none of the credit. That’s the ideal.

[00:22:57] That’s what that person in a leadership position doing their job at level 10 or level 100%.

[00:23:09] It can never be achieved, to be honest, but if you can get close enough, I think not only that the

[00:23:16] world’s best individuals want to be part of your team, but they would work with you for the rest

[00:23:22] of their lives, for the rest of their career. Wherever they go, they’ll follow, because they

[00:23:27] know you are invested in their success and you’re invested in their well-being and happiness. You’re

[00:23:35] not going to be hugging the limelight and what have you. Be the shit umbrella and proudly so.

[00:23:41] That’s excellent advice. I can imagine that there are engineering managers out there

[00:23:47] who know what this feels like. I’m actually interested in one more question about that,

[00:23:52] because you mentioned this kind of strange sense that I’ve gotten over my career,

[00:23:58] the invisibility. This is me kind of playing the devil’s advocate. How is it possible to show up

[00:24:06] to work, to be productive, to be there every day, but also to remain invisible? What are you doing

[00:24:13] during that time? Invisible is not that you don’t appear to work. Invisible is about

[00:24:20] making sure you give credit to always what it’s due. You don’t go and represent your team’s work

[00:24:28] as though it’s your work. It’s the mindset. You’re always getting your tech leads and

[00:24:38] engineers and other product managers in your team to go and present that massively successful

[00:24:43] product. You’re not the one presenting. Look at how awesome our strategy is that save the company

[00:24:50] and forget about all of that. When it is time to shine the spotlight, you are conspicuously absent

[00:25:02] and not because you’re somehow manipulating, because you genuinely believe that you have very

[00:25:08] little to do with it. The team actually did the work and so they deserve the spotlight.

[00:25:15] But when things don’t work out, then suddenly your mind should warp itself and say,

[00:25:21] oh shit, that’s my responsibility. The cannon pointing in the wrong direction was my fault.

[00:25:29] Now when the cannon really fired and hit the target, you should say, oh my God, that’s an

[00:25:34] amazing cannon. Look how accurate that is. But then it’s pointing in the wrong direction. It’s

[00:25:38] like, oh shit, I was the one that asked them to work on this in the first place and it’s my fault.

[00:25:45] When that lacks is when leaders don’t act that way. It’s when things get very, very tricky.

[00:25:52] So yeah, I think being invisible doesn’t mean you don’t show up to work. There are going to be

[00:26:00] moments when either the hot seat is going to be presented in front of you or a spotlight is going

[00:26:07] to be presented in front of you. They both are warm and glowy. You need to sit on one and be

[00:26:15] absent on the other and that’s really what matters. I 100% agree with this.

[00:26:22] This perspective. For the sake of the people who are in middle management right now who are

[00:26:27] listening to this, I want to talk about what seems like the risk of this approach and I want you to

[00:26:36] walk me through why it’s not a risk. So I’m assuming that it’s not. Let’s start with that.

[00:26:42] But taking on that persona of somebody who is a manager that they also report to somebody.

[00:26:49] They’re not at the top of the kind of the org chart. If we take this approach of not taking

[00:26:56] credit and being fast to take the blame, then it’s possible. I can imagine a scenario where

[00:27:03] it’s possible that if I have a bad boss, especially if I have a manager that I report to that doesn’t

[00:27:11] necessarily share that philosophy that they will see me as an impediment or perhaps they’ll see me

[00:27:20] as unnecessary that the team is doing great, but anything that I ever hear from this manager is

[00:27:26] negative. Why is that? First of all, do you believe that that’s a risk? And secondly,

[00:27:33] what do we do about it? That is 100% risk. I absolutely agree with that and I think

[00:27:42] especially when you are like a frontline manager or one of the, as you said, a middle manager,

[00:27:49] it’s very hard for you to change the culture of the company and help people look at it. I mean,

[00:27:53] you have to adapt to it and honestly, at that point, you have a choice.

[00:28:01] If I find myself in that situation ever, I would say, again, it’s probably the engineer’s job

[00:28:09] security arrogance, but I will quit. I will not be happy in that environment

[00:28:16] because that culture doesn’t suit me and what is celebrated in that environment and what is considered

[00:28:23] a taboo doesn’t align with my worldview and so I’ll never be happy and so I might as well

[00:28:29] do myself a favor. So you have a choice to quit or do still what you believe and not be recognized

[00:28:37] for it and be okay with it. So I think these are all very tough choices. I think ideally,

[00:28:44] I think I would say you should think about it before you take the role transition. You should

[00:28:51] think about it and do I really want to be a manager in this environment, in this culture?

[00:28:57] Also, before even taking the job, some of these things are harder to figure out in the interview

[00:29:04] process and whatnot, so you have to do a little bit of extra work and spend more time with more

[00:29:09] people that would be your future colleagues and future manager, but I think you can actually

[00:29:15] figure this out even before you accept an offer, but there are definitely markers, some of the

[00:29:21] things that we’ve covered in this program that you can try to ask and discover to figure out

[00:29:27] if this culture is going to be constructive or not and so philosophically, I think a leader

[00:29:37] in any position or I also don’t want to confuse leaders with managers. I think management and

[00:29:42] leadership are two orthogonal and important roles, but they don’t have to, oftentimes at

[00:29:48] Rockset and other places I’ve been part of, I intentionally separate the two. The leads are

[00:29:54] different, the technical leads are different from the people managers and the different

[00:30:00] primary and secondary responsibilities shifted, but I think coming back, I would say the thing

[00:30:08] that I would talk about in terms of what we do in leadership, in any position of leadership,

[00:30:19] it kind of like go back to the basics. What’s a leadership? It’s like the scope of what you’re

[00:30:26] responsible for is way more than what you can do by yourself in a 24-hour period every day, right?

[00:30:32] So that’s what gives you in a position of you being able to take ownership of something much,

[00:30:38] much larger than what you can do by yourself and so if that’s the definition of leadership,

[00:30:43] then that means you need to get really the power of what you can do or the capacity of your team

[00:30:50] really goes down to how amazing a team you can bring together. Now, if you have the kind of core

[00:30:58] philosophies that I’m talking about, then you will be able to bring together a world-class team

[00:31:02] and out-compete whatever other team that is part of your organization or out-win and out-perform

[00:31:09] anybody’s expectations there and if the organization can’t see white from black

[00:31:18] and right from left, then you really shouldn’t be working there in my opinion, but any organization

[00:31:24] with any sense will be able to see who are those winning teams and will be able to give more and

[00:31:31] more responsibility to them because they clearly have more capacity than what they’re doing right

[00:31:35] now and so I think kind of like going back even to the fundamentals, I really think it’s hard to

[00:31:41] change the culture of a company so if you’re really stuck, it’s going to be very hard for

[00:31:48] there’s no real clear easy and there’s a lot of risks as you point out, but in many, many situations

[00:31:56] it may seem risky but in practice at the end of the day, if you can show better results than

[00:32:03] your peer teams and whatnot, the recognition will come, the rewards will come,

[00:32:11] pursue excellence, pursue bringing together an amazing set of people and support them to do

[00:32:16] their best work of their career and I really believe the rest will take care of itself,

[00:32:21] it’s almost like karma or something, it will take care of itself. Yeah, it’s kind of this

[00:32:27] interesting dichotomy between practicing the values that you want to practice and that kind

[00:32:34] of being a forcing function, you’re kind of forced to find a place that will accept them

[00:32:41] if you practice them and your organization doesn’t tolerate it, then in a way you’ve kind of done

[00:32:48] yourself a favor, now you’re kind of forcing yourself to find another opportunity that might

[00:32:55] tolerate your value or may align with your values a little bit better. So rather than trying to

[00:33:02] ask around what are the values, you can kind of practice yours and if it turns out or practice

[00:33:09] your philosophy and if it turns out that the organization tolerates it and perhaps even

[00:33:13] begins to adopt your philosophy as well, well that was a good bet. If it turns out that they don’t,

[00:33:19] it’s probably also a good bet, right? It’s a good loss because to our very beginning conversation,

[00:33:27] that is exactly what the growth mindset is about. It’s about not trying to stick with

[00:33:33] whatever is true today as if it will be true forever. Just believing that the job that you

[00:33:40] have today needs to sustain you indefinitely is not only unrealistic but it’s also limiting,

[00:33:46] very likely for most people in their careers, whatever job they have today, they will not keep

[00:33:51] forever. It’s incredibly rare, especially in this career path. So I think that that is a really

[00:34:01] critical message here. The growth mindset plays through all of this discussion and I’m really

[00:34:06] glad we started out with that conversation. Awesome. Thank you. I think this has been a

[00:34:11] fun conversation. I really enjoyed all the questions and the discussions and hope your

[00:34:15] listeners enjoyed this too. Thank you so much for joining me on today’s episode, Venkat.

[00:34:21] Thank you. Another huge thank you to Venkat Venkataramani for joining me on today’s episode

[00:34:29] of Developer Tea and on the last episode of Developer Tea. I was very thankful to have this

[00:34:34] excellent discussion with him. I hope you enjoyed this episode. If you did, I encourage you to

[00:34:40] subscribe and whatever podcasting app you’re currently using. We have more interviews coming

[00:34:45] up between now and the end of the year. We’ve got a lot of changes happening to the podcast

[00:34:50] and I hope you will tune in to hear more about those as they happen. But a lot of new things

[00:34:56] are happening with this podcast. We’re not going away. We’re not going away. That’s the important

[00:35:01] thing. So I hope you will subscribe so you don’t miss out on those updates, those changes to the

[00:35:07] show. Thank you so much for listening. This episode was produced by Sarah Jackson. Of course,

[00:35:11] today’s sponsor was New Relic. We can’t do this without our sponsors and New Relic is going to

[00:35:16] help you understand your application with much better insight head over to newrelic.com. Thanks

[00:35:24] so much for listening to today’s episode. This episode and every other episode of Developer Tea

[00:35:28] can be found at spec.fm. My name is Jonathan Cottrell and until next time, enjoy your tea.

Visão de gráfico