Anyone who’s been in a rapidly scaling company with an ever-expanding engineering team knows that communication is never as simple as it seems.
That’s why we were so excited when Shankar Ramaswamy decided to sit down with Dev Interrupted's Conor Bronsdon
Shankar is a veteran leader in the engineering space, having helped recruit, build and guide developer teams at companies like Amazon, eBay, Paypal and Google - where before leaving he managed a team of 300+ people.
Now the Head of Engineering at Datastax, Shankar took the time to talk to us about some of the practical lessons he’s learned managing teams of several hundred people, and why something he calls the “intent perception gap” is so tricky for managers to get right.
We also took the time to talk about Shankar’s views on the future of cloud computing, what healthy conflict looks like at unicorn companies and why you might want to rethink your single-vendor strategy.
Episode Highlights Include:
- (2:54) Shankar’s career from product management at eBay to eng at PayPal
- (5:35) Why Amazon is the only place where junior devs argue about customer experience
- (11:52) What is the intent perception gap?
- (19:06) Future of cloud computing
- (21:07) Why single vendor strategies are a bad idea
- (32:19) Devs have no formal training to handle people problems
Our Interact conference featured content from the best engineering leaders in the world. Watch it on demand on YouTube now.
Transcription:
Conor Bronsdon: Host
Shankar Ramaswamy: Head of Engineering at Datastax
---
Shankar: [0:00] There is a big difference between what you intend to say and how it is perceived, especially as a leader. I call it the intent/perception gap, right? You intend to say something a certain way, and how somebody picks up on it is going to be very, very different.
Conor: [0:18] This episode is sponsored by LinearB. Accelerate your development pipeline with data-driven engineering metrics, continuous improvement automation, and project visibility while cutting your software development cycle time in half. Sign up for your free demo at linearb.io and mention the Dev Interrupted podcast discount for one month free when you sign up for an annual pro membership. Welcome to Dev Interrupted, this is Connor Bronsdon. I'm Dev Interrupted’s executive producer and I'm here filling in for Dan Lines as host today. I'm here with Shankar Ramaswamy, he is the head of engineering at DataStax and a former VP of Engineering and also Senior Director of Engineering at Google. He's had a million titles, a very storied career, and we're really honored to have him here today in the Dev Interrupted community to talk about what he's done, what he's working on at DataStax, and much more. Shankar, thank you so much for joining me.
Shankar: [1:06] Oh, thank you Conor for having me. Glad to be here.
Conor: [1:09] Awesome. I'd love to get to know you a bit better and talk a bit about your career, I really want to dig into DataStax, too but let's give our audience a chance to get to know you. Like I said, you previously have been a Senior Director of Engineering at Google, you were VP of Product Management. And you also led the engineering team at Apogee, which was acquired by Google, and you're previously a director of engineering at PayPal and Product Management at eBay. Walk us through your career a bit, how did you get started in engineering and then make your way to where you are today as a very successful engineering leader.
Shankar: [1:37] Thank you, yeah. So, I started my-my career in engineering quite accidentally, right, I was not super engaged when I was in school. You know, most-most of the stuff wasn't very interesting. And then when I got to college, I happened to read my-my textbook in electronics. And I just fell in love with electronics and hardware and all of that stuff, and then continued to study and got a PhD. And at that point, I switched over to the software side of things. And so, I really, really love technology and love being in technology. And then as a technologist, the first half of my career, I got to do a little bit of individual contribution also did a little bit of entrepreneurial work. And then the second half of my career, I did Product Management for a few years, right, and that gave me a great insight into how to think about products and the value and customers and all of that stuff, and then decided that finally, I wanted to be in engineering leadership. So, I've spent the last decade as an engineering leader. So, the first ten years was individual contributor, then about five years as a product management person and leader, and then engineering leader for the last decade.
Conor: [2:53] If I recall correctly, the product management, you were doing that as a director at eBay, right? And then you transitioned into engineering at PayPal.
Shankar: [3:00] Yes, exactly.
Conor: [3:01] So how did that transition come about? You decided you wanted to go full into engineering leadership, you already had these skills as a leader and you said, Hey, let me get into this here or what happened there?
Shankar: [3:10] I realized that as a product manager, while I had a lot of the experience of thinking about customers, and value, and experience and all of those things, I felt like I could bring that thinking and be more effective on the engineering side of the hubs, right? Where I felt like a lot of times when I was working with my engineering partners, there wasn't that appreciation, right? And I felt like, “Hey, if I came into engineering, and could influence the hearts and minds of engineers, then with product thinking and you know, appreciation for customers, and so on, that could be really powerful, right?” And so that's kind of why what I've been doing over the last decade is trying to get engineers to really appreciate and develop that product thinking and then also being a good partner for my product management colleagues, right and enabling them better, right? So-so that's kind of-I felt like that could be the spot where I could make the most impact than being just in front of management.
Conor: [4:13] It certainly seems like you're making that impact. I mean, you've worked for some massive organizations, you've helped lead teams that go to acquisitions, you're obviously doing incredible stuff at DataStax. Now, I'd love to know a bit about that experience of working at these major like headline corporations, you know, you were at PayPal, then you went Apogee and then Google. How did the experience and the culture at PayPal compare to Google? Are there like pros and cons of both?
Shankar: [4:37] Yeah, I think looking at all these large companies, I think they all tend to have you know, some center, right, something that has made them successful. You see that in a show in-in the way everything happens. So, for example, IBM, you know, had this long history of being a very reliable partner for enterprises. And so that was kind of-the center was, hey, we never let our customers down, we do everything we can, you know, to meet their needs, and so on and so forth. And every customer is special and unique, right? So that was kind of their big, big thinking there. Amazon was actually very customer centric but looking at it more from large scale, right, how do you sort of scale customer centricity, right? And how do you, you know, have millions and millions of happy customers, right? So-so that was very fascinating to see. And really customer obsessed actually. I would say to people, people at Amazon are super customer obsessed. That's the only place I've seen where junior engineers were sort of, you know, having arguments in the hallway about what would be the better thing for customers, right? Which I've never seen [crosstalk] [5:49] anywhere else.
Conor: [5:49] Amazing. Yeah.
Shankar: [5:51] And then getting to eBay and PayPal, it was all kind of one big, happy family at that point, the split had not happened. I think eBay was going through a little bit of a renovation at that point, right, they've gone through their early success, and then they've gone through a little bit of a downer and lost ground to Amazon, and so on. So, there was a little bit of revival going on. So, it was an interesting mix of cultures. I think they'd also been more like an IT shop and then they decided they wanted to be a tech company and so there was there was some of that going on as well. So certainly, it was a-I would say there was a there was a transition going on at eBay when I was there. And then getting to Apogee, of course, as a startup, right, classic, you know, small, few hundred people and you know, high energy, high momentum kind of thing. Then getting to Google, that was actually interesting to see the obsession with scale. And the scale that that you have at Google, there's maybe two-three places that have that kind of scale, and so many different properties with very large scale, right? So, the scale was-was just massive. And then the culture was really a very collaborative, very friendly kind of culture. I got to meet some really, really amazing people who've done things that we all talk about, right? You meet them in the hallway, or you meet them in a in a meeting and they're like, super humble down to earth, right, kind of people, so that was that was very fascinating.
Conor: [7:17] That's fantastic. I'd love to dig into Apogee a bit more, because I think it sets the tone for your next steps, right, going to Google for several years, and then now two DataStax. So, Apogee you joined, you were the VP of Product Management and you lead-lead the engineering organization. How many people were you managing at that point?
Shankar: [7:33] So I did two stints at Apogee. I did a stint and then I went in between-I took a five-year detour to Amazon and eBay and all that and came back. So, I was VP of Product Management initially, and then when I came back, I became the VP of Engineering. So, I did that for about five-six years, right, before-before moving on to Google Maps. Led the-led the thing through like a pre-IPO stage, right, so about a year and a half or so before we went IPO, and then for about a year and a half, we were public. And then for a couple of years, we were-a little over two years, integrating Apogee into-into Google. It was it was actually very interesting that each of those phases were quite different, right, we're sort of preparing to go be in the limelight and get to be a well-oiled machine, right, because once you're a publicly traded company, you have to kind of be well-oiled. So, that was the first phase, and then once we became public, then it was just, you know, being consistent, delivering, right, quarter after quarter and making sure that you don't miss your plans and that kind of thing. And then we got an offer to get bought. And once we got the first offer as a publicly traded company, you then have to go through like a process of shopping yourself around and getting the best offer and so on. So going-being part of that process was pretty fascinating for me personally. So, during this period, I would say the team was, when I started, we were about a hundred and fifty people or something and then we grew all the way to about two-hundred-and-seventy-five, three-hundred [crosstalk] [9:08] at the point that I left Google.
Conor: [9:08] Fantastic. And for those who may be listening and maybe don't know what Apogee is, can you give them a bit of a breakdown of what the-the product was and what you were working on?
Shankar: [9:19] It was a API management product, right? So, what it did was, it actually sat between the consumer of the API and the provider of the API, and enforced a set of concerns, right, for both sides, right, so security concerns, things like great-traffic management, right, rate limits, quotas, those kinds of things.
Conor: [9:39] Gotcha.
Shankar: [9:41] And then also did monetization, right, so if someone wanted to monetize their API, we could help them with that. We did analytics. We did a little bit of detecting, you know, security type threats and all of that stuff. So really, an API management product.
Conor: [9:57] Gotcha. And you went through several stages like you mentioned with apogee, you know, preparing for the IPO, the IPO stage, growth, acquisition, internal at Google and how that adjusted. What were some of the lessons you learned from those different experiences about how to be a successful engineering leader and to manage your organization?
Shankar: [10:16] I think the biggest thing that I learned-and I was growing during that period as an engineering leader as well, because when-at the point that I took on the role, I hadn’t really managed a very large team, right? So, I would say, the one thing that I learned through the years is just to not avoid difficult conversations. I think we all know when we need to have a hard conversation and, generally, that's not something we like doing. And so, we tend to put it off or avoid it, right? And that always comes back and bites you, you've got to, you know, make sure that you figure out how to have the hard conversations early, right. And so really get comfortable with that and get comfortable with having difficult conversations and develop your own techniques and so on that-that's one thing. And then the second thing I would say is, just listen very carefully to your team, right, I think your job as a leader is not to actually solve every problem, but to identify the problems that need to be solved. And then you know, figure out where the best solutions are, right? And all of those things, the-the problems that need to be solved are also going to come from your team, the solutions are going to come from your team, right. So, your job is really to pick up all that signal, synthesize and make sure you know, the right things get done. Then another one that often we ignore is, there is a big difference between what you intend to say and how it is perceived, especially as a leader the difference-I call it the intent perception gap, right? You intend to say something a certain way and how somebody picks up on it is going to be very, very different. So, I'll give you an example. I used to walk around the hallways and engage in conversations with folks on the team. My intent was just to connect and have a chat and have a technical brainstorm or something on our topic, right. And so, my intent was to learn a bit more about what they were doing and what they’re working on. But also, just chime in with some ideas and things of that nature. What I didn't realize is, when I would throw out an idea or throw out a proposal, they took it as a hey, Shanker wants me to change what I'm doing and do it differently, right? And so here it is, here's a great example of an intent perception gap, right? I'm intending something, but the way it's coming across to the people that I'm talking to is very different, right. And so that is something that you have to be very mindful of as a leader, right, is when you say something, it is perceived very, very differently by different people.
Conor: [12:59] We had Brendan Burns on the podcast a couple months ago, he's Kubernetes, co-founder, Microsoft CVP, leads a very large organization at Microsoft. And he talked about this same thing. He said, as he started to grow his team to really realize the impact of that, like elevator conversation, saying, oh, that's an interesting idea. And you know, three months later, this person comes back, like I built an MVP, and I've spent all this time on it. So, it sounds like you've experienced [crosstalk] [13:23] that sort of stuff.
Shankar: [13:23] Exactly, exactly. So, everything right? And that's just one example, right? But every word you say is perceived a certain way, so.
Conor: [13:33] There's weight to it. And I think it's-it's really wonderful to hear that both of you are thinking about it so deeply, because the impact that we have is really important to understand. And I think that goes in line with what you said previously around listening too, because that's also kind of part and parcel with this where, if you're not listening to your team and understanding what's going on and trying to unblock them, it's really easy to not just, you know, let intent perception gap be an issue where you may say one thing and they perceive something else, but to also fail to understand what's going on there, which leads to even more of that gap, I'm sure.
Shankar: [14:09] Yeah, exactly, exactly!
Conor: [14:12] I'm curious, how has this transition to a hybrid or remote world impacted your ability to do that listening? How have you had to adapt your strategies and make sure that you're not falling prey to the intent perception gap?
Shankar: [14:28] Yeah, no, actually, that's a that's a great question because actually, one of the things we all may or may not know is, a lot of our communication is actually nonverbal. And when you're in a physical space, the nonverbal cues are much easier to pick up, right?
Conor: [14:45] Totally.
Shankar: [14:46] Because they can you can see what's going on body language and so on and so forth. Even, you know, the thing that you can see in a hallway that somebody who's normally very cheerful, very happy is kind of walking around in a droopy, sulky manner, right? And you know, something's up, right? So those are the things that I would say I miss the most. And so, one of the things I've been trying to train myself is in zoom meetings and things like that is to see how I can try and make up. So, I tried to consciously observe what's going on with people, and their facial expressions and things of that nature, to try and see if I can kind of glean what's going on and try and compensate for some of that. And then also, I've been checking in on people a bit more, right, just to see how their tone is and how their response is and so on. So just trying to develop some coping mechanisms. Another thing that I've been doing is having more organized, just, ask me anything kind of conversations, like open-ended, ask me anything conversations. So, my ABP is kind of set a schedule where every week, I end up meeting a couple of groups [crosstalk] [16:01] for about thirty minutes. And all we're doing is just saying, hey, what's on your mind? What questions do you have? What would you like to talk about? That kind of thing? Right? Just opening the no agenda, right? Nothing. And that's actually helped as well, right. So just-just trying to, you know, figure out other mechanisms to get that signal.
Conor: [16:01] Love that.
Conor: [16:20] I appreciate the intentionality of that we had Darrin Murph on for an event talking about remote work, he's, you know, the head of remote at GitLab. And he talked a lot about that, about how it's not that we-we do lose that kind of synchronicity of these, like Hallway Conversations, you know, you run into someone getting a coffee, or you're walking around, and you go pop your head in somewhere. And so, because of that, we have to be more thoughtful about the interactions we're having. And I like that you're doing it not only and like how you evaluate and consider and like-like, think about the interpersonal relationship of each meeting, but also saying, hey, I need to check in more. You know, there's definitely been, I think, a phenomenon of people saying, “Oh, I'm fine, I'm keeping it together. Things are things are all good.” But we're also all dealing with things at home that maybe aren't going to show in a casual zoom chat or won't come through in a Slack conversation.
Shankar: [17:10] Right. Yeah.
Conor: [17:11] And without those-those cues that you mentioned, it's harder to do, then you have to be much more thoughtful about how am I tracking my team health? And how am I tracking burnout? How am I making sure that everyone's getting the support they need, or the resources or the knowledge? I think the AMA's are probably a great way to do that too, to build trust and also exchange info.
Shankar: [17:30] Exactly, exactly. And then you know, I have partners as well. So, for example, I have my HR partner, right, and I tell them as well, hey, can you check in as well, so-so that way we have, you know, multiple people checking in on others and getting signal on what's going on.
Conor: [17:46] I do want to really dig into DataStax and what you're doing, because I think the-the way you're thinking about everything is fantastic. Can you tell us a bit more about DataStax and make sure our listeners know what it is you're doing there?
Shankar: [17:58] Yeah. So, at DataStax, we are looking to build an open Data Stack for modern apps. And so, we've been involved with Cassandra for a long time. And we've had a product based on Cassandra as well in the market for a while. Recently, we also started to prioritize Pulsar, Apache Pulsar as well. So, pulsar and Cassandra are both projects that that we participate in, and we prioritize. And then what we're looking to do is also to integrate these things, right? So, if you look at modern data apps, they use a lot of different data systems and data's services, and they're somewhat disjoint. And they have to put things together or move data around, and so on and so forth. So, our thinking is, can we make that simpler? Can we give developers you know, access to some of the data services that they need? How do we sort of bring it together, single API, single way of accessing things so that they don't have to worry about a lot of these things?
Conor: [18:55] So something I was really curious to hear from you, given the work DataStax is doing in cloud computing and your experience in the field; Where do you see cloud computing going over the next five-ten years as we continue to use this distributed workflow model?
Shankar: [19:11] I think that if you look at it, the heart of cloud computing is you're essentially taking away a lot of operational headaches from folks, especially around infrastructure and other things, right, and you're freeing up more and more cycles for innovation, right? Otherwise, people would probably be spending a lot of their money and tying trying to keep things up and running. Say, for example, we take a simple thing, right? Let's say you wanted some logging and metrics for observability, right? Earlier, you would go figure out how to run your own logging thing, your metrics thing, right. You probably need a few people just to keep that up and running.
Conor: [19:49] Totally.
Shankar: [19:50] Today, you don't even think about it right? You just go and get some SAS offering for logging and something for metrics and you're done right? So, what that means is now you freed up a bunch of, you know, your budget and your bandwidth and you can invest that in more and more innovation, right. So, I think we're gonna see more and more innovation. And I think the rate and pace at which use-things come out in the cloud is also going to keep increasing, right? Because now all that is going to show up as a service as well, right? I think you're going to see more and more SAS services and interesting services come up, because there's so much more bandwidth available for innovation, I think there's still some challenges when it comes to the cloud, around things like cost management, [crosstalk] [20:34] security, all of those things, right?
Conor: [20:34] Totally.
Shankar: [20:36] So, I think seeing more, perhaps, integrated platforms where some of those things are taken care of, and it's very easy for you to sort of build in a way that, you know, you know the costs, you know the security is good, all of that stuff is definitely I think, also something we'll seen more of. More platforms, right, rather than just individual primitives that you sort of stitch together. So, I think that's another area. And then generally, I would say, multi cloud is, I think, going to become more and more important, because honestly, if people haven't learned from the past, single vendor strategies are not that great. I know today, single vendor strategies produce, you know, deep discounts and those kinds of things. But I do feel like it's somewhat irresponsible. If you're all in on just one vendor, right? I think having a multi cloud strategy is going to become important. And there's some great technology showing up there as well, right? That that's starting to really-Kubernetes is, you know, sort of foundational, some of the work we're doing at DataStax is in that direction. So, there's lots of interesting stuff happening and multi cloud is going to become more and more interesting. So more of the full, like, whether for availability, or for cost, or whatever reasons like, competition, being able to shift quickly back and forth and do things would be I think, where we would go with that.
Conor: [21:58] Fantastic. I was talking to somebody on a podcast, they talked about swivel chair engineering and how it's become this norm where, you know, we're going from-from one thing to another; one data source, to this other dashboard, to inputting code here, to tracking what's happening in JIRA. And all these tools on their own are really helpful but the confluence of them all, unless it's well managed, like what you're doing DataStax can be fairly negative for the process and bog things down.
Shankar: [22:27] Exactly. So, we're trying to see if we can, you know, with the world of Kubernetes, and multi-cloud and all of these things, you need your data to be everywhere, right? So, we are in the process of supporting that kind of distribution and providing more Kubernetes, we have a serverless database, that's all based on Kubernetes [crosstalk] [22:45] now, right?
Conor: [22:45] Fantastic.
Shankar: [22:46] So, we're really trying to embrace the needs of modern applications and figure out how to solve their data problems.
Conor: [22:53] So how big is your team now at DataStax?
Shankar: [22:56] It's-it's about a couple of hundred people.
Conor: [22:59] And how are you organizing it? Do you have two different organizations that you're funneling everything into that like small, distributed teams, how's it set up?
Shankar: [23:07] I actually believe in-I've used this framework for a long time, I have these three core principles around which I organize. They’re accountability, autonomy, alignment, the idea is that everyone should know, every individual team should know, what they're accountable for, right, in terms of the customer or business problems that they're solving. And then they need to have the autonomy, to be able to make the decisions they think of the best decision to solve those problems. So, we make them accountable, give them the autonomy, right. But autonomy without alignment is chaos, and so that's where alignment comes in. And so, alignment is about ensuring that as you have all these teams autonomously going off and making decisions, that they are consistent and coherent with each other. So, I tend to set things up where I've got teams and individuals, you know, their charter is spelt out, right? They say, “Hey, this is your charter, you will figure this out.” So, I spent a lot of time working with them, writing things down and really clearly spelling out the charter. And then I let them you know, do their thing, right? And then I focus a lot of my attention on the alignment piece. So, setting up the charter gives them accountability, giving them the space to execute and also, you know, letting them know that it's okay to fail, right, it's fine, we'll just learn from failure, that gives them the autonomy to go and do what they need to do. And then I spend a lot of my time on alignment. And the way I like to think about alignment is you want low-cost alignment, right? Like we could all be sitting in the same room all day and discussing everything. And we'll be perfectly aligned, but we won't get anything done. So, the question is, how do you sort of have, you know that alignment be at a low cost? And that's where I-I figure out what sort of process ease and rhythms and information exchange and all the things that we need to have to keep that going with the minimal cost for all involved.
Conor: [25:09] And that high degree of ownership you're giving our teams with the autonomy, that really, I'm sure resonates with them around feeling like they're making an impact with their work and having [crosstalk] [25:19] the opportunity to, like, try things, as you point out, and to fail when needed.
Shankar: [25:19] Absolutely!
Shankar: [25:23] Absolutely. And grow, right? So, I also look for, you know, how can I stretch people and give them something that they've not done before, and so on and so forth, so that they can also feel like they're, they're developing, right? We all-at the end of the day, all of us want-want to, you know, take on new challenges.
Conor: [25:38] Absolutely.
Shankar: [25:39] We get we get bored with what we've been doing all the time.
Conor: [25:42] So you mentioned processes to maintain and build this alignment, what kind of processes are you putting in place?
Shankar: [25:50] So for example, we have, you know, a set of regular heartbeat meetings, right, every week. And each of them is designed to give us alignment on something. So, for example, we have an all hands every week, and that all hands is to align the broader team on; What's going on? How are we doing, right? What's this team working on? That kind of thing. And then we have a review of all our initiatives every week to see if anything's changed. Hey, this thing's you know, now gone red. Okay, we all know it's gone red, what's the impact, right? Or there’s things coming in, new initiative coming in that kind of thing. And then we also align on the details, right? So, we have everybody looking at all the PRDs, and designs, and mocks and all of that, so that everybody understands, like, “Oh, hey, this is-this thing is getting built.” So, for example, the security team can say, “Hey, have you thought about the security issues of this thing, right?” Or the support team can say, “Hey, how are you going to get us up to speed on this particular feature?” Or whatever, right. So those kinds of things are one mechanism, right? So, we have basically this regular cadence so that everybody is all the time looking at all of this. It takes about maybe, you know, a couple of hours a week and server 5% of everyone's time. But the idea is that you're all very up to date on everything that's happening, that's material.
Conor: [27:12] Are there engineering metrics you're tracking for your teams to help identify which teams maybe need help or have blockers?
Shankar: [27:21] On that particular front, I haven't really come across very good metrics that help with that kind of thing. In the past, I've used metrics, like the turnaround time for tickets and things like that, right? So, like a good percentile turnaround for a P-one, or a P-two or a P-three, [crosstalk] [27:38] just to see where that is, right?
Conor: [27:38] Yeah.
Shankar: [27:40] So we understand how things are going, to understand our velocity. But I do tend to use a lot of metrics around the customer experience, right? So, what sort of [crosstalk] [27:49] quality are we delivering?
Conor: [27:49] Okay!
Shankar: [27:50] What sort of availability and reliability are we delivering, right, performance? You know, things that that would be material to our customers, right?
Conor: [27:59] Yeah, we recently did research around pull requests, contacts, you know, I work for Dev Interrupted, and also my-our parent company, LinearB, tracks engineering metrics and tries to help better align teams. And one of the things that we found in our pull request research was that 50% of PRs are like sitting idle for half of their lifespan. And so, I think there's definitely opportunities for that kind of alignment that you mentioned, to help improve that velocity, [crosstalk] [28:26] because, like you're saying, if my teams understanding what's going on, hopefully, they're going to align more with their co-workers.
Shankar: [28:26] Oh nice!
Conor: [28:32] And there's a lot of ways to go about that. We-we definitely see that a similar issue when there is a lack of alignment on teams and across teams, where idle time, whether it's like distraction time, you know, when you pick something up, and you go to something else, or like transition time during handoff can definitely drive problems.
Shankar: [28:49] Oh, interesting. No, that's, that's good to know. Good to know, I should certainly dig in more and learn.
Conor: [28:55] It's a-it's an intriguing space, I think there's gonna be particularly with distributed work, there's been a lot more emphasis, I think, on how can we track what's going on. Because as you point out earlier, we have less of that like day-to-day information. So, I think there's an exciting space evolving now around taking that and diving deeper. And there's going to be, hopefully, a lot of incredible stuff coming out. I don't want to, like, pitch us too much but I think there’s a lot of cools stuff out there. So, I'm really curious, your teams are distributed; They're mostly working at home remotely. Are you hiring across the world? Is your team mostly in the North America? Where is everyone?
Shankar: [29:31] Actually, we are hiring across the world! I believe we have people in about thirty different countries, right.
Conor: [29:37] Wow!
Shankar: [29:38] So yeah, we are-we’re all over already. So, I would say a lot of our folks are in the Americas and Europe, but we're slowly starting to also have a bunch of folks in APAC. We already have a team in Australia and we're now slowly starting to hire in India, and we have some people in Singapore and other places as well. So yeah, it's just truly distributed.
Conor: [30:01] So there are two more questions I want to ask that are ones we try to ask every guest. One is what was a mistake you've made as a leader that you had to overcome? And what did you learn from it?
Shankar: [30:11] One of the mistakes that I made early on was not delegating enough. And I think it's one of those things that I've seen, you're almost trained, you're good at problem solving, which is why you get these opportunities to lead, right? And then it's a muscle that you have, right, you have a lot of the problem-solving instinct, and then you become a leader, and you tend to continue in that mode, right, where you see [crosstalk] [30:37] a problem and you the-first instinct is, hey, let me go solve this, right?
Conor: [30:37] It’s hard to let go.
Shankar: [30:41] And I think the thing that-even now, right, sometimes I make that mistake, right? And I literally have to step back and say “No, should I be the one doing this? Or is there somebody else that I can give this to?” Right?
Conor: [30:53] Right.
Shankar: [30:54] And so, there's certainly things that I have to put my attention and get into the details. But a lot of the times, either there's someone better suited to do it, right, than me, or it's a great opportunity for someone to learn and do something different. So, I think that is the one thing that I would say is a big mistake that-that I certainly, you know, took me a while to realize that I shouldn't be getting into all these problems myself.
Conor: [31:18] It's funny you mentioned that. So, we had Hyrum Wright and Titus Winters from Google, they're both senior staff engineers there, on the podcast earlier in 2021. And they talked about this, but they also talked about it from the perspective of how we learn to code. So generally, you're going to a coding bootcamp. If you're, you know, going to university, you're taught to like, solve problems on your own. And engineers, who then later become engineering leaders are taught to, like you said, be really incredible problem solvers. They're not taught how to pull a team together, how to delegate to others, how to necessarily think in like a collaborative fashion about solving problems and using those other best resources. So, it can make people really incredible problem solvers. But in some ways, we're often training them to not be successful leaders down the line, they have to be retrained.
Shankar: [32:06] Yes, absolutely! In fact, there is no formal training on people problems, right? We know how to solve technical problems, right?
Conor: [32:15] Right.
Shankar: [32:16] But, you know, solving very large technical problems often involves a lot of people problems as well, right. And we're not, you know, generally equipped for those kinds of things.
Conor: [32:26] Which is why people, hopefully, listen to this podcast, so they get these great nuggets of wisdom from you. One last question here, in your mind, what are the keys to your success as an engineering leader?
Shankar: [32:35] I think one of the things that I do as an engineer is I bring a lot of systems thinking, to my leadership as well. And I think that serves me well. Because I'm always thinking about how do I create a system, rather than, you know, depend on just individuals, right? And so that's something that I think serves me well. And then I will say I've generally, over the years, learned how to listen more. And so, I think that's-I do more and more of that. I'm certainly not where I'd love to be, but I certainly am on that journey, and much better. And, and so I think that's-that's also serving me-serving me pretty well. And I'm also very curious, right, so I, like, love to, you know, just learn and continue to grow myself. So, I would say those are some things that have served me.
Conor: [33:22] I definitely hear that in your communication style even, like not just as a listener, but also in the way you communicate. So, thank you for bringing all these great nuggets of wisdom. So, if someone was interested in working for DataStax and said, you know, this guy sounds really smart, I like this Shankar guy, I want to go work in his org, where should they go find the DataStax career page.
Shankar: [33:41] Definitely on our website, datastax.com, you can find the career website and then if you want to reach out to me, it's Shankar (spells Shankar) dot Ramaswamy (spells Ramaswamy) @datastax.com (shankar.ramaswamy@datastax.com). Just drop me a note. And I'd be more than happy to talk to you.
Conor: [33:59] Fantastic. I do like to give our guests an opportunity here to close out the conversation with a call to action. What you want engineering teams and leaders to take away from this conversation?
Shankar: [34:09] So a couple of things. One is if you're looking for a database for a new app, or whatever do look at Astra, DataStax Astra. We're really proud of it, our serverless database we think represents state of the art database that would serve you well. And then if you're someone that is deeply passionate about distributed systems, cloud computing, Kubernetes, or databases, please come we're hiring actively. And please reach out and drop me a note or visit our careers page and we'd be really happy or connect with me on LinkedIn, you can easily find me there, love to talk to you.
Conor: [34:46] Fantastic. Definitely check out DataStax, [Music fades in] and I know I'm going to go connect with Shankar. What an interesting conversation. A couple quick reminders for our listeners, if you haven't already rated and reviewed the show on your podcasting app of choice, particularly Apple podcasts, it’s really crucial to the show getting discovered. And if you haven't also joined our Discord community, you're missing out on daily conversations of other engineering leaders, happens all week and we're excited to ramp that up as we head into our interact 2.0 conference on April 7th, we'll continue to give you updates in the show but if you want all the newest information, you got to either sign up for our newsletter with, now, more than two-thousand people or go and join our Discord community to learn more. So hopefully you will. We'll have links to all this in the description below and Shankar thank you so much for joining me today.
Shankar: [35:32] Thank you Conor. Glad to be here.