Episode 42 | Mastering Leadership for High-Performing Teams with Sri Viswanath, former Atlassian CTO

Listen to this episode on your favorite platform!
April 4, 2023
54
 MIN

Episode 42 | Mastering Leadership for High-Performing Teams with Sri Viswanath, former Atlassian CTO

Former Atlassian CTO Sri Viswanath shares his lessons on engineering leadership, such as aligning goals, handling difficult situations, and optimizing team metrics. Jason, Eiso and Sri talk about their experiences with system failures and the importance of technical mentors and CTOs in promoting better leadership.

Here are a few of our favorite moments from the conversation

You have to have a lot in you as a person, but you don't have to have everything in you, because nobody does. Nobody is perfect coming out of the womb, coming out of high school, coming out of college or dropping out of Stanford, you have to continue to learn.

If you look at it as a CTO, you need to think about multiple dimensions of things. You need to think about people, growing the team, hiring, firing, promotions, mentoring, organizing, culture, people. All those aspects. Second is product, you need to care about customers, you need to deliver, you need to have a roadmap. And then the technology and the platform, how you will build things. And for each of these, you also need to think about the vision, you need to have a strategy for execution and then the actual execution.

It's easy to find leaders who have done something, but hiring a leader who has all the skills that we talked about and can work in a new culture that they come into and be very effective and liked by all the different 360, not an easy thing. And it's actually rare to find and those are unicorns and you need to hold on to them.

If you're in the executive room, you've got to understand what your team is, there's this concept of "first team" that's out there and stuff. If you're an executive, you're a company executive, not a functional executive. You happen to run engineering or sales or whatever, but you have to be oriented towards the company.

💡 Topic Explainers

💡 Training The Neural Net

A neural net is a term used to refer to a type of artificial intelligence that's modeled after the structure and function of the human brain. Essentially, it's a network of interconnected nodes, or artificial neurons, that are designed to process and interpret complex information.

In the context of building an organization, Jason like to call it "training the neural net", when he refers to teaching employees to think and operate in a specific way that aligns with the organization's goals and values.

This is his preferred way, where, instead of providing answers, this approach involves giving employees the inputs and frameworks they need to arrive at their own solutions, which can lead to greater success and growth for the organization.

💡 First-team and Second-team mode

First-team and Second-team mode are about a leader's mindset towards their team and executive group.

First-team mode means prioritizing the executive team and working towards common goals. Second-team mode can create conflicts between departments and lack of purpose in the organization.

In simple terms, leaders need to treat the executive team as their primary team, and their function as secondary, to create a healthy organizational culture.

Jason goes deeper into this idea on Episode 2: The Growing Pains of Company Culture and Episode 4: Rethinking Your Role as a Leader with Emil Eifrem from Neo4j

Episode Transcript

[00:00:00] Sri: One thing that I found extremely useful for me, when I was at Atlassian, and also I was on the board of Splunk when I was there, is to have a technical board member, right? That makes a big difference. And- and this is not obvious, and- especially public companies don't have as many technical people on the board. Having a technical board member, a formal adviser extremely important, a sounding board for both the CEO and the CTO and maybe for the rest of the organization.

[00:00:32] VO: Welcome to Developing Leadership, the podcast for engineering leaders where Eiso Kant and Jason Warner share their lessons on the ins and outs of managing software teams. Today, we have Sri Viswanath, former CTO of Atlassian on the podcast. Sri joins us to discuss leadership and engineering, and the importance of aligning engineering with company goals, dealing with difficult situations, and optimizing team metrics. The guys spoke about finding solutions after system failures, the need for technical mentors and technical board members, and how the role of the CTO should be elevated in the industry to promote better leadership.

[00:01:07] As always, this episode comes with accompanying show notes, with a deep dive into the main topics, mental models, and key moments from this episode. Find them at developingleadership.co and linked in the episode description.

[00:01:24] Eiso: Hi, everyone, welcome back on yet another episode of Developing Leadership. Today with us we have a special guest Sri, who is the general partner at Coatue and the former CTO of Atlassian, in a long line of a very impressive tech career. Sri, thank you so much for joining us today.

[00:01:40] Sri: I am excited to be here, let's do this.

[00:01:44] Eiso: Fantastic. We were having a chat right before this on where to start today, and- and you said something I'd love to talk about if engineering leadership is coachable, because that has played a big role in your story. I'd love for you to kick us off there and we'll see where we end up.

[00:01:58] Sri: Yeah. Absolutely, yeah, I definitely think engineering leadership is coachable. Leadership in general is coachable. It's my own story. If you go back I was an undergrad and I was walking with my friend, and my friend said, "Oh, I want to be a manager, I want to do my MBA and become a manager." And I looked at him and said, why would you do that? I would never be a manager, I don't want to be a manager." I was on a technical track, I thought I would be a distinguished engineer, just be happy on my own.

[00:02:30] And I had reasons for that. I didn't say it just because. And the reason I said that was I felt like I was not good in communications, I was not a leader. I grew up in a village a small town. I didn't have English until I was 12. There were lots of things that cascaded into my answer, and I left it at that. Then I came to the US. At some point I started doing my MBA goes to uh, a- all things, right? Considering I had said no. and I started learning the breadth of things that a leader needs to learn.

[00:03:02] And the best thing I had was I was at Sun Microsystems for a long time, for nine and a half years. I had amazing mentors there. N- not people who'd come in and say, "You need to do this and that," but I would watch them and I would know, oh, wow, there's also this way of doing things. I vividly remember one example where... This was, like, the first day of Star Wars release.

[00:03:25] [laughs].

[00:03:26] Must be, like, early 2000 something. On a Friday, we had six people in the team we had bought the tickets. We all met at the theater. And the manager came in and he said, "Oh, why is one person not here? Why is she missing?" And we said, "Oh, she had something to check and she can't come today." And he was like no, I need to go back and get her," so he- he went back and got her to the show, but we only had the six tickets. We didn't have a ticket for the manager. He sat outside while we watched the movie and then we came out, we had dinner.

[00:03:58] And I was like, why would you... I would never do that. I- I'm super passionate about Star Wars, I absolutely... We- we had waited for a month. And I realized, the basics of being a manager is to care for people. So there's these moments where it just defined me in terms of you need to care for people, you need to start leading by showing how you want to be led. Those things just cascaded in- and I had... I was in a startup after that, I had amazing mentors there in terms of how do you actually do [inaudible 00:04:51] things in terms of being a VP of engineering and things like that, where when you are a leader and you have to fire somebody, there are good ways of doing it and not so good ways of doing it.

[00:04:39] You- you... When you go through this, each and every step is actually coachable. And I learned it by being and having experience, and also having these mentors, and I- I guess resources to be able to know different options in the toolset to be able to use different things at different times.

[00:04:58] Eiso: I'd love to maybe throw two hard questions at you straight away. it sounds like you had, incredible journey where along the way you got to see a lot of great examples. but there's for sure a lot of leaders out there who didn't get to see a lot of great examples, and maybe today aren't on the path of being a great leader. Where do you go from there? 

[00:05:17] Sri: you are already helping out. This kind of podcast, just listening to different people doing different things, it's not that when somebody says, "I did this," you need to go back and do that. It's also one other option in your toolkit, And if you need to know more, you can spend some time exploring that option and figure out what happened. Having more options when you have to make a decision helps you make better decisions, right? You're not single threaded in terms of just doing one thing all the time, you always have, oh, maybe this time I should do this and adapt to a different option.

[00:05:50] Having those... Today is so different from 20 years ago, right? There's so many resources, there's so many things, and if people really want to learn, absolutely, you can learn. And that's one of the mantras I talk about when even in organizations for people continuous learning needs to be part of your daily life, right? And- and people un- underestimate how great is compounding effect, right? It's magic, right? 1% improvement a day gets you 37% improvement a year people don't realize. If you keep working on things that you think you are not good, or you need more options, you- you don't even know you will be better in a 

[00:06:29] year. 

[00:06:31] Jason: Something I'd add to that too, by the way. Yeah. Yeah, I was just going to say, something I'd add to that, I think you said something about 20 years ago versus now. Obviously a lot more resources available to people. One of the things that I think is very different today than it was 20 years ago, and I think people should take advantage of this, is the fact that they can basically j- subscribe to people on the inter, like podcasts or Twitter feeds or whatever and they could learn from them.

[00:06:59] It's we're- we're, you and I have CTOs of very large tech companies, here we are on a podcast talking about this, we're rather accessible too. People, someone DM's me and I'll answer a question, somebody emails me and I'll jump on the phone for five minutes if I can. It wasn't available. I- I didn't- I couldn't tell you the top 10 CTOs 20 years ago or CE- a CEO may have gotten in the press, but it wasn't available.

[00:07:21] And the other thing is I think that we've also demystified management and leadership a little bit too. As you mentioned at the root of it's about caring for people. None of these things are actually that difficult to d- go do, you just have to know to go to them and you have to consistently, every day, as you mentioned, 1% better every day, go and do them. And then I think that's actually one of the big unlocks that's happened.

[00:07:42] And I'll- I'll make one other comment too, which is I think unfortunately when we get to the topic of can this stuff be taught, there's a bunch of people, particular VC's, now- now, you and I are both VCs these days but there's VCs who say, "You can't teach leadership. You can't teach entrepreneurship." All that sort of stuff. And I- that's fundamentally not a thing that exists. Everyone can be taught a- a certain set of things, and I think that has to do with the fact that those VCs don't know how to do that. There's a couple of very famous firms that say that, "We'll never- we'll never invest in somebody who quote unquote, 'needs our help'."

[00:08:13] Realistically it's because you don't have help to give them. And the... I think this is an- something we should help people understand. You have to have a lot in you as a person, but you don't have to have everything in you, because nobody does. Nobody is perfect coming out of the womb, coming out of high school, coming out of college or dropping out of Stanford or whatever, you have to continue to learn. And if you don't, you're going to be a really shitty 50 year old, because you're going to be a 20 year old in a 50 year old's body.

[00:08:43] Sri: A- absolutely, I couldn't agree more. I- I spend most of my time advising leaders in a portfolio, we have 200 plus companies in our portfolio, and I spend a lot of time advising them. And the questions range from simple things to pretty nuanced, how do I handle this situation things. And it also depends on the size of the company. But every input that I give actually helps them instantly, right? Not because they follow what I say, but because it's also, "Oh, wow, I can also talk to two other people who have done this," and we connect a few other people and then they actually make decisions better. And that's something that, over time, I think they get- become a much better leader than if they didn't have these kinds of exposure. 

[00:09:30] Jason: podcast before, but we've never gone in depth, but I have this- this construct in my head about how I want to build an organization over time, and I- particularly at scale, and I call it training training the neural net . I need to train the organization to think a certain way anybody who's done AI stuff understands what I'm trying to say about this, and as in depth I can go into here.

[00:09:48] But the point is, it's not I'm ever giving somebody the answer, I'm giving them the inputs and I'm showing them how I might wait and model and blah, blah, blah, and decision trees around that. And once they do the work, from that they realize, "Oh, wow, I understand the problem now, and I understand who I can go ask," and, again, those are unlocks. And I think that's an amazing thing, I- I love the fact that, I remember when I sa- saw you get up go over to Coatue, I was like, this is going to be great, because another one... Tim Tully, another mutual friend of ours over at Menlo now.

[00:10:18] A couple of CTOs in portfo- in- at firms who are helping folks, who are doing the sa- the exact same thing. We're investing infrastructure, but these technical CEOs or tech- technical co-founders and stuff finally have people they can go talk to.

[00:10:30] Sri: Absolutely, yeah.

[00:10:31] Jason: Sri, 

[00:10:32] Eiso: We've been talking about learning and- and leadership being coachable. I do want to throw kind of one curve ball question at you before we go on to another topic. You mentioned you did an MBA. With everything that's out there today, would you still recommend a young engineering leader to- to go down the path of an MBA?

[00:10:49] Sri: Tha- that's a great question. It really helped me in a couple of dimensions. One is I was a pure technical leader, and getting exposure to marketing, business, finance, just made me a better CTO. Just to be able to have a positive conversation with a CFO, with marketing department, understanding the nuances of what they do was super helpful. And the second thing it helped out was, since I did it in Stanford, all the classmates there, who's who in different places and the connections absolutely helped out.

[00:11:27] I would say for people who are considering MBA, it depends. Depends on what you want to do. If- if you want to start a company and if you are trying to do an MBA, that doesn't seem right? If you want to do a startup. But if you are have a ambition to improve certain things or learn broader and maybe go into a different field and others, it's definitely uh, it's definitely useful, but depends on your case.

[00:11:49] Eiso: 

[00:11:49] We've talked about everything that you've learned and where you've gotten to today but now you sit in the seat where- where you're the- you're giving the advice. What are some of the most common things that you are seeing at different stages now as an investor on the other side of the table, that you wish, engineering leaders would level up on? And maybe that links to thinking about the rest of the business as well.

[00:12:12] Sri: Yeah. Yeah let's focus on the CTO role for a second, and then we'll come ba- then we can generalize this. Whe- when CTO roles are fuzzily defined and means different things at different stages let's combine CTO and the VP of engineering to run engineering as well. If you look at it as a CTO, you need to think about multiple dimensions of things. You need to think about people, growing the team, hiring, firing, promotions, mentoring, organizing, culture, people, right? All those aspects Second is product you need to care about customers, you need to deliver, you need to have a roadmap, All the things about building your product. You need to have good practices in place so you can actually execute on many of these. And then the technology and the platform how you will build things. And for each of these, you also need to think about the vision, you need to have a strategy for execution and then the actual execution.

[00:13:08] The- there's different dimensions for each of these. And then there... I think about this as then there is the general management leadership capabilities in terms of how do you communicate what judgment do you have, how do you make decisions, how do you inspire people? The- all the personality aspects of things. And when you are at a different stage of the company and when you are leading, let's say you are a 10-person startup, the skillset you need as a CTO is very different from what you need when you are running a 5,000-person organization, right?

[00:13:41] I was in a startup a while ago. And my team was, like, five people, and if I reflect back I would do code reviews every day, right? I wouldn't write code, but I would do code reviews, I would be in every single architecture decisions and discussions. Not so when I was running 6,000% organization at Atlassian. Tha- that was very focused on people, organization, culture, a small portion on technology, but you relied on people, right? That's why all my blogs and everywhere I talk about getting the right people on the bus.

[00:14:11] Yeah.

[00:14:11] And then figuring out where to go, because people matter. And it matters in a 10% organization, it matters in a 5,000% organization, especially the leadership. I think people underestimate the impact of the leaders that CTO or VP of engineering has in terms of being able to execute, because when you are running a 6,000% org, you can't be in details of everything. You don't make all the decisions. You try to set a culture and a system in place, and you need the feedback loop from your directs to be able to tune it, otherwise it just goes somewhere that you don't expect it to be.

[00:14:47] Eiso: Can you give us a highlight? And what I mean with a highlight is, very few people listening to this by sheer numbers will- will have run a 6,000% engineering organization like, like Atlassian. If you look back at, maybe it's- maybe it's the top one, maybe it's the top three of- of decisions that you said, "There, I was instrumental in making them," that worked out. And maybe there are some that you say, [laughs], that you were instrumental in making and had the complete opposite effect, but I'm curious, what are the ones that you think back on very, yeah, proudly?

[00:15:15] Sri: Yeah. No, I'm- I'm proud of the six and a half years I was at Atlassian. Amazing company. I got to be in the cloud journey, I got to build out cloud at Atlassian from scratch. Atlassian used to be an on prem company. There was a single tenanted cloud system, but I got to build the next gen multi tenanted cloud. I made decisions starting from where to run the cloud, how to set things up, building out different dev centers I started the Mountain View office, I started the India office afterwards, so built that out to get to that scale.

[00:15:48] Every decision in this set of things, the- they were hard decisions in terms of do you go native on AWS or do you have an abstraction layer and arbitrage between multiple... We even, for Atlassian, it made sense, we went all in on AWS, and we did some blogs on that too. So there were all these decisions that I'm proud of, but the best thing I'm proud of which can't be showcased as much is the leadership that I during that time, right? The leadership I built in the first year as we came in and we called it the CTO leadership team was the best I had in terms of just being able to scale that org.

[00:16:24] And these leaders took on bigger and better pro- projects and roles and helped shape the organization, and b- bring in more amazing leaders. And tha- that scaled, th- the- the most proud of is my leadership team and we still are super close. And of course Atlassian has this amazing teamwork culture, and it's not just the CTO org, we worked super closely with the rest of the organization, the rest of the executive team. And we always optimized for the company. M- in some cases it made us work slower, because we had to optimize f- globally, not locally, but that definitely helped us to move all in unison, which is one of the underestimated things where engineering orgs generally want to run fast.

[00:17:11] And even the metrics that you see are all good DORA metrics and others, you can optimize things. But if you don't align with the complete org, you don't achieve the company level OKRs, you get to do fast somewhere, but it's not aligned with that, so that alignment is extremely important. And I think we did a pretty good job having the teamwork and the culture at Atlassian.

[00:17:32] I 

[00:17:32] Jason: love the focus on the global versus local. It's- I think it's an important distinction that many engineering leaders don't see sometimes. And- but i- glo- at the global level this is something that we- we've talked about, again, on this podcast a couple of times, but is if you're in the executive room, you've got to understand what your team is, and what you call... There's this concept of first team that's out there and stuff, but the idea being that if you're an executive, you're a company executive, not a functional executive. You happen to run engineering or sales or whatever, but you have to be oriented towards the company.

[00:18:03] And, again, that nuance seems to be lost on a lot of folks, and at bigger orgs it becomes a little bit more political too. But there's this sweet spot where I think it- it creates a magic alignment with people and it's- the most fun environments to work in and when everyone realizes that the- inside the email domain is sacrosanct and that we're all fighting for the same things, it's- for the of the company. So I'm glad you called that one out.

[00:18:26] Sri: Yeah, a- a- and it's funny pe- people ask this is my number one question that I get, saying, "Oh, I don't know if my..." And especially from non-technical founders, saying, "I don't think my engineering is running fast, what metric, one metric, can I use to show that... I don't know, optimize it."

[00:18:42] [laughs].

[00:18:43] I- I wrote a pa- a blog on this recently, on productivity. Do- the- the big summary of this there is no one metric that you can optimize and actually create an amazing culture. Like Jason said, it's a neural , it's a optimization on multiple dimensions and it depends on the company. The thesis of that paper is it's good to measure a lot of things and then figure out what matters to you as a company. And also, when you're optimizing, and this is something, the learnings that I've had too, is it's not just at the global level.

[00:19:16] Every team may have different optimization functions. Some team may be really good in execution but may not have customer input, they're not connected to customers. Some teams may have lots of debt that they have to remove before they can move faster. There are different optimization functions for each of the teams, and that's something that CTOs should be extremely aware of and should be able to articulate to the rest of the team, because it's... Engineering is- looks like a black box from outside and it's hard to explain why things are what it is, and it's important to be able to break it down and explain different ways.

[00:19:50] And in- in that paper I... At Atlassian we did this, which worked extremely well. We categorized for each team on how- what percentage of their time they are making progress towards our OKRs and goals, and what percentage of time they are doing keeping the lights on work. And it was fascinating to see, some teams were really good, especially new teams that didn't have debt, were really good, some teams were really bad. But at least it gave us a vocabulary to explain, saying, look, the reason they are slow is because... And we could explain and say, to get to the next point, you actually need to invest more, which means it's slower in the short term and then it speeds up afterwards, which is a concept that it's hard to understand if you don't realize what goes on underneath.

[00:20:34] I- 

[00:20:35] Jason:

[00:20:35] Eiso: really appreciate that approach, Sri. I want to- I want maybe put us in a- in a bit of a different direction for a second. You- you built up this incredible team around you, you were- you were six and a half years at Atlassian you went through the moving to cloud. There have to have also been moments where, you wake up at 04:00 in the morning worried and I'm not going to ask you about exactly the y- the cases and the moments that those were. What I find more interesting is how did you as a person manage those and- and how frequent were they and in which situations were they? Because I think there's a lot of people listening to this who- could benefit from kind of your advice and your journey 

[00:21:13] Jason: there.

[00:21:15] Sri: Yeah. That's a great question. Of course, if you have run a cloud organization, you have scars, right? [laughs].

[00:21:21] [laughs].

[00:21:21] You have woken up at 04:00 AM or stayed all night just to handle situations. And we have had a number of those too, especially when you build from scratch and you have- you have migrated 100,000 plus customers onto the platform, ge- growing at 40% whatever, per quarter, per year. So tha- that I think I'll take one example that happened maybe a year ago, year and a half ago, to- maybe some time before I left. And thi- this was a self inflicted wound, right? In terms of there was one engineer who ran a script, I know Jason is thinking of some examples in his, [laughs]... [inaudible 00:24:10].

[00:22:01] [laughs].

[00:22:01] Every story starts with one engineer ran 

[00:22:02] Jason: a script.

[00:22:03] I- I'm- I just started to sweat, I just started to sweat.

[00:22:03] [laughs].

[00:22:03] [laughs]. I know, right? Uh, so ran a script, that they'd run it 

[00:22:12] Sri: before lots of times this was- wasn't, and we- we had- we had pride... We- we were proud that we had run all these tests and backup and recovery for all our subsystems and overall, like we do vigorously every every month. And we met certain standards, we guarantee this and this for the customers we had all of that. It was a bit different this time. Somebody else had run a slightly different script before that changed the parameters of the production.

[00:22:40] [laughs].

[00:22:40] And when they ran it it- it was to delete some old records that didn't make sense. It also deleted some records in different databate- bases in microservices architecture, it deleted multiple places. A- and suddenly we had a... It was a small percentage of customers it was like point zero something percent. But, still, it's N number of customers that their records, their data just vanished, right? We had the data, we had everything, but to recover consistently across, we had a microservices architecture with hundreds and hundreds of microservices with databases running in production. That took us a long time to recover. And we in fact wrote a postmortem on this, and that's something that I strongly advise for any company to follow.

[00:23:34] Yeah.

[00:23:34] [inaudible 00:25:48] having retros, having, having retros that are not... Blameless retros. There's... It's easy to start blaming engineers, so one of the mantras that we had during that, and you'll see that in the writeup too, is we said the fault is not of the engineer but is of the system. Because engineers run script, that's what they did, they had been running it for a while. It- the reason it crashed is not because of the engineer, it's because we didn't have the rest of the systems supporting the engineer, right?

[00:24:01] We were very clear on not highlighting who the engineer was, not... Making sure that the engineer felt like they won't be, like, fired right there, but to rally everybody else to say, "These things happen, let's go fix this, we have customers that are suffering right now without data." it took us a while to be able to recover from this, but we learned a lot, we got more resilient, we wrote out an external blog for this, and lots of scars for us who were internally inside 24 by seven no- sleepless nights. But we also rallied the rest of the organization we worked super closely with the marketing department to be able to communicate and customer support, and that actually brought us together and became a better engineering organization after that. Painful though.

[00:24:46] Jason: I'm- I have a story similar, which is why, we have a bunch, right? Obviously we're going to... But we, GitHub, did a very public postmortem on a 24 hour outage. It was in 2018, and I remember it very vividly because we were maybe weeks away from finalizing the acquisition by Microsoft. And I was, I was on a- I was in Hawaii on a long awaited family vacation. And I got a call while I was at the top of a mountain from our head of infrastructure saying, "Hey, do you know what's happening right now?" And I'm like, "No," Someone in one of our data centers, not- not a GitHub employee, but somebody else kicked out a cable, took down the entire data center, specifically our rack went down.

[00:25:26] We had a split brain situation with something failing over to the, a different cluster. We plugged it back in, things- things got messed up. And y- you learn a lot about your organization and how you're going to handle stuff in that moment, that's when... And- and when things go poorly is when you start to realize a lot, whether or not things were put in place. And here's- here's the thing, anyone listening to this, and I- I hope CEOs are listening to this too, is that you can't account for everything in your systems. There's never a world, and this is something that maybe non-technical CEOs, and GitHub, as weird as it sounds, had a history of having non-technical CEOs is you don't know everything.

[00:26:03] You can't possibly. You can try to account for a lot, but there's always something that can drastically go wrong. And the... It's how you respond to those that's going to be what your organization and your culture is going to be. I think we should link both of these postmortems for people to read through, so you can see how we talked about that. But internally you have to understand what was happening too. And internally I'm assuming it's- it's similar, giving what Sri has said here, it's focus on the problem, focus on the solution, focus on the customer, focus on, staying true to the principals that we adhere to, no data loss or, all that sort of stuff, there's a whole bunch of different things. But, you... Tha- that's when- that's when you find out who you are and what kind of company you are.

[00:26:44] Exactly, 

[00:26:45] Sri: yeah.

[00:26:45] Eiso: Both of you became VCs. We can't ignore that fact, it's rare to have VCs on an engineering leadership podcast. Now, I- I wo- I won't dig in to the why, I know Jason's why. I- but I'm more curious, now you've been on the other side of the table, is there something non-obvious, Sri, that you learned, and I'll ask the same for you Jason that you wish you would have known as a CTO at any of the... Or- or a- just as an engineering leader in general?

[00:27:08] Jason: Tha- 

[00:27:09] Sri: that's a great question. The- the one thing that I see is engineering, just overall technical departments, have more issues than I had imagined, especially even in smaller companies.

[00:27:25] Yeah.

[00:27:25] People issues, scaling issues. Just leaders not knowing how to navigate that. And we talked about this, having good mentors helps out, and that's why I feel like, I- feel fulfilled by the end of the day because I feel like I'm helping these founders and I'm passionate to make them better. And whether it's a technical founder or other, whether it's a CTO, having these conversations helps them a lot. But I'm actually surprised, and I'm glad I'm doing this and I'm sure Jason has this too, where it- it feels like finding an amazing leader or hiring somebody from outside is not easy.

[00:28:03] It's easy to find leaders who have done something, but hiring a leader who has, like, all the skills that we talked about and can work in a new culture that they come into and being very effective and liked by all the different 360, not an easy thing, right? And it's actually rare to find and they're- those are unicorns and you need to hold on to.

[00:28:25] Jason: I have a bunch to say on this topic, but I think two things that I will 100% re- confirm what Sri said, is that more tha- often than not, engineering teams have issues. You... We- we like to really in Silicon Valley say this team is exceptional or this organization is, they are, but there's issues inside there. I would say the other is this is surprising to me and maybe disappointing too, is how little we the VCs, end up understanding the tech side of the companies that they're investing in. They talk a lot about the CEO, they talk a lot about the revenue leader we- we dive into the go to market strategy, we dive into market differentiation, but we get very little insight into the tech.

[00:29:02] And I think largely because, one, the VCs themselves don't really understand the tech, but two, ultimately a lot of those... The tech can be covered over in go to market. You can just buy your way to market share in a lot of cases, you could... Particularly in a zero interest rate phenomenon environment where you could pay $2 to make $1, and that was very acceptable for a period of time.

[00:29:22] The other thing I will say though is I think thi- I think this has been confirmed in my 18 months, almost two years, of doing this now is and this is going to be controversial f- when I say this, I think it's infinitely harder to hire a competent CTO for an organization than it is to hire a competent CEO. And I think there's just so many more people out there that are able to do a CEO job than there are able to do a CTO job. I think the CTO, at a scale, job, credibly, is a unicorn. And, revenue leaders, they're different. CTOs, po- and particularly CTOs that can run product or have some sort of product orientation or at least security, infra, and all the other application engineering, there's- there's not that num- the- the same number of people out there that are capable of doing that.

[00:30:05] I... 

[00:30:05] Eiso: Sri, we're calling you a unicorn here as well.

[00:30:08] [laughs].

[00:30:08] And- and, but we're also saying it's highly coachable, it's highly teachable. How How do we get more pro engineering leaders in our industry? And- and I'm going to asterisk that with not the non- not not the obvious answer that ChatGPT will tell us, right?

[00:30:24] Wa- we need more content, we need more people speaking up and, like, all of that kind of stuff we- I mean, we... Wha- what is it that we could be doing according to you that might not fall in that obvious answer?

[00:30:36] Sri: O- one thing that I found extremely useful, for me, when I was at Atlassian and also I was on the board of Splunk when I was there, is to have a technical board member, right? That makes a big difference. And- and this is not obvious, and- especially public companies don't have as many technical people on the board. Having a technical board member, a formal adviser extremely important, a sounding board for both the CEO and the CTO and maybe for the rest of the organization. AI is coming to every single org, and we can talk about specifically where and how. Somebody who understands data and AI and technology-

[00:31:17] Is going to be even more 100 times more critical in the near future than it has been. It's always been important, but it hasn't been as impactful because people we- can figure out, without that. But it's going to be a huge... A- and the other thing that's also happening is I- I said earlier, exponential and compounding is magical. And it's happening in technology, right? It's changing so fast that even technologists are not able to keep up with what's happening, right? To c- I've spent the last seven months in AI.

[00:31:48] And I feel like I've learned a lot, but I feel like I always get behind. Every week there's so much happening, every day. It's a amazing time to live in, but if you reflect back to that question think about if you have, you are living in a bubble without having a technical board member it's going to be much harder to navigate the scenario that's coming up.

[00:32:08] I have, 

[00:32:09] Jason: The- the public company or the- the technical board member comment is spot on. It- it is unbelievable to me, I think it's a fiduciary malfeasance situation, for what it's worth, for public companies not to have technical people on the board. I think that's incredibly shortsighted and I think it would be great if the industry recognizes that. My answer is going to abstract up one level I think, and what I imagine we would need to do is we need to change the incentive structures to a degree.

[00:32:36] W- i- if CTOs became stars in their industry the way that CEOs have be- been for the last 20 years I think that our- our industry would be 100%, 100 times better off, from it- from a technical leadership perspective and thought leadership perspective. And there's a lot of, like negati- negative aspect of what I just said too, because there's some Machiavellian things that will happen with it. But the point being that very technical people who have leadership acumen and who have been learning to do those sorts of things or have been taught or mentored into them, over the last 20 years, have switched tracks most of the time.

[00:33:10] They have not stayed as the technical leader and they have not continued to do that because ch- in Google, jumping from technical to the product side of the fence meant you're probably going to get a highe- d- more dollars or bigger- bigger roles or whatever. Or jumping from the C- the T- TO to the CEO of a startup or something like that, and, yes, that's maybe a structure that works for the VCs of the world, now that Sri and I are on that side of the fence, because people [inaudible 00:36:43] found companies. But it hasn't worked out for a lot of the big companies and, you- if you walked into a lot of the very large companies in the world at the moment and you talk to people, you're going to be very impressed with the revenue leader.

[00:33:44] Yeah.

[00:33:44] The CFO is going to be amazing. CEO is probably pretty good. You talk to lot of the engineering leaders, and you'll be like, where did this person come from? No way that they should be running 10,000 people and that sort of thing. And that's across the board.

[00:33:56] Eiso: Would you tend to agree, Sri? Walking in a pub- ta- take the S&P500 and their CTOs?

[00:34:01] Sri: I- I definitely agree. I've actually seen wha- what happens in... I- I would also say it depends also o- it's more acute in different types of companies.

[00:34:10] Yeah.

[00:34:10] If you go in the stack, generally the lower infrastructure companies have solid CTOs.

[00:34:18] Yeah.

[00:34:18] And they are generally given more prominence. If you go up the stack and you go to application companies, where it's also important because technology drives quite a bit, it changes a- a lot. Different industries have different, and the type of CEO also depends on who they lean on. The- if they lean on the CTO a lot, that generally gives prominence for that person in the organization.

[00:34:40] Yes.

[00:34:41] If they don't. But in general the sentiment that having an awesome CTO and elevating the profile will make the company better, I 100% agree.

[00:34:50] Eiso: I know all three of us on this call are spending a lot of time on- on AI for a while and it's actually how... Jason, I think we said we were going to tell Sri... M- tell the story one day, but it's actually how Jason and I met but we'll keep that story for another day. I'm curious, Sri, w- there's a lot out there being spoken on how AI is coming for lots of parts of businesses, but I see... I don't think I've heard anyone speak yet about how it's going to be impacting the engineering leader's role uh, as a user themselves. And I'm curious if you've given that any thought, and you Jason, and get your- your perspective on that. How does our role change? Because everyone's role is about to change.

[00:35:26] Sri: Yeah. F- I think the first wave that's happening is to have a Copilot for different actions that you take, which makes you a lot more efficient in what you do. And what'll end up being is there's going to be a Copilot for hiring, Copilot for doing promotions, Copilot for the product side, Copilot for the practices, co- or maybe there's one, there's many, but it's going to help you become more efficient and to be able to scale much better. There are some things that, at least in the near future, the judgment, creating a good culture, caring for people there are a number of things that a leader needs to do, like inspiring people, that AI won't and can't do and may even hurt in some cases.

[00:36:11] But on a overall sum, it actually is going to make a leader much more effective. I'm actually bullish on AI across the board, not just the CTO or engineering leader, but every leader in the company, every engineer, every person and employee in the company, every company it's going to make us more efficient across the board. And we just have to navigate it. And technologists do this, right? And- and it's happened lots of times before, in every case it feels like it gets over hyped, people expect a lot more and then it doesn't do, and people feel like, ah, it's all bogus, it's not happening.

[00:36:46] And then it comes up and just starts taking over and replacing previous technology, previous... AI, this time, is actually being useful from day one, right? It's not just that curve, but in that curve, people are using these technologies today, right?

[00:37:01] Yeah.

[00:37:01] Co- Coatue is an investor in many of the AI companies, even before I started, and I've invested in many of them, and I see customers using the product and being very productive by using the product. And that's only going to be much bigger, better in five 

[00:37:16] Jason: years.

[00:37:17] I think one, how- how to- as if you're a technical leader, how do you navigate this right now? [inaudible 00:41:00] I just call you and ask you what you're looking at, [laughs], because you have access to all the data and you're at the forefront of of this stuff at the moment. I'm like, I'm cheating on that one. But that does help. But, I think exactly, what Sri said, is you're going to end up with something sitting beside you trying to figure this out and we humans will then continue to do the things that... More human bespoke. You and I, Eiso, had an off camera conversation about that, [inaudible 00:41:26] in the future will be an actual thing that we value because of what will happen to us. And I think that is even more important inside companies, 'cause you can't have a... We can't have AI make culture, as an example, it's going to be difficult to- to navigate that, so wha- what do we do versus what do machines do?

[00:38:01] I do think also as, there's a public stat about GitHub Copilot, which is... Right now, it's generating about 40% of- 40% of all code that's written on GitHub is from Copilot. But there's- also there's a bunch of mistakes that are happening inside there too, so there's judgment, and it- it'll getter better and it'll refine and obviously that curve will continue to improve. But one thing I would caution anybody in the current moment about is if you look at what something can't do at the moment, you're missing the big picture, because what it can do is amazing.

[00:38:31] And what it can't do will get better quickly. It'll get better much more quickly than we expect even at the- from this point forward. And for what it's worth, that's the exact same mistake as, like, when you're evaluating a person. You're looking at what they can't do look at what they can do amazingly well and see if that superpower can be used or is useful for your organization. You can also find a reason why even Sri and I, who ran two of the largest technical organizations in the world would not be a great fit.

[00:38:54] [laughs].

[00:38:54] But what are we amazing at? And, S- I know Sri well enough to know there's a bunch of things. Unleash those things for your organization, not figure out [inaudible 00:42:48].

[00:39:02] To- totally. I- 

[00:39:02] Sri: I- I like what you said and people also get scared, saying, "Oh, it might replace me." It's like, it's not going to replace humans in any time... For- for example, I'll give you, the- there's an easy way to create a disaster in your engineering organization. Just approve a full rewrite of your V2 product, [laughs].

[00:39:19] [laughs].

[00:39:21] [laughs].

[00:39:21] [inaudible 00:43:09], it might actually be the... If you look at all the stats and you look at what it takes [inaudible 00:43:14], it might actually be the right answer the AI might say, "Oh, yeah, rewrite," and there you go, you have created a full disaster for the company.

[00:39:34] [laughs].

[00:39:34] Yo- full rewrites, again, we can delve into that, [laughs]. Full rewrites are really bad, you have to do piecemeal updates and whatever. But, again, AI won't understand that's why the judgment of the leader is so important in these scenarios and the experience and learning from what- how things have worked in their scenario and applying the right judgment, super important. AI is going to help with this, but not replace humans, yet.

[00:39:59] One 

[00:40:00] Jason: last comment to make on this, which is there's that... There's- there... We're in the middle of the- the biggest hype cycle in AI for a while, right? We- we're trying to figure out how to navigate this type of thing. And I love it, Sri loves it, Eiso, you and I met over this stuff.

[00:40:12] [laughs].

[00:40:13] eight years ago? Six years ago at this point, I think, or something like that?

[00:40:16] Yeah.

[00:40:16] Yeah, six years ago. We- we spend a lot of our time on it. But one thing I will say is there is- there- there's still a moment where... I don't know when we're going to get comfortable with AI making a certain set of decisions as an example. Th- as a theoretical construct, we're not going to give AI the keys to the nukes type of deal, right? That's just not a thing that we're going to feel comfortable with doing. But inside businesses, there's the same [inaudible 00:44:35], it's oh, yeah you- you know, AI can approve a spend of, $5,000, $10,000, depending on your organization. $1,000,000 maybe, depending on sa- something or other, you're a day trader or- and using this or whatever.

[00:40:51] But GitHub size, or a- Atlassian size, hey, we're going to go spend $250,000,000. You're like whoa, hang on a second. Let's back this up, let's have a conversation about it, let's go through the numbers, let's do all that sort of stuff. There's a spectrum on here about when this is going to be useful, and this goes back to that Copilot analogy, which is, again, even why we named it Copilot in the first place was we were looking for exoskeletons or Iron Man suits type of deal. These were not supposed to replace the human.

[00:41:15] And if you read Iron Man comics, Tony Stark is supposed to be the superhero, not the suit. And it's an important distinction here, and while I think we're going to be living in that era of AI for a lo- for a long time. Now, there might become a time when it's no mo- longer a person in the suit, but I don't think we're there for a while.

[00:41:35] Sri: No, I- a- and the other aspect is w- and this is something people should appreciate, it also will let us do things that we won't be able to do.

[00:41:43] Yeah.

[00:41:43] There's of course the efficiency gains. But there's, like... AI is already better at detecting radiology reports ta- issues than humans. It's better at certain things, so it's going to do things that humans can't do, which I think is a huge benefit. It's not just the efficient, it's- efficiency, it also unlocks things that will take us much further as a humanity.

[00:42:06] Eiso: 

[00:42:06] Let me bring that back in the realm of- of engineering leadership. What is a CTO going to be able to do of a 6,000 or 2,000 or 3,000 person engineering org, at the top of the org, in three years, five years from now, that they can't do today that will be massively invaluable to them?

[00:42:25] Th- 

[00:42:25] Sri: the- there are lots of things that are extremely hard to get right. Even... I wrote the paper, but measuring some of these metrics is actually hard. There are companies working on this, it's possible that tha- you can put some people on and get that working and... It's actually hard right now.

[00:42:43] Yeah.

[00:42:44] Right, It shouldn't be that hard, right? If you look at go to market and others, there are much, much better tools for them than what engineering leaders have.

[00:42:53] [laughs].

[00:42:53] It's ironic. But AI is going to make it better. It also can help with identifying and fixing bugs, security identifying security issues that are public, [inaudible 00:47:12] the zero day times can come down. There are multiple things that CTOs have to worry about that takes much harder, much longer time, a lot more processes, and AI can reduce these processes and make it a lot more efficient.

[00:43:20] And also unlock other innovation things, so y- you could focus the same resources on less of the not moving the company forward to things that are moving the company forward and making building new things, and trying out if there's a new technology that comes out and if it actually is- works well with the product. This AI should tell us that, look, there is this thing, and just be able to handle that much faster than not knowing certain things. So, So, It just... That education part I think is going to take us much farther.

[00:43:51] Jason: The- the fact that we don't have a tooling in- in engineering is- is something that I don't think a lot of people outside of engineering realize. Every CTO in the world knows exactly what we're talking about here. A- again, Sri and I ran the dev companies of the modern era, and the internal tooling we had available to us was terrible. in fact the visibility that we had was so poor in so many different things. think that- exactly that, we're going to have a lot more visibility into this, like what revenue leaders might already have and all- and marketing folks have on there and stuff will- will get better.

[00:44:18] I- I think of it as a lot of the drudgery and kind of ceremony of the software development stuff might go away. My favorite example to- to bash on is writing Java as an example is a very tedious task, because of how much you- how many characters you actually have to write to get something done. A lot of that can be- can go away, but that's not... It's an example, but it's supposed to illustrate that a lot of the drudgery that we just generally put up with in software development and to build platforms I think will co- will- will be able to go away, which allows us...

[00:44:48] Again, it's, like- it's another abstraction layer, will allow us to go focus on other types of problems. And- and I think, to a degree, more important problems again, going to the culture, going to the efficiencies, going to that sort of stuff. But also then making really important decisions. A lot of times, CTOs have a hard time pulling themselves back out to the really important decisions, 'cause they get pulled back into a technical decision that maybe they shouldn't be in or whatev- for whatever reason they're involved in and, again, another abstraction level, another way for us to- to find 

[00:45:17] Sri: leverage.

[00:45:17] A- and the other thing that I think will also happen, thinking about this, is we talk about 10X engineers better than normal engineers and such. It's going to gi- AI is going to give superpowers to these engineers, and you actually will start talking about 100X engineers and 1,000X engineers, because they can leverage these AI tools much more effectively.

[00:45:39] Eiso: I think that's a topic we have to get you back on for, Sri, because that- that could- that's opening up an entire can of worms.

[00:45:45] [laughs], I know, that's right.

[00:45:45] And it's a- it's... And while I tend... While I... Yeah, [laughs], you said it right at the end. And I know Jason and I tend to agree with you on- on a lot of those parts there, so it's- we might have to have you back 

[00:45:54] Jason: on at some point, [laughs].

[00:45:54] We- I think to end this, yeah, to end on that topic too might be maybe there is not a 6,000 person organization in the future too because you have so many of those folks that are able to do that. And if- if we're- if I'm being honest, that's what I think will happen, we'll start to see more really excellent companies in the, 100 to 200 person total range, and they're just doing things that just blow your minds.

[00:46:15] And- and 

[00:46:16] Eiso: this is a little bit what I was alluding to. We- we run most engineering organizations with ratios of, a modern tech company with a couple of hundred engineers that's VC backed today will have four ICs to a- a manager or a leader. Some of the bigger companies aren't far off from those ratios, and I think as we... One of the ways of solving the problem we've been talking about today of we wish we had more pros in- in engineering leadership can start getting accelerated, not just from the education perspective that a Copilot can bring, but also from the fact that we might need less leaders to- in organizations in general or to number of engineers. And I think this will- will unlock us to focus on what makes leaders really great, and it's the human qualities. It's not the ability to deal with Jira. 

[00:46:59] Jason: No offense, Sri.

[00:47:00] [laughs].

[00:47:01] We get asked the- I'm sure Sri gets asked this question all the time, people talk about hey, is AI coming for your jobs and all that sort of stuff. The one thing I will say is, no, I don't think it's coming for your job, but the- the job changes, and the job, you have to adapt to the fact that the job is going to change. One... If you want to future proof yours- yourself in a world where AI is everywhere, is you have to have great taste and good judgment, because you're going to be reading or you're going to be amalgamating information on a higher level, at a faster pace.

[00:47:28] If you're an engineer, you're going to be reading a lot more code, you're going to be looking at a lot more architecture diagrams and understanding... You have to be able to understand. This is... To Sri's point, like, I- I think low code or no code low code is the AI generated code now. That's... We're going to get rid of all these interfaces, it's the AI generated stuff. But you still have to have an understanding of what is happening and because some of it will break and you'll have to understand where to go look at- look around and do that.

[00:47:53] And if you don't have that understanding, that's what a junior's going to be. A junior knows how to generate but not understand. The senior is going to be able to generate just like everybody else and- and adapt, but they're going to understand how it all works together, what's happening, where to look if something completely blows up. It's taste and judgment.

[00:48:08] Fantastic. 

[00:48:09] Eiso: Thank you so much. Sri, is there any parting words you'd like to leave engineering leaders with today?

[00:48:14] Sri: Let me recap what we talked about. Engineering leadership is coachable. Seek for help, get mentors, that has helped me personally, [inaudible 00:52:51] will help you a lot too. Start learning about AI, if you haven't. It's going to come and disrupt you, so that's important for you to be... Especially you in a company as a CTO to be aware or le- engineering leader to be aware of what's coming and how the whole company, not just you, your org, can adapt to it. And third is, to summarize everything, it's all about people. As long as you're getting amazing people in the org and keeping a high talent density, I think you'll do great.

[00:48:53] Eiso: Appreciate it. Thank you so much for being with us today, we hope to have you back on again in the future. Thank 

[00:48:57] Sri: you, Sri.

[00:48:58] This was a lot of fun, thank you.

[00:49:03] VO: Thanks, Sri.

[00:49:04] Thank you for listening to Developing Leadership. Make sure you subscribe to follow us on our journey to more meaningful engineering leadership. If you have any challenges or topics you would like us to explore in an upcoming episode, Tweet or DM us @devleadership_ on Twitter. To learn more about data enabled engineering and how metrics can help your teams and improve your processes, go to athenian.com. See you in two weeks for another episode of developing leadership.