Raj Yavatkar

Rahul Abhyankar [00:04] Raj, welcome to the show and thanks for taking time out of your busy day to share your journey. The lessons you've learned along the way, in some big or small ways, all add up to where you are today, so really looking forward to learning from your journey.

Raj Yavatkar [00:20] Thank you, Rahul. I'm very happy to be here and glad to see you again.

Rahul Abhyankar [00:25] Excellent. So let's start at Intel and VMware. You were a fellow, which I understand is the highest technical role inside a company. What does that mean, and how do you intersect with other organizations within the company?

Raj Yavatkar [00:41] I have two experiences, one at Intel and one at VMware, which are slightly different. At Intel, the role of the technical fellow, especially when I was appointed a fellow—this was the Andy Grove, Craig Barrett era of the company. There were very few fellows and the criteria was that you must have shown consistently an ability to make a strategic impact on the company in terms of driving new directions.

At that time, what I had done was I was in the networking business at Intel. We first tried to do merchant silicon for networking fabrics, but that project got canned. So some of us started brainstorming and came up with this idea of programmable network processors that became a new product category, and Intel was one of the leading vendors for that. So that's how I got into a position to be an Intel fellow.

When I went to VMware, there are very few fellows. There are two founding fellows and there are two more fellows appointed. There, I think they wanted to recognize people who are already industry leaders and how they could help. So it's different criteria, different role at both places. At Intel I was an individual contributor, so you have to influence across the company to get what you want. You don't have the resources directly available to you. Whereas at VMware I was given a position to do a startup, basically within VMware. So that's very different, where I owned architecture, product management, engineering. But Intel was really cross-group influencing and continuously convincing people to invest in something that you believe.

Rahul Abhyankar [02:18] Going back to that, in terms of influence, how did you intersect and interact with other functions and what was that like?

Raj Yavatkar [02:30] It wasn't very easy. I must admit, it's not very easy. Especially Intel has a tribal culture. Every tribe protects its time. The idea is to find like-minded people, make sure they participate in idea creation. They feel like they own the idea, co-own the idea, and then only you get bottom-up support to go to the engineering managers, product leaders, to socialize the idea and get it.

I did a lot of mentoring of junior technical people. Since I was a fellow, people always looked up to me and said, "How do I become a fellow?" I wanted to help them become principal engineers, senior principal engineers, which was the technical ladder. That sort of mentoring created a network of people who are willing to work with you. So that was the trick.

Rahul Abhyankar [03:20] Interesting. So as a fellow, you're looking ahead to emerging technologies and potential opportunities. How far off a horizon do you look at?

Raj Yavatkar [03:31] Intel had this process every year called strategic long-range planning, or SLRP, where the horizon to look at was three years, not beyond that. They said three to five years, but it practically became three years. It happened every year in May, and the output of that fed into the business plan. So that was a critical junction where product managers, engineers, architects came together. We even used to have face-to-face, and different people would come up with different hypotheses based on what trends you see. That was a great mechanism and process to use.

Rahul Abhyankar [04:06] I remember in 2010, Intel acquired McAfee, and I was at McAfee at the time leading product management for global threat intelligence. I came across a white paper that was about Intel's vision for cloud computing by the year 2020. They had a 10-year vision for cloud computing and Intel's role in it. Curious to understand, how does a 10-year vision get built up within the organization? How did that come about?

Raj Yavatkar [04:36] That was a very interesting thing. It was done for multiple topics based on where things were evolving. The 2010 example is very good. In 2007, actually, Amazon Web Services collaborated with Intel in terms of data center architecture and servers. I was part of some of that. The idea was to always paint a 10-year vision, understanding fully well that you may not be able to, but at least analyze what are the challenges you're likely to face and what are the opportunities.

I always found that exercise very useful, especially if it's done cross-functional. It's not just by technical people. There are some product people. Intel at that time was investing heavily, starting in 2004, in the area of user experience. These were social scientists who went and spent time in different places, for example, to understand the PC's future. They went and spent time in remote villages of India or other Asian countries, in Africa, to understand what their requirements were. They also were part of such a vision creation process, which was a very powerful idea in market.

Rahul Abhyankar [05:39] That's very interesting because at Intel, you tend to think about everything under the hood—Intel Inside, as they say. But then to have learnings from different parts of the world to understand how this technology, the PC computing platform, is going to evolve, the use cases that's going to bring up, and where does the plumbing need to go along with it. That's fascinating.

Raj Yavatkar [06:03] It was very interesting that initially, when it started, many of us, including me, were skeptical. You're talking to social scientists. They have no idea about technology. You're talking to people on a very different plane. But over time I came to appreciate what they bring to it. They thought of things that we never thought of.

Rahul Abhyankar [06:19] This ability to look ahead—what went into that thought process? Being able to look forward to that horizon, looking around corners, anticipating change in the environment around you at a macro level, industry level. How did you build the ability?

Raj Yavatkar [06:42] One advantage I had is a brief stint in academia before joining industry as a researcher and a professor. There you're constantly thinking of new ideas which nobody has thought about, because of competitive pressure in your tenure track as a professor, or even to get tenure or to get funding or great grants requires you to think like that. So that mindset gave me an advantage when I went to industry.

The other thing I started doing is I always like to ask questions. People found me irritating sometimes because I'd always question and challenge people on every assumption, and that doesn't go very well. People don't like it. But that was my way of understanding, because otherwise what happens? You think very incrementally. You go talk to some customers, you look at the competition, you thought of the next incremental future roadmap. If you have that mindset, you forget the bigger picture.

The other thing I always did, which I always tell our product managers to do, is talk to architects. They are not your competitors, but they have a very complementary role. I also used to very actively look at academic research, especially DARPA grant proposals, requests for proposals. DARPA always thinks way ahead and they have use cases only for military. You think all those technologies created silicon value—lots of them. Silicon photonics, a lot of stuff in there, semiconductor. So always paying attention to their requests for proposals and what they're doing, and conferences, also helps you understand where the trends are going to be.

Rahul Abhyankar [08:20] Excellent. So fast forward from there, you came to VMware, where you said it was a slightly different role as a fellow, but you had the opportunity to do a startup within VMware. Tell us about that experience.

Raj Yavatkar [08:34] In 2013, VMware had already tried to build its own public cloud, Cloud Air, and it was not a successful thing. People were very worried about VMware because VMware did not have a cloud story. People were leaving and stuff like that. When I joined, coming from Intel, people were a little bit skeptical. Is this a software guy? Is this a chip guy? If you come from Intel, everybody thinks you're a chip guy, and I'm a distributed systems networking software guy.

So my bosses, Raghu, who's now the CEO, and Ray—Ray especially told me, "As you are a new guy, you have a clean slate. Why don't you go and figure out what we should do with cloud?" I took the challenge. One of the advantages VMware has is the customers really like them. So I went on this tour to visit customers. I went to Minneapolis, St. Paul, Twin Cities. There are so many VMware customers, about 10 of them. I spent a week there to understand what the problem is.

VMware had defined a new vision called software-defined data center. The whole data center is software-defined and we had seven products in network virtualization, compute virtualization, storage virtualization, monitoring, analytics, all that. All those seven products had to be integrated to create a private cloud, and customers' complaint was that was too much. They had to pay millions of dollars for professional services, three to six months, to bring it together.

So I came back and wrote a five-page white paper that we should automate, with the vision to bring up the private cloud in less than a day. From three to six months, that's a pretty audacious vision. Raghu said, "Okay, you can go try. You can take some four or five people and create a POC." So by end of the year—this happened in March, April—by December, first week, we brought the same customers down from Minneapolis to Palo Alto and showed them a two-rack full of servers. Everything could be brought up automatically.

That demonstration was just to gauge the reaction that we can build private cloud. It was put together with toothpicks and gum. It was like a prototype demo, but they liked it and they told Raghu, who was the chief product officer at that time, "Yeah, this is something that will really help." At that point he gave me the funding. So it became a startup, because I had architecture, product management, engineering. That turned out to be my best professional experience. Now that product has more than a billion dollars in revenue. It's the only organically created product outside of vSphere, where the company was founded. Very good experience. It was like a senior VP slash fellow title, because I was also managing plus doing technology.

Rahul Abhyankar [11:12] Let me pull the thread a little bit on those trips to Minneapolis and conversations with customers. Love to hear your experience in terms of keeping a balance between listening to customers too much versus pitching your idea and getting their response and seeing how they react. You can never really trust what customers tell you. Their behavior is actually going to be more aligned with the reality.

Raj Yavatkar [11:39] My experience in that particular thing was, you do not want to take everything they say as the truth. You have to start asking questions to find what is underneath it. For example, when we talked to VP level infrastructure-owning people, their requirements, their needs are very different than when we talked at two levels down, where people who are operating the data center are bringing VMware things together. So distinguishing between what kind of input you hear from every level is very important.

Second, you have to, to some extent, be a little bit confident to the point of being arrogant, that you have to think that I know better in terms of what problem to solve, as long as I know what the problem is. Whereas customers will tell you not just a problem but their solution they want. That's what you have to separate out, and that's very hard to do. I made lots of mistakes, I can tell you, in the process to learn that over the years.

Rahul Abhyankar [12:53] So as you've been building these infrastructure-level technologies, embedded as well as cloud-based infrastructure and so on, in order for product managers to be successful in collaborating with engineering, what have you seen in terms of the attributes product managers have or need to have, how technical they need to be, in being able to have credible conversations with super technical people, engineers, fellows like yourself?

Raj Yavatkar [13:10] The product managers' credibility always depends on how close they are to the technology and engineering. The best product managers I have seen understand technology and they interact with engineers at their thinking level, at the same time making sure they abstract out things what they want. That's the most important thing.

Nowadays product management is a discipline where people enter it from engineering side, marketing side, sales side, and you see different characteristics of people. Sales engineers becoming product managers and engineers becoming product managers tend to have technical background. I've seen some people coming from marketing who take time to sit down and play with the product, play with the technology, to understand. They have a lot more credibility with engineers.

The second part—I always found it useful and observed people—the word collaboration can be interpreted in multiple ways, because it's not just a question of making people feel good and interacting. Instead, collaboration means that you truly create a working group in which people bring the ideas and you brainstorm. The best product management ideas I have seen happen when people have two, three hours sessions to bring together people. You have to bring people from sales architecture, sales engineering, regular engineering, and product management. I find the input coming from the sales engineering side very useful. People think, "Oh, they are very short-term focused." That's not true. They see the bigger picture many times because they're interacting with the customers.

Rahul Abhyankar [14:42] That's been my experience as well. People from sales engineering moving into product management have a much deeper appreciation for how that technology is being used by customers, the challenges that they face. They understand the customer side of implementation as well as the engineering side of development, and they are really able to bridge that very well.

Raj Yavatkar [15:09] The best example I have is Jay Chaudhry, the Zscaler CEO, a friend of mine. He came with that background and has built some really successful companies.

Rahul Abhyankar [15:17] So as you were building this startup inside VMware—it's now a billion dollar business or over a billion dollar business—you went through the process of doing this prototype that was held together by rubber band and gum, and then additional funding to go through that. At what point in that journey did you feel that you had to take into account the P&L, the financial aspect of building the product? How did that become front and center for you?

Raj Yavatkar [15:46] That was a big learning experience. Once we went to MVP status where we could go and try it out with the customers, we didn't have a sales force, because the sales guys were focused on selling the current products. This product automated, so that eliminated some of the services revenue because there was no professional services.

To make the case to get go-to-market support, it's the first time in my life I had to understand the finance requirements. It's not enough to get engineering budget. Now you have to go to other people. Luckily, we had hired a product manager from outside who had that prior experience. So we started interacting with finance. That required us to build a case for what the revenue roadmap looks like and how we are going to be able to generate the revenue, and that can be translated into a P&L and build a P&L. I must tell you that this is where the VMware execs helped out by bringing in more professional managers who were experienced. I could not be relied upon just to do it by myself.

Rahul Abhyankar [16:52] But that experience of knowing go-to-market strategy and all of that—how do engineers get a better understanding of what it takes to sell a product? Because a lot of times we focus heads down on building the product, adding new capabilities with every new release, understanding from customers, but the aspect of go-to-market and how do you sell, the sales process and the messaging that needs to go along with that value proposition—tell us about your learnings and takeaways from that, and how do you think that can be part of what an engineering organization learns?

Raj Yavatkar [17:29] There are a lot of learnings now applied in my current job as a CTO. One of the things early on I learned is that you have to build a close relationship with the finance counterpart, because they are the ones who ultimately are going to help you do the analysis, and their support is necessary.

The second part is, you asked a very important question. Having a good idea of product is not enough. How does it get to the market? How does it get sold? What's the current go-to-market vehicle we have? Because you cannot invent a completely new go-to-market. The sales guys will not take it. They have the quota, they are preoccupied with that. So you have to figure out the current go-to-market motion and how can you ride on the back of that. Without that, it will not work.

Sometimes at VMware I had given a sales overlay—sales guys, three, four—just to make it easier, because you bring them in. They have existing relationships with the existing sales force. They understand go-to-market. So that's another way you can ride on the back of the current go-to-market motion.

For example, in case of VMware where vSphere or NSX or vSAN products were there, they were sold in a particular way, and you have to find that your product, which is integrating these products, somehow sits at the back of that go-to-market motion. In my current job I try to do that, because I'm basically incubating new products as part of my role and I have to start thinking about how I'm not going out far left somewhere, but it's more in conjunction with the current go-to-market motion. That's when you partner with sales engineering, sales architecture, and some of the friendly account managers who are willing to think out of the box.

Rahul Abhyankar [19:15] I was going to come to Juniper, so that's a good segue. In your role today as the CTO, what are some of the processes, rituals that you have as part of your organization—the long-range planning, the annual planning cycles—and how do you engage engineering and product? Product does not report into you as the CTO, so that's a separate organization. How do you then bring that together with you and the chief product officer, engaging your organizations into this long-range planning as well as incubation for new ideas?

Raj Yavatkar [19:50] One of the things I started is a new process at Juniper—new for Juniper, I have done before—called pathfinding and incubation. Pathfinding is where we look for a funnel of ideas. The sources of those ideas can be any engineer, any sales engineer, sales architect, product manager. I take those funnel of ideas and then we qualify them as to which ones we should pursue, based on key criteria. Like whether it's an adjacency to existing product, because then it's easier to go to market. Is it going to have a bigger revenue portion? For me, another criteria is software. We are trying to increase the company's ARR revenue from software, so it has to be done.

Once you do that, assign two to four people to an idea to try it out, give them three, four months to come back with something. If that fits the requirements, then we make it a pathfinding project with an actual number of people assigned to create what I call a minimum viable demo. It's an idea based on MVP, but it's not quite MVP, but it's not a science fair demo that you throw across the wall. It's basically something that you can actually deploy in a customer environment to do a pilot. So it has to be robust, and that is used to collect feedback before we decide whether it can go into business incubation or not. Business incubation will try to make it a regular product with sales revenue and stuff like that.

That's a decision I make with my CPO. The first decision is mine. First phase is all mine, my resources, I can assign them. But incubation phase requires his buy-in, because he sees now this can be built into a new revenue-generating product.

Rahul Abhyankar [21:31] I like what you said about the minimum viable demo. The term minimum viable product, the MVP, has been so overused, abused, burdened. People get wound up in different shapes when you think about what is an MVP and what it is not. But this minimum viable demo—how did you come up with that?

Raj Yavatkar [21:50] I was trying to think about it based on my experience at Intel. Anytime you build something—POC, prototype—people will be very skeptical how robust it is. Is it just a science fair demo? I have always heard people coming and saying, "It's okay to do a demo, but that's not a real product." So I wanted something that will gain credibility with internal stakeholders. The best thing is to go to customers, ask them to try it out, but they are not going to try it out unless it's robust enough. So that's what this concept of MVD came about, and people liked it. So far I've gotten really good responses from that. Recently we did a pilot for a completely new product I'm building at Equinix. This is a colo service they provide, and their feedback created credibility to be able to take it to the next level.

Rahul Abhyankar [22:42] Excellent. Coming back to that customer angle a little bit, all customers are not cut by the same piece of cloth, and whenever you are taking something new, a minimum viable demo to customers, you also want to have customers who are innovative, forward-thinking. How do you get a sense of whether this is the right customer for the minimum viable demo or not?

Raj Yavatkar [23:07] That's the hardest part. If you just talk to the infrastructure people, they will be very polite, they will look at it, but they may not adopt it. So finding the equivalent CTOs, equivalent function in other organizations is very important, because they are open to new ideas.

When I was at Google Cloud, we tried to do a completely new product, and I still remember trying to sell that idea to many customers, and people were saying, "Solve your current problems first. We currently are not delivering what I want. I don't want to hear new ideas." But I still remember one of the customers, a Southern healthcare company. I really hit it off with the CTO and he said, "I would love to try." That helped a lot. If you find the right sales guys who are also a little bit forward thinking, they know which of their customers is likely to be more open to new ideas.

Rahul Abhyankar [24:01] As a CTO, how do you embed this DNA into the organization, your habits about asking questions, being persistent with questions, ideas? How do you build that curiosity, innovative gene within the organization?

Raj Yavatkar [24:22] I do two things. One is that every two weeks I have an extended staff, which is people at staff engineer level and above—they come, senior staff and all—and my rule is that I do not move forward in the meeting unless people ask questions. I call out people who are not asking questions. The idea being, because people tend to be very reluctant to ask questions, you have to encourage them by calling out people. I figure out the three or four people who are always willing to speak. I use them as a starting point, then ask them to shut up and let the other people jump in.

The second thing I do is that every about month or so we have all-hands where somebody comes and presents an idea. My rule is, in the all-hands, the last two rows have to ask questions. Because as a professor, I would not go forward in my teaching unless the questions came from the last two rows in the classroom, because the most passive people, you're not sure they're even listening to you. But if you stop the class saying, "I'm not going to go forward until you ask a question," it's pretty embarrassing to people and they will. My team has gotten used to it now. They know that I know people by name, I'll ask them. So that creates the culture of feeling okay to ask questions and be curious.

Rahul Abhyankar [25:44] You also talked about this funnel of ideas and that ideas can come from anywhere, any part of the organization. So how do you encourage people to come up and contribute ideas? What do you use as a mechanism to create that funnel and then evaluate that funnel?

Raj Yavatkar [26:04] When I started this, I started almost like an evangelist and I volunteered to go to people's staffs to present the idea of pathfinding. There I would solicit ideas and tell them that I'm free to be approached.

One idea example I give is that there's a very smart sales architect in data center business, and he had this idea that there should be a pre-designed sales design tool to design a network fabric before we give our fabric. We're very proud of our fabric automation story and all that stuff. But he said, "Customers don't think like that." So he came up with the idea. I put two engineers on it, and now that tool is now commercially available to our customers. I started advertising him every time I got a chance—not to present a success story, but his name and recognition for him. That encourages other people. You have to create the sense that you're celebrating other people for doing it.

Rahul Abhyankar [26:55] Excellent. We'll come to the lightning round of this particular podcast. Who are the leaders that you've admired and learned the most from?

Raj Yavatkar [27:04] Probably the most admired leader is Andy Grove. He was amazingly strategic, visionary, but also extremely practical. He could look at the inflection points—he worked very closely with Clayton Christensen on his books—but also at the same time, he was not just a visionary strategist, but he knew how to implement or translate that into something pragmatic. I still remember he used to say that we have to disrupt ourselves before somebody else disrupts us, and that he tried to follow all the time. He came up with Celeron. People said he's going to kill Pentium, but he said if you don't do Celeron, somebody else will do it, so we have to do it. For me, he's the most admired leader that I have followed and learned from in my entire career.

Rahul Abhyankar [27:53] You have quite a few collection of books there, and I'm sure that's only what we see on the screen here. I know you have a much bigger library. Which is a book or two that you've recommended the most to people?

Raj Yavatkar [28:07] The other admired leader which I followed very closely is Ben Horowitz. This book, What You Do Is Who You Are: How to Build Culture in a Business, is my favorite book. I recommend it to many people, gifted it. It's the most important book for any organizational leader.

How to build organization, how to build teams, how to manage a project is a book by Andy Grove, High Output Management. I must have given away so far as gifts to people 25, 30 copies of it. This is a Bible for anybody who builds a team and wants to be a good leader. Those two guys are my really role models, and the books are amazing.

Rahul Abhyankar [28:50] Excellent. What is your favorite interview question you like to ask when you are interviewing people?

Raj Yavatkar [28:55] What's the one single important mistake you made from which you learned the most? That question brings out so many interesting stories, and it also shows the humility of the person to be able to remember what mistakes you made.

Rahul Abhyankar [29:10] By that same token, are you willing to answer that question?

Raj Yavatkar [29:15] Oh, absolutely, yes. Many of the successes I've had, I believe came not just by plan. You just hit the idea. But I made lots of mistakes. One of the mistakes I made is that sometimes you get so preoccupied or you love the idea, you forget about what is practical and keep on pursuing it. This happened to me at Intel. I ended up wasting a lot of my time and other people's time and resources. But I learned a lot from that.

Many times it's not the technology and idea. You have to also look at it from the other end. Start from what use case you're trying to solve. How do you solve it? Is it useful for somebody or not?

I'll briefly give an example. This is Roni Friedman, who was a design manager at Intel Israel, really educated. I was very proud of the fact I had come up with something on a chip design, a design for manufacturing test validation circuit that will save the area—not the area, but it saved the number of people used for testing. It will cost a little bit of area, but it will save about 40, 50 people. This design manager explained to me, "Even if you save 100 people, I don't care." I was shocked. Why would a design manager? He said, "I make every product with 100 to 200 million chips every year. If you save me even half a centimeter square—half a millimeter square—it's a lot of money for me. People cost—I don't care."

Until then I was so proud of that. That's one example. There are lots of such examples I can give you. I completely changed my perspective about how to think about the business, how to think about the finance, how to think about what matters to the product manager.

Rahul Abhyankar [31:07] It shows your humility, Raj, when you say that a lot of your successes have been serendipitous, but then what you really learn from mistakes.

Raj Yavatkar [31:17] I fully believe, with examples I can give, truly believe that when you start out, it's very easy to look back and later on say I had a great vision, great strategy, but many times you forget how many times things did not succeed.

Rahul Abhyankar [31:32] Well, I think this has been a fantastic conversation, Raj, really insightful. Thank you once again for taking the time to join me in this episode.

Raj Yavatkar [31:41] Thank you and wonderful talking to you. So good luck. Thanks.