Inbal Shani

Rahul Abhyankar [00:03] Inbal, thank you so much for taking the time to be on this show. Really looking forward to our conversation. I really appreciate it.

Inbal Shani [00:11] Awesome. Thank you so much for having me. I'm looking forward to chat with you.

Rahul Abhyankar [00:15] We are at the early stages of this revolution with AI, and that was one of the things that I was really excited to talk with you about. How did you get into AI, and what did you see as the challenges with AI then and now?

Inbal Shani [00:33] That is a great question. I started working with AI when it was not even mentioned or called AI, when AI was very much a niche. I started my career as an applied scientist and I worked in the aerospace industry, and I basically developed Kalman filters for a living, for navigation systems, for different vehicles. The art was the art of tuning the Kalman filter—how you fuse all these sensors, what are the weights that you need to put on your Kalman filter, what are these models to eventually get a clean signal to tell you where they are. It was just the beginning of GPS being more commoditized. I've also done my master thesis on developing multi-input, multi-output controllers, and I was using what was at that time called genetic algorithms, so a Pareto-front approach, to tune that.

So I started really digging into the world of AI very early on, and then throughout my career I've encountered AI again and again, whether it's in the work that I've done in Amazon, in AWS specifically. I was part of the Alexa team, so getting knowledge of the world of natural language processing and what is conversational AI and how you use voice prompts and so on. And then recently in GitHub, developing Copilot and enhancing Copilot, continuing evaluating after the world of democratizing AI and LLM.

So if you ask me what are some of the big changes that I'm seeing in the industry when we're talking about AI? AI historically was at the hands of the expert, so you needed to be an applied scientist, you needed to understand AI, you needed to be able to develop the model, and it was very niche. So we developed AI for very specific use cases and you optimized that solution for that use case. And now, in the world of ChatGPT and democratizing AI, basically we're bringing AI to everyone. You don't have to be an AI expert to know how to leverage it. You just need to be able to focus on what is that application that you want to build and how is that application using the AI capabilities to develop that solution that you need for your product, for your customers, and what is the actual problem we're trying to solve?

Rahul Abhyankar [02:49] That's very fascinating because you've been at the forefront of a lot of these waves—early stage with respect to GPS and navigation, and then you were doing robotics at Amazon before even robotics was the kind of innovation that we see now. So how did you get into these domains that were really early stage and then contribute something to that domain to push the envelope forward?

Inbal Shani [03:18] I think it's part of my character. I'm very good in the zero to one as a builder. I like to be in areas that have a lot of ambiguity and that you need to go and figure out what is it that we're trying to solve and how to think about it. A lot of that comes from my history as an aerospace engineer, where I started my career, and that systems engineering thinking—the ability to look into a problem and dissect it to the different chunks and then figure out how to connect the dots, and then how you use that to predict what will be needed, and a lot about what will the customer need in the future, how this product will look at the end of its development cycle and working backwards from that.

So that's where my passion is. These are the type of problems that I enjoy solutioning. The combination of me being an applied scientist and a software developer and someone who is very familiar with hardware and then the product concept—all of that together are what keeps on pushing me forward to dive into these new ventures, new worlds of innovation.

Rahul Abhyankar [04:25] Were there some defining moments that built your philosophy around zero to one and just building that ability to look around corners? Is this something that is inherent, that you're born with, or can people learn this?

Inbal Shani [04:43] I think I'm fortunate to have both. I think it's the engineering instincts that I have developed throughout my career, and it comes from the fact that I was never afraid to try something new. I was educated as an aerospace engineer and I spent the first five years of my career as an applied scientist in the aerospace industry, and then started taking additional responsibilities, also managing software and managing hardware, and then taking on the systems engineering, which is basically the product management in aerospace engineering. So continuing stretching myself, putting more tools, more skills in my toolbox, and then doing the same, going to the automotive industry and then going to Amazon and then Microsoft.

Someone asked me, what is the weirdest role that you ever played in your career? And I said, I worked for customer service and I developed solutions that help customers self-serve. And people are looking into my history and my experience like, why did you do that? What pushed you there? Because I said that's a tool that I didn't have in my toolbox. That's a skill that I was still missing as a product leader, as an engineering leader. I was always developing product by finding a solution, but I never had a chance to work so close to the customer and really understand the experience that they have, then I'm missing that customer obsession.

So building that customer obsession by taking a role in customer service and customer support and customer success and figuring out how to help customers, that puts another tool in your toolbox. So the idea of getting used to feeling uncomfortable, and when you feel too comfortable, look for something else, because that means you already know what you're doing and you stop stretching yourself. That for me was a guiding principle. The ability to go all over the stack, solving different problems, thinking about different products, different customers, different markets, that enables me today to be much better in anticipating these corners, figuring out what are the next problems that will show up, saying, here's the mountain, when no one else sees that.

Rahul Abhyankar [06:45] That's great. The customer intimacy and that opportunity to understand where they are struggling with the technology or the challenges that they have, that really closes the loop as a builder, to be able to have that perspective.

Inbal Shani [07:01] 100%, and that gave me so much understanding and so much appreciation that, as product leaders, we often think about what is that next big innovation we can make and how can we make it include everything and think about every use case and every corner case that the customers are using. But then eventually, when the customers are ending up using your product, one, you can never anticipate all the ways that they are using it. And the second thing is, sometimes you're overcomplicating it for them. So really sitting in the customer's shoes and trying to figure out what is their use case going to be, how are they going to use your product, and trying to think about simplification. Customers don't like something that is too complex. It's hard to onboard it, it's hard to use it. Even if it has all the bells and whistles, it's not always the best product.

Rahul Abhyankar [07:51] This detour that you had with customer service—is that something that you sought out actively, or did that just come to you and you thought, well, I'm going to do this for some period of time, but my real passion is building software and I'm going to figure out how to go back to that after this particular stint?

Inbal Shani [08:10] The way I was thinking about my career—someone asked me, if you're looking back, did you plan your career? What I tend to say is, I didn't plan my career, but it didn't just happen. So I took deliberate decisions throughout my career. I didn't think that I'll be the CPO of GitHub—it was not planned when I was in my 20s—but the decisions that I took throughout my career, again, it's identifying what are the skills that I want to add to my toolbox, what are the things that I want to learn more, that I want to be better at, that I want to understand more and explore more. These are the criteria that I use in order to take decisions on the roles that I've played.

Did I think that I will be forever in customer service? I didn't know at that time. Every role that I'm doing, I'm assuming that I'm going to do it until I don't feel that I add any more value at that point, and I need to go and find a different adventure. That was my philosophy when I built my career.

Rahul Abhyankar [09:11] You were doing software development in robotics at Amazon, and then you went to Microsoft and came back to Amazon as a general manager. So that was a jump. How did that jump happen and what enabled that jump?

Inbal Shani [09:27] There is the title of general manager in AWS, which basically represents a multidisciplinary function that is managing both engineering and product, and it's the P&L responsibility. But if I'm looking throughout my career, more or less since my first management role, I've been doing these multidisciplinary roles. When I was in the aerospace industry, I built navigation systems and I was responsible in both the software, the hardware, the sensors, the design of the systems, the product management. So I played a general manager role throughout my career, and AWS was the first time that I had the formal title that represents that multidisciplinary function.

The big jump for me in going to AWS was enhancing my understanding in cloud and cloud development, and how I moved from—if at the beginning of my career developing software for a very small chip or a CPU—to really figuring out how to scale compute in the cloud and figure out what does that mean, enabling businesses to run on the cloud or going through a cloud transformation at that shape. A different thinking and a different skill in my toolbox is what does that mean, development in that scale and services, and you're no longer working with an end customer. You're now working with a business that is your end customer and they're building on top of your solution.

So I think that was an interesting learning for me, because I feel like my time in AWS enabled me to be now the CPO for GitHub, because I've had a chance to work with so many developers throughout my career, from being an applied scientist and writing real-time software, to after that doing web development, and then NLP and Alexa and chat, and then going to the cloud. So now I understand the variety of the developers that are using GitHub as a platform, which makes me think about what does that mean, a developer experience, and how we build these platforms for all these developers that have very different needs.

Rahul Abhyankar [11:30] At GitHub, obviously large community of software developers. But as product people, when we think about markets and segments of customers, we tend to see how to define those segments. So how does that apply to the developer community? Because not all developers are the same.

Inbal Shani [11:53] Developers are not the same. The way I think about it, when we're talking about GitHub, we're talking about the developer platform, and developers are not the same, but there is a big overlap between the developer needs. Everyone needs a place to store their code, everyone needs to do code reviews and software development lifecycle. All developers would appreciate if they had a tool like Copilot that sits next to them and helps them write code more effectively or shorten the boilerplate type of code when they're writing. All developers want to focus on solving the problem that they are, and not building infrastructure that is used to develop the code. If I'm developing an application or if I'm developing a navigation system, if I'm building a robot, I want to focus on that. I don't want to start figuring out all these tools that everyone is putting on me and figuring out how to connect the dots.

So in that manner, there is a lot of overlap between the developers. And then when you're looking into the community or looking on open source, and you're looking on businesses, you start seeing much more common ground between an open source foundation and an enterprise. You still need to have a space for all developers to collaborate. You want to see code sharing. You want to see thought process happening. All developers want to be productive.

I've read recently a research that GitHub has conducted that developers have less than 25% of their time actually writing code. The rest of the time they're spending in meetings, in collaboration, waiting for a build, waiting for hardware, waiting for something. So how are we making that 25% of their time writing code so much better, so they're much more productive? And that's the big driver for me when I'm thinking about GitHub—optimizing that 25%. And then what can we do to enhance better collaboration? So that's 50%. What can we do so they don't need to wait so long for a build? That's another going to the 75%. Can we do less meetings if we're using more async tools to get communication done, and I'm thinking about communications or projects? There's a lot of things that we can do to help accelerate software development lifecycle.

Rahul Abhyankar [14:02] You mentioned earlier the art of software development. When we think about art, there is a certain elegance to that output. When we think about writing code, it's only the end result of a lot of thinking that has gone into how do we design the system, how do we make sure that design is elegant. I've heard this said by one of the brilliant engineers that I worked with. He said, it's not enough to just write code that works. It needs to be elegant in terms of the system design and all of that. The code being written is the end result of a lot of that thinking. To what extent can that part of the software development of the engineer's workload be enabled with AI?

Inbal Shani [14:57] That's a very good question. If I'm very honest, I think right now the existing power of AI is a lot about removing a lot of the repetitive work. We still want to see software developers designing the system, and by Copilot taking a lot of writing the repetitive code or the coding element itself, it gives the developer much more time for the art of developing code, which is the system design.

Where AI in the future can be useful for system design is helping more as an educator. How does good look like? What is elegant? What is a more efficient code and less efficient code? What is a more secure code versus a less secure code? How can you learn from others? So how are we seeing the AI becoming more of an educator and a helper?

But right now we're still in a phase where we need developers to think about the system design and the art of writing code. But definitely we'll see AI developing more and more towards helping thinking about system design, whether it's learning from others, if it's showing you documentation, if it's giving you feedback on your system design and highlighting some areas of failure, maybe can run some tests and it will identify that your system design is breaking in these corner cases or it doesn't cover those corner cases. So AI will continue to enhance, it will continue to grow, but the core of system design will be at the hands of the developers.

Rahul Abhyankar [16:28] What's fascinating about GitHub is you've got a group of engineering teams that are users themselves. Typically what you see in many industries or many companies is engineering is removed from the customer. There are degrees of that removal just because they cannot necessarily relate to the customer in the use case, whereas that's not the case with GitHub. Do you feel that you've got engineering who's much smarter, much more aware about the needs of the users than perhaps product people are in GitHub? Because that's the dynamic that you see, which is reverse in many companies.

Inbal Shani [17:16] GitHub is unique in that manner that when we're building GitHub, we're not just building it for developers, we're building it for software development lifecycle. So our population that are using GitHub are bigger than just the software developers. We are fortunate that we have internally to GitHub our customers. So when the product is coming with a concept, one, most of the time it's done as a joint venture between engineering and product. And the second thing is that you have your tester within home to go and test whatever you're thinking is. So you have a sounding board, you have a customer advisory board, that basically is building eventually the concept that you have built. So I think that's one element.

The second element is that when we're thinking about the developers, even our developers are only representing a segment of the developers. They're not covering all the developers. So we have a representation, a bigger representation, but by far we're not covering all the—if we're talking about aerospace or automotive or fintech industry and so on and so forth. So this is where the product is bringing an additional perspective, representing the rest of the customers that are not necessarily just our developers.

But definitely we're in a unique place that we have that amazing synergy between having our engineers and our product leaders all coming together to solve a problem that everyone is passionate about, because that's their tool that they use. And in GitHub we believe in what we call eating our own dog food, meaning GitHub is running on GitHub. So we have a first-hand experience in GitHub, which makes the company much more customer obsessed, because we experience first-hand where we're failing when we're designing for developers, and what does success look like.

Rahul Abhyankar [18:56] I've heard you talk about the metrics that GitHub enhances, and one of those metrics that you've mentioned is developer fulfillment. How do you measure that? How do you measure fulfillment?

Inbal Shani [19:11] That's an excellent question. It's really hard to measure developer fulfillment. For me, developer fulfillment—there are input goals and output goals. For me, developer fulfillment is an output goal. When we're talking to developers, and we've done a developer experience research recently, what developers said is they feel fulfilled when they have an effective collaboration, when they feel that they're more productive, when they're getting recognition from their leadership on the work that they have done, and they get acknowledgement for the decisions that they are taking.

What we're looking into is, how do we measure fulfillment? What are these set of metrics that we can measure as an input that will eventually result in developer happiness? So we're focusing on making developers much more productive, whether it's with Copilot or if it's with projects and issues, with actions, everything that we can across the software development lifecycle, making developers more productive.

The second thing—we know that GitHub today is the largest platform in the world to lead collaboration between developers. We have more than 100 million users on the one platform that is GitHub. And then the third one is because you're running everything on GitHub, you can measure the developer productivity, you can see the collaboration, you can see the decisions, you can see the thought process. So developers will get much more appreciation from their leadership on the thought process because it's all in one system. And when you aggregate all these metrics together, you're getting that eventually developer fulfillment and their enjoyment.

A lot of the developers want to figure out that they focus on the things that matter. So if we're enabling to focus on the things that matter to them, the things that drive impact, and less on the infrastructure that they run their code, or less on writing code maybe that is repetitive, then automatically we're making them more productive, hence we're making them more happy.

Rahul Abhyankar [21:06] There is an aspect of, like you said, the 25% of time that a developer spends writing code, and how do we make that productive. But you really want software developers, engineers, thinking about what to build and the systems, and making sure we don't over-engineer them, so that we don't fall into the situation where we are building the wrong thing fast just because we are productive.

Inbal Shani [21:30] Exactly. It's not about the speed. We call it time to value. Time to value is, what is that time that you need to cook your idea so it's good enough? So we are thinking about all these use cases and nuances, and how fast can you experiment with that and learn from your experience? One of our leadership principles is ship to learn. We believe in putting things out there that are not necessarily 100% ready, but you start getting that feedback. So can we enhance that as developer productivity, because you shorten the feedback cycle?

When you're thinking about developer productivity, there are so many things that are in that statement, and everyone can interpret developer productivity. But I think developer productivity for me is much more than time. Time is one aspect of it, and for me, when I'm looking into time, it's time to value. It's how long does it take you from the moment you have an idea to the moment that you deliver the value that you wanted to deliver for your customer? That is a more important metric when we're looking into developer productivity than time or speed.

Rahul Abhyankar [22:33] You talked about fulfillment and the aspects that create that fulfillment for developers. As you look at the product management side of the house, is there a corresponding way to think about product manager fulfillment, and is that how you're looking at the PM organization that you lead?

Inbal Shani [22:55] PMs want to solve impactful problems. They want to make sure that they're delivering impact. When they're thinking about a product, when they're thinking about a solution for customers, they want to make sure that they have captured that entire space of the existing problem, but also the future problem. That's where product management magic is happening. They are venturing into these unknown areas. They're trying to figure out what is the next thing they need to go and innovate on behalf of the customer.

So product managers wear so many hats. They need to think like a developer. They need to think like a customer. They need to think like a project manager. They need to think like a CTO that is taking a decision. They need to think like a CIO that is maybe taking a buying decision, or like a CISO that is looking into a platform for security. So that's the uniqueness about a product leader—they have to represent all the segments of customers that the problem they're trying to solve exists for. And then they need to have that creative mindset and the ability to look around corners, the ability to look on, what is the end result that they're trying to achieve?

I think that is the biggest satisfaction for a product manager, when they are able to capture that space, when they're able to make it something that eventually will lead to a product, and that product will deliver value to the customers, and they'll see the customer adoption, they will hear the customer reviews, they will see that enhancement and meeting the goals that they have set up for themselves, and sometimes exceeding. That's the biggest fulfillment for a product leader.

Rahul Abhyankar [24:35] I've heard you say, Inbal, that you wanted to be your own worst customer. What do you mean by that?

Inbal Shani [24:45] I always try to think, what is the customer that will struggle the most using our product, and where will they struggle? And trying to predict that. When I'm thinking about a product, when my team is thinking about a product, is always having that customer chair in the room when we're having a product discussion or product design. What will that customer that maybe doesn't understand anything in AI, and we put in front of them a code completion or a Copilot, how will they feel? Will they know how to use it? Will they know to understand the value that is coming from that? What are these going to be the set of questions that a customer will ask us? Will that customer be willing to pay for that solution if they were in the room with us taking a decision when we're doing a feature, when we're doing a capability, when we're thinking about a new product?

Will that customer—our worst customer—will they sit in the room and say, yeah, I understand the value of what you guys are doing, I see how I can use it, I see where is all the documentation that I need to find in order to onboard to your product, and I'm willing to take my checkbook out and pay for what you guys are building? That for me is the worst customer. The customer that we need to figure out how to position the value in a way that they really understand it, and maybe the customer that will struggle the most to use our product—how we make our product usable for that customer.

Rahul Abhyankar [26:08] When product managers are learning about customers, learning from customers, how do you advise how much time they spend with the best customer and the worst customer?

Inbal Shani [26:25] They should spend time with all their customers—the best customers, the worst customers, the small customers, the big customer, they're not even yet customers, they're projected customers. You have to understand who are these people. Who are these customers? Who are these organizations that you're building your product for? It doesn't matter if it's a developer platform or it's the device that sits in your home that speaks to you and answers questions, or it's a robot that goes in the street and delivers packages, or it's a chatbot when a customer is coming to talk to and they're asking questions about, I'm struggling to install my Word, what should I do right now? You have to understand your customers. The key to being a great product leader is having a strong customer obsession and understanding your customers.

Now, where is the pitfall that is happening? You don't solve for what your customer wants. You solve for what your customer needs. Because when you talk to customers, they will come to you with a list of thoughts and ideas and feedback. All is great. You take it, you learn from it. You try to understand what is that customer actually needs when they're asking for what they want. Great product leaders know how to distill all this information into understanding what the customer needs. It's not just what they need right now, it's what will they need in the future.

Rahul Abhyankar [27:44] You talked about leadership principles. If I rewind the time on your career a little bit at Amazon, very famous for the leadership principles—customer obsession, working backwards. During your time at Amazon, was there an incident or an instance when you felt that this was an opportunity to apply those leadership principles? Tell us a story or two about that.

Inbal Shani [28:17] That's a good question. Let me think. When we have built the Amazon delivery robot, as you're fully aware, it's full of innovation, it's a new technology. It's an amazing set of engineers and product leaders coming together trying to solve a problem that is still very new to the market. A lot of ambiguity.

What I've seen is that the teams have a tendency to jump into that technology and figuring out, how are we integrating these sensors? How are we making sure that the robot is driving exactly in a straight line, it's not necessarily going left and right? The biggest question that I asked my team is, okay, we took the robot from point A to point B. How is that robot now delivering the package? What is that customer interaction that they have with the person that's supposed to come to the robot and pick up their package?

The team stopped for a moment and said, we didn't think about it. I said, before we know how to drive the robot from point A to point B, maybe we should work backwards from the end case. The end case is we want to deliver a package for a customer. How does that interaction look like? How to bring the robot back from point B to point A, from their initial delivery location to where they're supposed to deliver the package. How does that interaction look like? Is it a voice interaction? Do we expect them to have an app?

Also think about that fleet of robots that are walking the streets. What happens if a robot gets lost? Or if a kid is approaching the robot and they are like, what is that toy? And I want to touch it and I want to hug it and I want to play with it. How does that interaction look like? Really starting to figure out what is the end goal.

We're building a delivery robot, and the purpose of that delivery robot is delivering packages. That means a lot of human interaction throughout the lifespan of that robot. If you build a robot for a factory that works the floor, it's not the same interaction. So figuring out that human aspect—and that's the customer obsession that is on the Amazon leadership principles, and to be honest, it's right now a strong leadership principle across the industry. You see that in Microsoft, you see that in GitHub. Customer obsession is becoming a de facto for when you're thinking about a new innovation. Who is your customer? How are you going to interact with it in this case, or what is your set of customers that you're building your product for and how you expect them to use it?

So that was for me a big customer obsession moment, and I've done that role immediately after doing my role in customer service. So I was very much in the customer mindset because I just finished my tenure in customer service, and I don't want to pick up the phone call and talk to a customer that says, I found your robot in my backyard, what do I do with it right now?

Rahul Abhyankar [31:05] This aspect about customer obsession and working backwards—do you see companies struggling with this in terms of adopting that working backwards approach? At the end of the day, it all sounds very common sense, yet very hard to do. Why is that? There is that dichotomy where something makes so much sense but it's very much hard to do.

Inbal Shani [31:32] I think it goes to the origin of innovation. When you're thinking about someone developing a great idea, they're thinking in the back of their head, they're thinking about, someone is going to use it and here's how they're going to use it. But it's not always that crisp that they have, I'm working backwards from a customer because I have a great idea and it's a great solution. It's a great technical solution that I can go implement, or it's a great product, or it's a great book that I'm writing and someone is going to read it. So in the back of your head, you're always working backwards from a customer because if you're doing something like that, you're not necessarily solving a problem for yourself. You're trying to solve a problem at scale, so expecting to have a customer, a user, a person or someone using your product.

I think the struggle is to make it crisp and clear—what is that point in time that you're taking your idea from a great innovation to a usability element of that? This is where that bridge is becoming hard, because you're so busy in that innovation that you're driving that amazing idea that you have and developing and bringing it to life, and then you finish developing it, and then, oh, but the customer that I built it for and that I had in the back of my mind is not exactly the customer that I have right now. So how am I building the bridge between what I built to the customers that want to use my product?

That's where the working backwards is such a strong tool, because it forces you to stop when you have a great idea and ask yourself, before you start building, before you start writing a line of code, before you start developing anything, who is my customer? What am I solving for? What is the problem that I'm trying to solve? And then focus on that amazing innovation that you have. So it's not that the customer working backwards is coming before the innovation. The idea for innovation is the first, but before you pursue just with the innovation track, that's the moment you need to stop and ask yourself, who is my customer, who is my user, what am I doing it for?

Rahul Abhyankar [33:33] And that requires being out in the field, meeting, talking with people that you hope to solve the problem for. You cannot short-circuit that process.

Inbal Shani [33:43] No, and that's the era of product management. If we think about our job as product leaders, it's really doing that working backwards from the customers. Not all the innovation is coming from a product team. Not all the innovation is coming from the engineering team. Not all the innovation is coming from technical people at all. Innovation is happening everywhere, but the role of product management is taking innovation and making it real.

Rahul Abhyankar [34:07] Throughout your career, as you made the leap into leadership and management, how did that happen and how did you become comfortable with that?

Inbal Shani [34:19] I would say it happened by accident. I was hired to develop a navigation system for a company for helicopters, and at that time, if I remember correctly, my manager that was leading the team has left, and I was asked, as the most senior person on the team, to jump into a management role. I was not sure that this is what I wanted to do, because I really enjoy being an applied scientist at the forefront, innovating. But there was a need and I was asked, and I tend to take chances on things that I don't feel comfortable doing, so I said yes.

That was my first management role, and I started figuring out, oh, being a manager is not exactly being an applied scientist. You need to develop so many tools and so many skills in your toolbox that no one really teaches you. It's like being a parent. There is no handbook that tells you, here's how you're becoming a great leader. You learn a lot by making mistakes and you learn by experimenting and you learn by developing these relationships and how to empower people and when to delegate and what these audit mechanisms look like, and what are the things you need to do yourself, what are the things that you expect your teams to deliver on.

So for me, that was the first management experience. And when I started doing that, I didn't think I'm going to like it. I was a very hands-on person. I enjoyed being an engineer. It was my core. I was an engineer likely since I was a kid. But suddenly I figured out that being a leader is being engineer plus plus, because now it's not the impact that you're delivering—you can deliver much bigger impact because you're also enabling other people to deliver impact. And basically, instead of doing a function, now you're doing a product. And then, instead of doing a product, now you're doing a set of products, and then now you're managing such a large portfolio and you're empowering much more people to go and do that. So the impact is much bigger if you do it right. And that's the core of great leadership—how are you empowering your teams to deliver great impact? That's what brought me into a leadership position, and that's why I've never looked back.

Rahul Abhyankar [36:34] One of the things that I'm picking up from our conversation is you've continuously put yourself in situations that stretch you and continuously looking for those challenging opportunities, whether that's spending time in customer service or taking on this leadership role that you said happened by accident. But all these have been ways that you've stretched yourself, and that's a great theme to come out of this conversation.

Inbal Shani [37:06] If someone would ask me what's the best advice that you can give someone who's starting their career, is don't be afraid to take risks, because taking risks is likely the smartest thing that you can do. Some of them will be great learning experiences, some of them will be not so much, but it's still a great learning experience, because sometimes you succeed, sometimes you fail, sometimes you move forward, sometimes you take a step back, but overall you keep on growing and you keep on enhancing and you keep on having—if we talked about Amazon leadership principles, your learn and be curious is never put on hold, because you keep on adding more things that you know how to do. You keep on adding all these great learnings. That's what we are as humanity. We want to continue to grow, we want to continue to learn. That's the source of innovation. That's why we continue innovating at the fast pace that we are.

For me, that was a life motto. I want to continue to learn, I want to continue to grow, I want to continue enhancing my skills, and I want to be able, at any point in my career, to do the same for others. How can I help others continue to learn and grow? I've been doing mentorship for a lot of females in tech, because that's something that I've experienced when I went to my bachelor degree, where we were six women in my class because it's aerospace, it's not common to find female leadership. I took it on as a goal to myself to encourage other female leaders to continue stretching themselves, continue taking chances and taking risks, and continue enhancing what they know. Sometimes it's in innovation, sometimes it's in a leadership position, and sometimes it's outside their comfort zone completely.

Rahul Abhyankar [38:41] When you came back to Amazon as a general manager, and now you've been at GitHub for a year as a chief product officer, when you come into these leadership roles, how do you evaluate or assess the landscape of the organization and then create your own sort of mental model of areas for you to focus on and define your mission for the organization?

Inbal Shani [39:11] The biggest thing that I've done when I joined GitHub, as well as AWS and any other role, is listen. You talk to your team. You talk to your customers, talk to your partners. What do they expect? I spent a lot of time talking to as many people that I could to really understand what is the greatness that we have. What is that GitHub brand, that amazing developer platform that we have put out there? What does our customers think about it? What does the community think about it? What does the open source community think about it?

And trying to map what is the areas that are working amazingly and I shouldn't touch. I don't need to touch it. It works, don't break it. And what are these areas of opportunities that we have that will help me shape the vision for the product, for GitHub?

There were lots of learnings coming from that. Whether it's the idea that product leadership in GitHub is pretty new, it's a function that we have established in GitHub after the acquisition by Microsoft. Before that it was done, but it was not defined as a function that was leading change for the company. And ever since the acquisition, that function has been up and running. So let's say something like four years. GitHub has a solid product team, but that also means that the team is pretty new, and the concept and the practices of product leadership and product management is new to the company. So how do you help shape that vision for what does that mean being a product team, a product leader? What is the expectation from a product leader? How does a great product leader look like? What are some areas of opportunity?

And then the second part is, what is the product that is GitHub? What is our brand? What are some of the things we need to do in order to continue growing in the same rate that we have been growing, maybe even accelerating? And how do we anticipate the future of the needs from our customers? That's where I spend most of my time, is really asking these questions and trying to get as many feedback points that I can.

Rahul Abhyankar [41:09] Wonderful, Inbal. Who have been the people that you've looked up to that have shaped your way of thinking about products or leadership? Who have you been most influenced by?

Inbal Shani [41:24] There are two people that jump into mind. The first one is, I would say, Jeff Bezos. I really appreciate Jeff—when he was still the CEO of Amazon, he was still the product leader for the company. What I really appreciate about Jeff Bezos, he was never afraid of experimenting, even if it's not successful, and taking risks and shaping the future. He was not afraid of jumping into a venture of unknown and innovating on behalf of the customers.

And the second, which came before Jeff Bezos, was my first manager in the aerospace industry when I was still an applied scientist, and he was leading our systems engineering function. He's the one that taught me to look on the big picture, how everything is coming together, and really identifying these corners, or how to anticipate the mountains that are not there.

These two together—learn to be brave and don't shy away from experimentation, even if some of them will result in failing, is the failing forward; and learn how to anticipate the big picture and look around corners. These are the two people that have shaped a lot my product perspective.

Rahul Abhyankar [42:42] Very nice. We are coming to the rapid fire section of our conversation. Is there a book that you've recommended a lot, that you think everyone should read?

Inbal Shani [42:56] There is a recent book that I finished reading not long time ago. It's written by Dalia Feldheim. It's called Dare to Lead Like a Girl. What I liked about that book is a different concept of how to embrace female traits for leadership and how to empower more women to become a leader and stick their truth, because often we find women trying to assimilate. And that book is, on the contrary, don't try to assimilate. Lean in, be who you are, and find a way to influence from the point of who you are and your traits to become a better leader. That's a book that I recommend to everyone. It's not just for females, it's really also for the entire leadership. Learn, understand who are your employees, what are they thinking about. So that's a book that I definitely recommend.

Rahul Abhyankar [43:43] Beautiful. If you had to put a slogan on a t-shirt, what would that be?

Inbal Shani [43:50] I'll quote my manager in AWS—she's always right. As someone who has spent her career throughout the stack and have built different types of products, that engineering instinct, that product instinct, is very strong with me. So one of the leadership principles that was always tied to me is right a lot. It's a blessing and a curse, but that's something that I'm very proud of. I have these instincts to identify all the things that we can do better or anticipate some of the challenges that are coming. Although if you ask my husband, he will say she's never right. So maybe that's the backside of my t-shirt.

Rahul Abhyankar [44:37] What do you do just to decompress and take a step back? Are there rituals or routines that you follow for yourself personally that have helped you a lot?

Inbal Shani [44:51] I'm a hidden artist. I would say that's something I will do full time, hopefully when I retire one day. But I like to paint, and right now I paint in watercolor and I paint in gouache. For me that's a big decompression. If I can find even 20, 30 minutes in a day at the end of the day, just clear my head. And a lot of the problem solving is happening, because at that time you don't focus on anything besides paint on a paper and creating something more creative. I would say that's my creative outlet because I'm not an engineer anymore, and that's my happy time.

And the other part is just hanging with my kids and having a conversation on how was their day at school and really focusing on soaking as much as I can from that experience, staying with my kids as much as I can.

Rahul Abhyankar [45:41] Beautiful. Well, thank you so much, Inbal. I really appreciated you taking the time out of your very busy schedule to have this conversation on this show. You really shared so much rich, insightful aspects of your career that there's a lot of takeaways there. So really appreciated. Thank you.

Inbal Shani [46:04] Thank you so much for having me, and I hope it will be helpful for other product leaders, other leaders that are developing their career and learning from my experience and my stories.

Rahul Abhyankar [46:15] Absolutely. Thank you.