We're going to turn to the AI architecting side of things. And as most of the room has been CX leaders, we wanted to pull in the discussion and get the perspective of chief AI officers and talk about how they are thinking about this massive transformation that's been happening and how most of the room, who are CX leaders, should be partnering with them. And we'll bring in that perspective. So I'm going to let folks introduce themselves really quick, and we actually had a delay in traffic for one of our panelists. So we've invited Krishna back on stage to join us. And if Howie joins, we'll pull him up on stage as well for this one. But it's my honor to welcome Bob Friday, who is the chief AI officer, has been for a long time for Juniper Networks and now part of HP Networking. So welcome Bob.
And Krishna, you need no further introduction.
The only thing I would say was I have a little bit of a networking background. So I was just talking to Bob Friday about it that when I was a support engineer, I was doing specifically network troubleshooting. Actually Javu was another engineer I worked with. So there's a lot of fond memories of troubleshooting networking problems. So this will be a fun conversation for me.
Yeah, absolutely. Thanks for joining us, Krishna. So Bob, I would love for you to share a little bit about your background. You've had a great career, good experience leading to this. But that role of chief AI officer, it hasn't been that long since you've had that role. So maybe explain to us what that means. What is your scope? What are you responsible for? And then tell us a little bit about the org and what you're focused on there.
Yeah. Yeah, Joe. So I usually tell people that 40 years ago I started as a wireless engineer. If you bet a dollar I ended as chief AI officer, you guys would all be millionaires by now. So the fact that I'm here as chief AI officer tells you something about how fast things are changing. My role at Mist Juniper and HP has evolved from automation, right? So for me, day two, real-time operations has always been about the next step in the evolution of automation. And I've been a firm believer that as we move to cloud in the networking space, I'm responsible for actually building self-driving networks for our customers. But I think when you look at almost all businesses as we move into customer experience, there's almost always a customer-facing part of the business that customer success has to deal with. And so I'm a big believer that product and customer success are converging. They're one and the same. And you'll learn at Mist, I basically took my data science team and my StreetRx here from Juniper customer. So I work very closely with them on a weekly basis on making sure we actually can help customers solve problems.
Fantastic, Bob. Thanks for the intro. I'm going to break and invite Howie to come up and join us.
Come and join us. We kicked off and thanks so much. I know you were in traffic. Come up and join us on stage. You can.
Thanks. I'll be joining. I inserted myself into the conversation because I was talking to Rob about network troubleshooting and I told him I used to do troubleshooting with Hobby Zoo many years ago.
At least 20 years, more than 20 years.
Christian, do you want to introduce how you guys go back a long way?
Yeah, let me introduce Jav and I back in, I would say 2002, 2004 we were at VMware and Javi wrote the virtual switch. So people who are familiar with virtual switch product for VMware, he is one of the inventors of virtual switch. And I was doing VMware technical support and I specialized on network troubleshooting. And a lot of network troubleshooting issues tend to be in the nexus of virtual switch interacting with your physical switch, physical NIC, and all that. It's a very complex troubleshooting process. I thoroughly enjoyed it. Some of them are like very arcane bugs and very difficult to reproduce issues. So I would go to Hobby's office and we would code troubleshoot the issues and bring in some very interesting cases to him, like support cases to him. So that has been my experience with Hobby.
Until very late in the evening, and then looking at the TCP dump of all the hex numbers.
Yeah, it's very fond memories. Yeah. So Hobby since then has become an entrepreneur. He started a company and you could probably tell what he did with that company and he had an exit. And right now he is pretty much an AI expert and popular speaker in many conferences. So I invited Hobby to join this event. Yeah, in the last seven years I've been a chief AI officer or the head of AI for three public companies. Right now at Gen Digital, and before that I was the senior VP of AI at Palo Alto Networks, and before that Zscaler. And I did my startup back in 2017 and then was acquired by Zscaler after IPO. So it has been a journey of doing AI machine learning for the last decade. And then in 2015 I joined Greylock as an EIR looking at quite a few interesting AI companies. So my last 10 years has been AI machine learning, but before that I spent so much time on the TCP dump CPU cycles before that. Anyway.
We also intersected at Greylock. I think when he was an EIR at Greylock, we actually met and I was telling him about that I'm starting a company called SupportLogic. This is the core idea. So we exchanged some notes back then. Yeah. And just such fond memories. And then who would have known 20 years later you are an entrepreneur in this space.
It's amazing. Small world. Welcome Howie. Thanks for joining us. We've had a lot of conversations today just around the AI agenda in enterprises. And I'm curious to get your take. Maybe we'll start with you, Bob. Where does CX fit in the overall prioritization?
I mean, I think in the case of Juniper, I think there's two stories here. One is I'm on the product side, customer-facing side. I think you look internally inside of companies. Almost all CEOs are asking for 20% efficiency. And I would say there's two big areas where they're looking for efficiency. One is around engineering and software. The other big area is customer support, right? If you talk to almost any customer support leader, they're under pressure to do more with less. And that's where I think there's an opportunity for customer support and product to work together, because usually if you're in a support group, it's because you're offering something to a customer right now. All that support is coming from customers your business is working with. And so I think that is a big opportunity for support is leveraging AI on both sides.
Great answer. I think you're speaking to these people's hearts and minds. Do more with less, but be better and be more collaborative within the organization.
Yeah. Yeah. I think everyone, and I would say I work with the enterprises, all the enterprises who are adopting some sort of cloud AI, it's not replacing jobs. What you usually hear is they're going from being reactive to more proactive. They're basically changing their time. AI is taking the mundane, middleman work out of the experience. And then your support team is getting much more strategic to the business.
Howie, what does CX mean in terms of your org and the overall prioritization of projects?
I don't have a lot to add, I want to say, because I deal with AI across different functions right now, not just support, every function. I want to say there are two major applications for AI that are going to make a huge difference in almost every company. I think one is support, the other one is coding for programmers. Everywhere else you see AI applications really depends on what you exactly do. Your mileage may vary. But I think when it comes to coding, when it comes to support, these two areas are going to be totally redefined. Like what engineers are doing, when we were at VMware, what engineers were doing or what QA engineers were supporting, as long as you're touching the code, I think your life should be totally different in the next few years. And the same thing with support. Now it doesn't mean support is eliminated or not. To me, it's going to be redefined. Before, you ask, you answer some mundane question. You get those things out of the way by AI. But you now can connect with your customers in a way that you never had time to connect with them in a different way. So I think AI is actually totally changing customer support and coding, plus every other area, but these two are major areas.
Yeah, Howie, we talked previously about the role shift. And if there are jobs in support that are being eliminated, and support has historically been a people operation, right? How do you see that dynamic changing?
You always need the people to produce, let's say software industry produces software, but other things too, right? And then there are people who distribute it, and then there are people who connect with your customers. Before, maybe just simple Q&A, right? Hey, it doesn't work or how do I do it? But guess what, with AI, some of those mundane stuff, that's the low-hanging fruit, should be automated by AI. But now you need to maybe the support engineer should be doing customer success, or you bring the conversation to a different level, right? Before it's very reactive. Bob also mentioned now you have to be proactive, right? How people are using this product, and then from their usage, from your understanding of the usage, you maybe help the product team to enhance it. So I just think it's not about elimination of the workforce, it's really about elimination of the day-to-day task. But they can afford to do something very different. I think you have to produce it, you have to distribute it, you have to connect your customers versus the company that's never going to change.
Yeah, that's a good point. Chris, I'd love to get your perspective running all of the functions. How do you think about the prioritization of resources? Right? Because that becomes a big thing in terms of planning, in terms of building product versus supporting product, because now we're talking about spanning all of these areas.
I think I'll draw from VMware experience as a support engineer and a global escalation engineer, and what CX meant for me, and then I'll connect it to this question. Back in the days, we started a group called Product Support Engineering, which is a nexus between connecting the dots between customer support, engineering, and product. This was an initiative that was done in 2002 and 2004. So it's not a brand new idea. It's been around for quite some time. And the core idea there is going back to what Bob was saying and what Howie was saying, is that a lot of this customer interaction data that you're dealing with on a day-to-day basis, right? Why repeatedly answer those questions? You can put a self-service in front of the customer and call it a day, but even better is to fix it in the product. That's where your point about being partners with product is very important. So that's the task I took at VMware. Hey, we can write a KB article, call it a day. Customers will find the KB article, we'll move on. They're going to get frustrated every time. If we get frustrated, they're going to see the KB article, they'll self-serve, they'll be done. Better to fix the product. So I would take those feedback and run into a different building where Howie used to sit and gently tell, maybe you should fix this issue in the next bug release because it's causing a lot of pain for our customers. So to me, that was a CX point of view. So CX is not just how support is interacting. CX is not just about how great your customer portal and self-service portal is. CX is also about making sure those issues don't arise by channeling it to the engineering team. But the challenge I faced is getting the signals and passing on to a different group, and running to the building doesn't scale as a company scales. And that was a challenge we faced with VMware as well. And this is what the mission of SupportLogic is: how do we scale that?
Yeah, right perspective. Shifting gears, popular topic, and this came up earlier today, is the notion, the old notion of build versus buy. And this is a favorite one. But with the rise of data science and AI, the concept that you shared earlier on stage of building the art of the possible, as you said, 20 minutes on an airplane to create an MCP server, that was incredible. So the question is, why isn't everyone building? Why should they build or not build? And then I'd love to get into the how from your perspective as a chief AI officer. I'll start with you, Bob. How do you think about that decision framework?
Yeah. So I'm a big fan of always, if you're doing a project, there should be a build and a partner bake-off. I would say last year we went through this exercise of trying to find a solution for doing public doc. And we had two internal teams trying to do some RAG thing, and I had five startups and two big companies. Turned out Perplexity won at the end of the day. It was just cheaper and easier. There was no domain expertise here that had become a commodity. So I always encourage people, where you're solving a problem like that, you should do build. I think the more interesting question is, is it going to be the big companies, IBM, all these legacy customers, big vendors, are they going to solve this for you, or is it going to be the startups? I would say my experience so far is the startups seem to have a leg up on the big guys. You think the big guys would solve this problem. It doesn't look like it's going to be SupportLogic that's going to start. You're still a startup. You're still in the cold crowd. So that's my experience for build partner. You got to try. I would say domain expertise where I found build comes in is when there's some sort of domain expertise that needs something special about the data or something that requires domain expertise. My latest problem is log files. Anyone working on log files, come call me afterward. That's my Yeah, log file. Anyone want to help me solve log file problems? I'm open to that discussion.
Yep. Howie, what's your perspective?
Look, the build, partnership, all those things are a constant topic. It never changes. I think from my point of view, typically what happens is, my VMware experience, people are always motivated to build something internal, right? That's engineers' mentality. That's always the case. And it just turned out that a lot of times between a demo and then production ready, sometimes it's a little bit apart, sometimes it's miles and miles away, right? And then a lot of times, as a leader, you have to have a point of view, you have to have the experience, you have to understand sometimes, yeah, let engineers innovate, they are closer to certain area, they should do it. But a lot of times what happens is, once you have a shiny demo, who's going to operate it? Who's going to refresh the data, for instance? Or all the everything. The example Bob mentioned, he didn't mention the external vendor's name, I can imagine some of the external vendors he's thinking about. And versus the build, we went through similar thing, right? Hey, what if we just use Google Amazon API and then we can do enterprise search as well? But guess what, you have to connect with all the data sources and it's a lot of the work, right? So people always underestimate, or not say always, people often underestimate all the kind of the sometimes dirty work to integrate, for integration, right? But guess what, integration sometimes is 90% of the work. Doing a shiny demo is 10% of the work. That's the piece. I would say when you think about build, buy, whatever partner, you have to be careful. You compare the shiny demo, it's all the same. Compare the whole solution, it's different.
That's a perfect segue to my next question, but I want to ask if Krishna had anything to add.
