What makes a great engineering team? For Rajashree Pimpalkhare, vice president of engineering at Twilio, the answer lies in a thoughtful blend of leadership values, diversity, and customer-centric innovation. Rajashree’s journey—from the early days of Silicon Valley’s microprocessor boom to leading teams at PayPal, Intuit, and Twilio—has shaped her unique approach to building cohesive, high-performing engineering teams.
In this episode of Keep Moving Forward, Rajashree shared her philosophy on leadership, cultivating inclusivity, and preparing for the transformative impact of AI on software development. Her stories offer a compelling roadmap for creating resilient and adaptable teams in today’s dynamic tech landscape.
How Clear Values Create Engineering Teams That Deliver
Rajashree’s leadership is rooted in three core values: customer focus, engineering excellence, and transparency. “As a leader, your biggest job is to explain why are we going in a certain direction and what does success look like,” she explained. This clarity helps her teams align their creativity and efforts toward shared goals.
Flatter organizational structures are another hallmark of Rajashree’s approach. She believes hierarchies dilute communication and slow decision-making. “At some point, if you have several steps from the leader who's actually making decisions to people who are responsible for implementing it, you're going to lose touch,” she noted.
To foster accountability, Rajashree organizes teams around durable ownership of platforms or customer outcomes. “You have an accountability problem if you have an ownership problem,” she explained. “If you don’t have agency in making decisions, in deciding what matters most, then it’s very hard to be accountable.”
Diversity and Inclusion as Catalysts for Innovation
For Rajashree, diversity isn’t just a goal—it’s part of life. “Even if you have same sex and same ethnicity and what have you, you still bring diverse experiences based on your childhood, where you grew up, your financial status, or what have you,” she said. But inclusion, she explained, is what truly unlocks the potential of diverse teams. “If you make people feel like they are part of a team or they have that sense of belonging, you're going to get much better work of them than you otherwise will.”
She emphasizes the importance of investing time to understand her team members as individuals—their values, principles, and backgrounds. This deeper connection enhances collaboration, especially in remote environments where bonds can be harder to establish.
Rajashree also sees inclusivity as a business imperative. “Almost every company I’ve worked for has built products for the world,” she noted. To serve a diverse customer base effectively, she believes teams must reflect that diversity.
AI’s Role in Redefining the Future of Engineering
Rajashree views AI as a transformative tool for the future of engineering. “I think what's going to happen is the engineering and software engineering roles are going to get more and more focused on the harder problems,” she said. “AI will help us do many more things faster.”
While AI simplifies repetitive tasks, Rajashree believes engineers will always be needed to optimize and refine software. “There was a time when to write a webpage, you had people really focus on that. Now there's software—you just click a few buttons and boom, a page is up there,” she said. Similarly, AI will streamline development processes but leave room for human expertise to shine in solving complex challenges.
Looking ahead, Rajashree anticipates an emerging industry focused on validating AI-generated solutions. She urges leaders to integrate AI thoughtfully and to develop strategies for teams to adapt as the technology continues to evolve.
Rajashree’s leadership philosophy offers a masterclass in building engineering teams that thrive. By focusing on clarity, accountability, and inclusion, she creates environments where innovation flourishes. Her forward-thinking perspective on AI ensures her teams are not only prepared for change but poised to lead it.
For leaders and engineers alike, Rajashree’s insights are a call to embrace continuous growth and the power of collaboration. After all, great teams aren’t just built—they’re nurtured.
Looking for more stories from tech leaders who embody the Keep Moving Forward ethos? Subscribe wherever you listen to podcasts and never miss an episode.
Transcript
Rajashree Pimpalkhare:
Any team that I work with, I make sure we get to know each other as humans. It's even more challenging when you're in a remote environment, but you really need to invest time in that to see where people are coming from, what forms them, what are their principles, what is their value system. I think it's important because that then informs your judgmental nature by this additional information. I'm like, aha, okay, maybe I'll look at things differently. So I think that's an invaluable part of forming any team.
Caleb Brown:
Hey, everyone and welcome to Keep Moving Forward, the podcast from X-Team for tech professionals who are passionate about growth, leadership, and innovation. I'm your host, Caleb Brown, and each episode we'll dive into candid conversations with the tech industry's brightest minds, seasoned leaders, forward-thinking engineers, and visionary experts. In this episode, we welcome Rajashree Pimpalkhare, Vice President of Engineering at Twilio.
Rajashree has been a force for innovation at tech giants like PayPal and Intuit, where she's transformed how products scale and how teams deliver amazing customer experiences. You'll love hearing Rajashree's take on leadership. She brings this wonderful combination of clarity and heart to everything she does, anchored in three principles that really resonated with me: customer focus, engineering excellence, and transparency.
What's fascinating is how she weaves these values into the fabric of her teams, creating spaces where innovation just naturally flows. She also shares something really close to her heart, her commitment to building truly inclusive teams. And wait until you hear how this approach not only brings out the best in people, but leads to some breakthrough moments in product development.
For anyone who's ever wondered how great engineering teams come together and stay together, especially during those high-growth phases, Rajashree's stories and insights are pure gold. Ready to dive in? Rajashree, thank you so much for joining me today. Definitely appreciate it.
Rajashree Pimpalkhare:
Sure.
Caleb Brown:
I do just typically ask you to walk through your early career and just tell me a little bit about what sparked your interest in software engineering.
Rajashree Pimpalkhare:
So as far as I can remember, growing up I always wanted to be an engineer. I loved math. I loved tinkering with things. So I graduated in India with my bachelor's degree from IIT Bombay, and then I came to the US to study, to do a PhD actually, at University of Maryland. And my interest at that time was very much in a math-oriented field. This was Soliton Systems that we are trying to build in the US at the time. And two years into my PhD, Silicon Valley called.
So this was the time when Intel had just started building microprocessors or they were starting to build the Pentium processor, and it was really a race to go participate in that boom. And since then, I've been in the valley and I've moved through my career wherever it took us, wherever the opportunity took me. And from Intel I moved to Synopsys, which was a software company building software for chip design, and that's where my software engineering journey started.
Caleb Brown:
Cool. Very cool. Moving on a little bit into more leadership and culture stuff, just curious, based on your experience of building engineering teams, what are your core leadership principles when it comes to culture and team dynamics, because that's obviously something very important, but can be tricky to get right?
Rajashree Pimpalkhare:
I definitely think culture is set at the top. And to build effective engineering teams and machines that build great products, you do really need to be grounded in what makes for a strong engineering culture. So when I think of a strong engineering culture, I always feel like there is a value system that I have as a leader and that I take to the team.
But then there is also a set of values that may be important based on the business we are building for or the situation where we are in, like the life cycle of that product or the engineering team or what have you. So I always feel there are three durable values I take to every team or every job that I go to. I think I talked a lot about customers. So customer focus is definitely one I would put at the top.
The second one I look at is engineering excellence. So I like to go to every situation by saying as an engineering team, our role is to innovate and bring best practices, but also bring the best technology to solve a problem at hand and to bring the right technology to solve the problem at hand. And then the third piece, which is more focused on team or culture or the way I like to lead, is to lead with transparency.
I believe that we are all adults at different times in our career, but we all should understand why is something that we are building important and what can you bring to the table, what can you learn from the experience? But I think transparency is really important because you have to think of this as a team sport, and you have to have everybody in for the right reasons.
So I start with those three values and then the rest of them can be depending on what life cycle we are in. So for example, when you're building a new product, innovation or agility or really focusing on the customer value and iterating fast with simple experiments, that might be important. When you're working on something like at Twilio, the product that I led, Flex, reliability was very important because we are serving contact centers.
A product doesn't work, it's not useful. It may be super cool, but if it's not actually reliable and stable and performant. So I think depending on the life cycle we are on, usually I lead with three to five values. The three are the same always, but then the other two might be different depending on where.
Caleb Brown:
That makes a lot of sense. That's interesting. That's cool. There's like a foundation. And then depending on where you are in the process, it kind of adjusts, which I think makes a lot of sense and is a good way to put it forward. That's very cool. When you and I met just on the prep call a week or so ago, we talked just passions of yours within an organization and diversity and inclusion is something I believe that you stated was something you're passionate about.
So playing off culture and teams, I was curious how do you work to cultivate a truly inclusive environment, especially in a global and totally distributed organization?
Rajashree Pimpalkhare:
So I have to start by saying the idea of diversity and inclusion as a concept came late to me or I came late to it, if you will, because I've had a very privileged upbringing. I grew up in India, but I grew up in a very progressive family. I was expected to really figure out what was my value to the world and go chase it. I came to the US at a time when the industries I worked in were I think really supportive of all individuals.
So in my mind I was a technologist for a very long time. Until halfway through my career, the gender difference never really touched me because I was in a very supportive environment and I was valued as what I brought to the table. It was surprisingly at PayPal actually where I first realized that because we are developing software at scale, these were large teams, these were globally distributed.
And prior to that, I had always worked in very small teams, like three to five people. So everybody knew each other really well. So what I found was just as humans, we judge people based on their appearance, the unconscious biases we carry, the expectations or the past experiences we may have had, and there is a huge amount of information that we go with. And this is not specific to men or women or different ethnic groups or what have you.
It's just as humans. We come into it and we judge people. That's what we do best. I think it's a critical skill for us to survive in the world. And a lot of times, depending on what you expect of people, you will see things in a different light. So the unconscious bias actually plays a huge role in how you perceive people and how you value them and how you work with them.
I think that really comes in the way of getting the best outcome from teams. The way I think about diversity and inclusion first is diversity is part of life. Because even if you have people with the... Let's say you have same sex and same ethnicity and what have you, you still bring diverse experiences based on your childhood, based on where you grew up, your financial status or what have you.
So the diversity exists everywhere. And inclusion really says, if you make people feel like they are part of a team or they have that sense of belonging, you're going to get much better work of them than you otherwise will. And that's I think also universally true. There is a third aspect of it, but let me just focus on given a team, you need to assume there is diversity, and you need to assume that without inclusion you don't get the best with that.
So any team that I work with, I make sure we get to know each other as humans. It's even more challenging when you're in a remote environment, but you really need to invest time in that to see where people are coming from, what forms them, what are their principles, what is their value system. I think it's important because that then informs your judgmental nature by this additional information.
I'm like, aha, okay, maybe I'll look at things differently. So I think that's an invaluable part of forming any team, to make sure the team actually gets to know each other and has a sense of belonging. And then the second aspect of it is the world is diverse and almost every company I've worked for has built products for the world. No products are built just for this one population or what have you.
So in order to build products for the customer base you have, you need to have a reflection of that base into the team that's working with it. And I think I also feel like as a woman technologist, there aren't that many of us in the world, and I think we could actually be better served by having many more of us. I also think of diversity from that standpoint to say by encouraging diversity or actually going to eventually get better business outcomes and because the natural paths of society are not leading to that diverse outcome, you need to focus on it and you need to invest in it.
Caleb Brown:
No, absolutely. That's helpful. I suppose expanding on that, I was curious what kind of actual processes and practices you found most effective for maintaining a cohesive culture when teams do span multiple countries and backgrounds, as you mentioned?
Rajashree Pimpalkhare:
Yeah, so I think we talked a little bit about the value system. I think it's really important to come together around the value system for the team and that says, what do you value most in how we do our work? The second thing that I always think of is once you have these set of values that you might be aligned around, you have to think of as a leader, what are you going to expect of your people?
So I think there are different styles of leadership. The one I always believe in like you, culture and value system and so on is set at the top and you need to lead with what you believe, and you need to have people on your team that either challenge it or align with it, but have the right roles and responsibilities. So then I think about it as you have a set of values and you have a set of roles and responsibilities on the team that you need to be clear about.
So while you want the collaborative set, you also want to make sure you are bringing the right talent onto the team that can work together. And then you look at what are we trying to achieve? So as a leader, your biggest job is to explain why are we going in a certain direction and what does success look like? And if you define success in terms of the customer benefit, the business benefit and, whatever, shareholder benefit, then you're going to get the most creativity out of people on how to go there and to contribute their best.
So I look at it as if you create a framework that is very clear and you allow people to have certain roles and bring their creativity in, then these differences fall away, because then you're all lined up towards the right goal and you're all lined up towards what success looks like. And that can actually be really effective.
Caleb Brown:
Yeah, no, that absolutely makes sense. Still talking about teams, I wanted to expand a little bit into scaling teams and even productivity. So I know you've led teams ranging from I don't know if those was quite startups, but much smaller teams all the way up to thousands of engineers. And I think that difference is interesting in itself. So I was curious, what are some of the key differences when it comes to optimizing productivity and process at these very different scales?
Rajashree Pimpalkhare:
So first of all, not thousands, but hundreds of engineers, I would say. Still a lot. And I think the easier way to think about it is you are either leading individual contributors or you're leading leaders. And again, I think the leading leaders can be at different levels of hierarchy. That's kind of how I think about it. I have some principles which say flatter organization work better than hierarchical ones.
Because at some point if you have several steps from the leader who's actually making decisions to people who are responsible for implementing it, you're going to lose touch. You're going to not understand what the implications are. So I try to make my organizations as flat as possible. That's one principle. The second principle, which is very specific to engineering, is I think of it as an engineering team's job is to build software.
But even more importantly, keep it running and keep it up to spec and keep it growing. Because the successful product is one that solves for a customer problem, but then keeps getting more and more customers and scales with that. So I always think of engineering teams organized around a durable ownership of platform, product outcomes, customer offerings and so on, where as a team you are responsible not only for building new features, but also maintaining.
And then depending on where the product is in its life cycle, your focus should be on one or the other. You're building a new product, it's all about agility and finding the product market fit and being able to build quickly. But then once you have a sizable customer base, you have to say your job one is to keep the product running and well and performant for what you have.
So this principle also helps because then you can form teams based on durable ownership of the platform. Another principle I look for is accountability. You hear it all the time. You hear it in all companies like, we have an accountability problem. But very often in engineering you have an accountability problem if you have an ownership problem, if you haven't actually defined, and those are two sides of the coin.
Because if you don't have agency in making decisions in deciding what matters most, then it's very hard to be accountable, because you can't be doing what somebody else tells you to do and then be accountable for whatever. It doesn't work that way. I mean, forming organizations in the right way and then around the right principles is very key, because then you can say, at every level of the organization, is the charter for the team clear? Are the objectives clear?
What success looks like, is that clear? And then are you enabling the leader of that team to make decisions that will serve those goals? So flat organizations organized around this idea of durable ownership, and then also making sure that you make the right decisions at right levels and provide people the guardrails, but then let them figure out what works best. Because even if you look at a leaf level engineering team, I generally think eight to 12 engineers on a team is a good size.
But those eight to 12, you might have all engineers that are senior and about, so they're quite capable, or you might have half the team that's new college graduates. And the engineering manager of the team is going to be in the best position to decide what are the right ways to lead that team and get the best out of it. So really leave the right decisions for the right levels of leadership.
Caleb Brown:
Yeah, that's a really good segue actually into the follow-up question I had there, which was just how do you balance standardizing practices across the team while still allowing some level of autonomy for different workflows across that team?
Rajashree Pimpalkhare:
I think such a great question because this is something that I had to tackle recently when I joined Twilio. I think there are two models, and again, different leaders, different type of industries, different type of software development practices use one or the other. I've always leaned towards this model of agency and autonomy and accountability, where like I said, you want to have people be able to make certain decisions.
There is another model which is described to me as engineering as a software factory, where you have the processes defined to such an extent where you know you feed something to the start and something will come out at the other end. And I think of that as optimizing for output, where you'll hear a lot of Jira-based or check-in-based metrics to say, this is our developer velocity or development velocity, and I think it's maximizing for output.
But then you put garbage in, garbage out, you'll still get a lot of garbage. But depending on the requirements, you'll get what you have. So I believe in the model of outcomes over output. So the idea that with supporting roles or other roles like product and design, typically product design and engineering, that's a great triad to work with. And I think of it as that triad is responsible for creating outcomes for customers or outcomes for business, and you measure the velocity of the team or you measure the velocity of development based on the outcomes that they drive.
So the best way to maximize outcomes is to be very clear about how you measure them, because then whatever you measure is what teams are going to perform towards. So I think of the implicit expectations that customers have from a product are availability, is your product on all the time, reliability, is it working, does it have quality issues, is it performant, is it scaling. All those are implicit expectations, and those I think of it as like hygiene.
We track, in my teams, we track it every week. We have dashboards, we have metrics, and we make sure those are performant. And if that is failing, then you need to go address that. That's the thing. And then depending on the products you're building, you want to have metrics that measure the customer benefit, measure the business benefit, measure whatever else that you're trying to move, and those are the outcomes.
And if you make sure that the teams are focused on optimizing for those outcomes, then the rest of it you let teams do what they want to do. And I should say the employee outcomes as well, because you need to... To some extent, the team itself is a product as well that you want to make sure you build strong teams.
Caleb Brown:
No, that's a really good way to put it. The team itself is a product. Here at X-Team, we have a lot of engineers and they're all working on different teams. And so something we think a lot about is that developer experience and how we can help our developers and even though they're working with different clients and different partners still have a cohesive and good developer experience. So I was curious what strategies and tools and technologies, just anything along those lines, that you've leveraged over time to enhance that overall developer experience and productivity as well?
Rajashree Pimpalkhare:
The best approach is to measure based on metrics how well teams are. I think a couple of other things I'll mention, and I have to say it's been some time since I ran a team at the first line of management, so a lot of what I'll say is not going to be directly applicable to engineering managers perhaps, but just to think of it as a philosophy of how you ensure good velocity. So some of what we talked about is the metrics, having the customer implicit expectations as engineering metrics that you track.
But then the other important thing is how do you set goals? We talked about what are the objectives? Yes, keep the product running. Well, that's one. But then there are also other pieces where I think of it as just as we have a product strategy and a product roadmap, you need to have a technology strategy and a technology roadmap that's looking around the corner to see what are the capabilities we might need.
Or if you directionally know where the company or the product or the business strategy is going, then what skill set you might need to bring up, what kind of training you might need to have. AI is a great example. So in the last couple of years, it's suddenly seen a huge surge in every company needs to build AI-based solutions. How do you quickly do that? So there is a technology strategy that needs to go along with the product strategy or the business strategy, and that's another way of making sure you are…
It serves all different things. It serves the business. It serves what we are trying to build and the customers. It also serves the team. Because while you have engineers working on your team, that is part of their career journey. They're also looking at where are they going from here. So as employees, when I say the engineering team is a product, you also need to look at how are you growing that team to keep up? I mean, technology grows at a phenomenal…
Changes at a phenomenal pace. I've been in Silicon Valley all my career, and I've worked on so many different things. So part of it is you have to say that, oh, are you delivering for the outcomes, but then are you learning in the process, and providing that guardrail to... It could be around development planning. It could be around what size of responsibility you have, what size of impact do you have. You need to address all those answers as well.
Caleb Brown:
Yeah, no, that makes a lot of sense. And I'm glad you mentioned AI just because as we sort of get to the end of the podcast here, I do start looking a little bit more into questions that involve the future and just looking forward a bit. So just curious where you see things like that, voice and video and messaging, communications just heading over the next five to 10 years with the innovation.
Rajashree Pimpalkhare:
I think we really believe that these are all channels of communication. As a company, we started out with single channel at a time. But as we work with customers right now, I think we can be a one-stop shop for them, to communicate with their customers or to engage with their customers through any channel that they want, in any country that they want globally.
So we definitely aspire to be that solution where they don't have to think about how do they connect to their customers and they can only think about what engagement do they want and how do they want to go to the next level. And all of this, AI plays a big role in that. I mean, if I go back and lean into the specific product that I've been leading, which is the contact center or a customer relationship management experience, we can bring a lot of information that is uniquely available to us.
So when you have Flex, which is the product, if you are using that for your customer relationship management or contact center management, when the call comes in, we actually know enough information about the caller, about the initial through IVR, the information we get through a chatbot that they might interact with. We have all the information and all the past information on the interaction to say, "You should go to this particular agent."
And it can even be based on, well, this customer sounded kind of irate. They haven't received their product a long time, so let me send it to this person who handles these calls really well, versus this customer is just looking for information and maybe they can just go to our website or they can go to this readout before we can answer their questions and move them to another bot or what have you. So we have all this information that we can bring to bear and solve for.
Or if as an agent I'm answering a question, we can bring them all the information as a copilot to say, this customer called five times in the last one week. They haven't gotten this. Last interaction was this. We told them that they will receive their order on this day. And they can have it on their side as they're talking to the customer. So there is a ton of innovative solutions we can bring.
Caleb Brown:
That's so cool. That's not even smart routing. That's like very intelligent routing. That's really cool.
Rajashree Pimpalkhare:
It is intelligent routing.
Caleb Brown:
That's awesome. I did not know that. That's very cool. Staying on that topic a little bit, kind of curious, as these ecosystems and APIs become more robust, how do you anticipate engineering roles and the skills behind that needing to evolve? And that actually also plays into AI as well. I'm just curious how you see engineering roles like that evolving as we move forward.
Rajashree Pimpalkhare:
So I think in my mind, the jury is still out. I know that there are people who are huge believers that AI is going to replace all the engineering and so on. But I think, again, I've worked in many different industries like chip design before my time was all done by arranging transistors and then we created a bunch of software and you could just synthesize a chip based on some description, and then we took it to behavioral language and so on.
So I think this type of innovation and simplification is going to happen constantly and AI will do that too. Right now you can go to GitHub and you can go to a copilot and you can get an initial template for code that you want to write like that. I think what's going to happen is the engineering and software engineering roles are going to get more and more focused on the harder problems.
I mean, you already have... If you remember, there was a time when to write a webpage, you had people really focus on that. Now there's software. You just click a few buttons and boom, a page is up there. I think that's my belief that AI will help us do many more things faster. I think it's when you're trying to write very optimized software, I think you're still going to need something more than AI to power you, but it certainly will make it easier to develop software.
I think of it as it's an essential tool that you should start using and you should start making up your mind on and seeing where it goes. And I think there is also going to be a parallel industry that starts to say you are using AI to develop software and do anything else, and then you'll need a set of tools to verify what you're doing is actually right.
Caleb Brown:
Absolutely, yes.
Rajashree Pimpalkhare:
So I think we'll have more software areas growing from using it in this space.
Caleb Brown:
Absolutely. That's awesome. Just curious, if you had a magic wand and you can wave that and you make one change that would positively impact software development practices and culture as a whole, what would that be?
Rajashree Pimpalkhare:
I would have to say have a really easy to implement method of getting telemetry about, have eyes on everything we do. I think one of the biggest challenges I feel is whether it's the processes, whether it's the development practices, whether it's actually the website and the systems, I think if we have a magical way of saying, "I can very easily get metrics on anything that I want," that would be my magic one. It's like no need to plum anything. I just say, "Oh, now I want to focus on this," and now I just have everything magically...
Caleb Brown:
I don't think that you are alone on that either. I think that would be a pretty great one. Someone needs to productize magic. We need to get there.
Rajashree Pimpalkhare:
If we're looking for magic, that's the one thing I would ask for.
Caleb Brown:
Very good answer. And like I said, that was the last one I had for you. So thank you so much for joining me today. This was really enjoyable. I learned a lot, and I've been impressed with Twilio as a developer and as just an observer. So this was such a cool discussion, and thank you again.
Rajashree Pimpalkhare:
Thank you.
Caleb Brown:
What an energizing conversation with Rajashree Pimpalkhare about nurturing thriving engineering teams. I loved how she brought to life her three guiding values: customer focus, engineering excellence, and transparency. Her stories about building trust through open communication and watching teams flourish when given both direction and creative freedom were especially inspiring.
One of the most compelling parts of our discussion was Rajashree's genuine enthusiasm for diversity and inclusion. She shared such a refreshing perspective on how diverse teams naturally lead to better understanding of customers and more innovative solutions. Thank you, Rajashree, for sharing your journey with us, and thanks to you, our listeners, for being part of this conversation.
Innovation is all about continuous growth and making meaningful impact wherever you are in your journey.
We're looking forward to bringing you more inspiring stories from tech leaders who embody what it means to keep moving forward. Find us on Apple Podcasts, Spotify, or YouTube Music, and spread the word if you enjoyed today's episode. Until next time.
