Jason Andrews

I am a vice president of engineering operations at Cisco Systems.

Yeah, so we keep the engineers engineering. There are folks that build product in the organization. They're the actual developers and the product managers. We're there to kind of support the operational arm of it. So I have the technical program management arm, which kind of oversees about 160 different products at Cisco releases.

We've managed the releases, the bug scrubs fixes, anything that we don't, like I want the developers developing and then my team's actually kind of handling all that overhead for them. Then I also have a group that does the tools. And so I do actually have a large group of engineers. They ensure our systems that we collaborate on, your JIRA, ZAHAs, different systems we use to do productivity applications. They actually run that entire stack, building AI and things like that. And then I also have another function in the team as a global lab services. It's about 1.2 million square foot of data center space globally.

And we have, it's basically where we test our hard wringing. It's where they have the bench, people are soldering things. They're putting them in chambers to manage your temperatures. We're running regression tests. We're testing out software for new systems or MPIs that we've had on the shelf for several years. So it's a huge, huge undertaking of our organization. But all that is to be said, it's to take that weight off the engineering team. So they're not having to do, "Hey, I'm gonna have to write code. "Oh, I've got to go make sure this lab equipment is set up." We handle that for them. Like we can do that, we can do the rack and stack, we can maintain it and show the networks and all those things are there. So you can just really run your software test as an example.

Yep.

That's a good question. I don't think I've ever thought it that way. But I think it's just anything that distracts them from what they're doing, right? One of the visions I've had for the team on the tools front and just in general, it's a philosophy. It's like, I want them looking at one screen. Whatever they're using, GitHub, they're using

whatever IDE they're using, they should never leave that application. We should pipe that information where they can just literally focus on creating product. If it means that they can query inside the application and pull in a functional spec that the program manager made sure was in the right place and was completed, and then they can do kind of spectrum and development, that's the goal. So it's trying to build that ecosystem around it. So these guys literally, their job, when I've met most softwringers, that's what they want to do. They don't want to do any of this other stuff. They don't want to go update these fields or this and that. They want to do architecture and write code and really just setting them up to be successful is really the goal of our organization.

Snacks do help with that, by the way.

Oh, huge differences.

I think we're struggling with it, right? But I think all organizations are, especially large technology companies. I mean, our chief product officer consistently says, "We should be the world's largest startup," right? But that's hard. And that's hard because, A, we're not in a green-filled environment. Most startups will be in a green-filled environment. They're deploying software that was never there previously, right, even that first few years. Their customer base is gonna be smaller. The number of implications, integrations, all that stuff are different, right? The guys that when we end up acquiring a company or folks that join in the startup world, they're like, "This move's too slow. "Why do we have to do this? "This is overhead and governance." But the problem is to sell in every country in the world, you've gotta have a lot of, there's requirements that you'll never capture. So we try to line that stuff up so they can do the work and make it more efficient. But it's viewed, especially from the folks that come in from a startup organization, as like, "This is all overhead. "We shouldn't be doing any of this. "It's just about building the product." I'm like, "Well, unfortunately, "we're a large publicly traded company. "We've gotta maintain a lot of compliance rules, "isonia, you know, all these things." So we really gotta kinda merge both of those world together because we do have some very startup-level enterprises. They function differently. And what we try to do is really get our legacy organization. So we have our large networking groups that have been around for 40 years, right? They're operating on code bases that are 20, 25 years old with 200 millions lines of code. Completely different ball of wax than the team that is creating that new and basically doing AI-driven development. We just released our first product. It was like 100% written by AI. It's out in the market today. And we're kind of advancing that journey to get to more of those. But it's a fundamental shift because we want these guys to run at the same pace these guys do, but it's not really possible. The IDEs haven't quite figured out how to handle the 200 million lines of code and all the ingletrydity dependencies and it doesn't have context in the application. And in this side, they're saying, "Oh, well, no, I can just plug in some specs and look, "I'm vibe-coding, I'm doing all these cool things "and look, I've just got a full application "and I built this." And it's like, great. How do we find the middle? And I think that's a lot of what we struggle with as an organization. And we're doing a good job with it, but I think it's still a struggle. I don't think I always will be, to be honest, right?

Not yet.

I think that we're a couple decades away from really when you point where you just, somebody's just kind of talking in the air and then it builds the application. But I think while AI is amazing, I go through and I was working on a strategic plan, I plugged some different things and it really did a great job of laying out, hey, these are some things you should think about, these are things you do,

but that's where the human comes into the loop. How do we actually make the decision? Where's true innovation come from? Is AI gonna be innovative? I think it will be to a certain degree, but it's never really gonna replace human thought, in my humble opinion. And so I think what it'll transition from is, and where I'm worried about this transition is to your point with the planes in the air,

is how does somebody get to actually understand how to build a large distributed application? Do you learn that without actually going through the steps of actually writing the code through the years and going from your entry level developer to mid level to senior level to architect, et cetera? There's a breadth of experience you gain there. If you actually take away what most companies you're trying to do today is automate or use AI to replace,

supplement the jobs that you see for those earlier in career folks, how are they gonna get the expertise? Now they will have experience in prompt engineering and things like that, but does that teach them the fundamental architecture? Right, because I know we all go to college, I mean, I studied software development a little bit, wasn't really my specialty, but I didn't learn enough there to step in. When our new college hires, it generally takes them a year, 18 months to really truly get up to speed where they're actually adding a lot of value to the team, but that's because it requires some knowledge. Now, I think AI can replace that function, but then how do you get that guy from a early in career to the senior VP, right? Does he just gonna jump because he can write better prompts, but does he actually understand the architecture of the system, the fundamentals of software? I think it's gonna be an interesting balance in that realm.

It's changed it fundamentally, right? Historically, if I was going to release an employee, right? Or we employee lease, let's pick attrition, because I don't want to say we're fired, you better, right? We have attrition, you know, Josh, you leave the company, and the typical thing is, oh, we're just gonna backfill Josh. Maybe the change we'll make is we'll look for a slightly different skill set or a slightly earlier careerless experienced person, but it was just a slot in. Now I'm really good at the thing is, hey guys, are we gonna need that role in 18 months? If we do the things that we are on a roadmap with engine to program management or the labs or with the tools, is that a role we're gonna need? Or should I take that role and push a reinvestment into prompt engineers or somebody to kind of go build these AI productivity applications for the organization? Should I take that from them? And it's a hard debate because again, we're doing all the planes flying and I'm kind of having to make bets on every position and we backfill and look at it and go, okay, is AI going to optimize this work to a point where I don't need as many folks in this space? And should I take that investment and put it over here? Right, it's a, there's a lot of time going into that,

that level of thinking and how we're structured in the organization. I think if leaders and teams are not thinking that way or they're looking at it, I think they're gonna be in real trouble, right? If you're just in a, you know what, I lost one, I gotta fill one, I gotta keep doing the same thing I'm doing. I think they're gonna get caught in two or three years with a completely out of kind of whack workforce. They'll be too heavy here and then they'll have to let people go, right? Which is the last thing you wanna do because it's just not good for anybody.

I think it's about the transition of what you spend your money on, right? Are you buying apples or are you buying oranges, right? In this scenario, are you buying people to do the work? Are you buying people to automate and leverage AI to do the work, right? I think that's really the fundamental question. I'm asking myself is like, is this a role that is gonna exist in three years? Is this a job that is going to become much more productive where I needed, I had 10 before, I'm only gonna need six now, so do I need to cut 40% of the staff or do I just let natural attrition take its time and then as that happens, invest more in this other space so I can continue to accelerate it's gonna hit growth like challenges, right? We're gonna leverage AI this next year or we've already done it to optimize about 20% of our workload in the program management space. We'll get another 20%, that next 60% is gonna get much, much harder, right? And that's okay, but so do I need to shift focus and resources to kind of thinking about the future, developing future applications and ways of working versus doing the same thing we're doing today and I think that's the transition.

I think it's, we obviously go after low-hanging fruit first, right? We know that, hey, I need to build an AI agent that goes out and checks program status quality, right? All the data that we do and fills in the gaps and does it, like that actually is easy. I say easy, my team hates when I say that, it's not that easy, but that is not the hard problem to solve. As we go upstream and as we start to, a lot of the work is not just on the, where I laugh, people go, oh, we're just gonna use AI for it. Again, in a startup world, that perfectly works. But in a larger organization with legacy tools and applications, especially in an older company, like, you know, go pick, you know, Cisco, we're working hard at it, but imagine other companies that have been around a heck of a lot longer, big banks, insurance companies, have a lot of legacy homegrown applications that are in their stack or they haven't upgraded and their data may not be in the best quality. You can't really use AI, right? These homegrown applications are not built to interface with the AI, you can pull it in, but how's the data quality, right? If you're asking 10,000 questions, you probably have a very low set of data quality and big companies tend to do that. And so then how do you leverage AI automation on that, right? Just don't think it's possible. People, I think, forget that and they go, oh, well, you know, to your point, I think conversation we had outside, you've used AI agents to do several things in your business around transcribing and things like that, right, that makes a lot of sense. But it's a bit more greenfield than having to go deal with like all this legacy process, legacy systems and modernize it. And that's where I think the engineering is because we bring in folks that kind of go, hey, let's go rebuild from the ground up. Let's leverage AI as the starting point, not what we're thinking about post and actually get these things developed.

Yeah, I think you laid it out about us, but I think that's actually a perfect statement. I'll probably use it. You can steal it. Thank you, I appreciate that, Josh. But what I wanna look, when you go in that context, complexity, that's that 60%, like that next 20%, it's more context and more complexity you're dealing with. That last 60% is a heck of a lot more complexity, heck of a lot more context required. And that's what, how do you replace a guy that's been at a company for 28 years and drives these decisions and processes? That's gonna take a long time to get there because there are a lot of things that, A, are not written down. It's not written down. How does AI do something with it, right? It's a process, it's tribal knowledge, et cetera. So I think it's gonna be a transition, and that's why I think that last 60% gets hard. And I think a lot of it is because you have to rebuild the way you work, because if you just try to, say, fit AI in your daily life today, meaning like, this is the way we're done, we're just gonna have AI do that. Like, that's not really setting you up to kind of do that transformation. You're just gonna, you're gonna get the 20%, but I don't think you'll ever get to the full 80.