AI Spend Needs a Business Case, Not Just a Budget

Hey guys, thanks for the intro. We're here with Kevin Nanney, who's chief product officer for Tempo Software, and we're having a chat about, well, all these AI coding tools, and we may be suffering from a plethora of too many, or maybe we're just drowning. We don't know what we're doing.

But Kevin, welcome to the show. Thank you, Mike. Thanks for having me here.

So the question that's come up now is that we finally, first of all, beat everybody up to use AI coding tools, and now they're all using it, and we're kind of swapping in and out tools and models, and everybody seems to be enjoying themselves, but nobody seems to know exactly what's going on, who did what, when, and where, and most importantly, which of these tools is any better than the other ones. So, do we need another level of maturity here? What's going on from your perspective?

Yeah. Well, it's interesting. So we talk about this a lot.

With all the advancements we've seen, it used to be that writing the code and the building aspect of software was the hardest part. Now we flipped it. Building has become easy, right?

There's all these tools, there's all these models, there's all these things that we can use to build, and it's become easy. And now it's making the decisions up front that's become very difficult. But, back to your question about all the models and everything, it can completely get away from you.

AI spin is-- look at all the companies that have put in user caps, right? They've spent their budget within the first quarter or two of the year that they had set aside for the entire 2026. So we have to start looking at how we're measuring that AI spend.

And everyone can measure spend. The question is, can you tie that spend back to the actual work that's being done? Because like I said, there's stuff that's becoming easy and there's stuff that's making the upfront decision part hard.

But having all the information of where that AI spend is exactly going will smooth out all of that. How do I tie spend to value? Because not all tokens are of equal value, right?

They may be of equal cost, but the token that you use to create some killer feature versus the token I use to create some PowerPoint slide for the marketing team may not have the same value. So how do I assess that in some meaningful way? Right.

And so that's one of the things that we're working on here at Tempo Software with our workforce intelligent application. And it's interesting, Mike, because if you look at just-- Let's just look at an R&D department, right? And if you look at the tools that are out there, it's one of the fastest commoditization areas I've seen.

And I've been in software for over 27 years, building this stuff. And it's one of the fastest commoditization times I've ever seen with software. And that is taking the spend and attributing it to throughput, right?

And so if you look at some products that are out on the market and everyone's rushing to build an AI attribution spend management product, and they can go out there and they can tell you exactly what you spent, and they can even tie it to certain teams and whatnot. But what's missing, and back to your question, what's missing is how do you tie it to specific work and then put a return on investment against that work? How do you tie it to that work item and then to an objective for the company?

So like you said, I've got teams over here that are working on a discovery project. I've got teams over here that are actually writing code against epics and stories that are in Jira. I can go in there with workforce intelligence.

I can tie the AI spend against those work items and tie it back to a company objective. But if I misinterpret that discovery work, which I'm going to associate that to your marketing spend, right? " But if I don't know that that's a discovery against a certain project, I might think that that's just spend that's going out the door for no reason.

So, really, the key here is being able to tie that spend specific to the work and then tie it back to the objectives for your projects, your company goals, whatever it might be. You have to be able to tie it back up through that process. How dynamic is all this going to get?

I think early on, people kind of chose a tool, and the tool was attached to a particular LLM, but it seems as we go forward, I may have a tool that is more loosely coupled with the LLMs, and I'm dynamically routing requests to different LLMs based on cost and capability. Is that kind of where we're headed? That's exactly where it's going.

Actually, I was just in a conversation with a router company last week, and the whole thing is, I can tell you from using my software, using Tempo software, I can tell you that the spend is being attributed to the work. " I probably don't need the highest cost LLM for just doing discovery work, for example. That should be routed somewhere else.

Have we kind of maybe gotten ourselves tied up in knots here because you will hear people who are saying that, "Well, I have to cut the number of developers I have to pay for the AI consumption of the other developers," but I thought the whole point of this exercise was to enable more developers to build more stuff faster and hopefully safer. Yeah. Well, again, and I'm going to sound like a broken record, but if I can tie the spend to work, that might be the case.

Maybe I don't need 120 engineers over here. Maybe I can put that work elsewhere, or maybe I can just not have 120 engineers on something that it doesn't need. But you can't make that decision without having the information in front of you, right?

And so I think that's what's going on. Actually, I was talking to another chief product officer, and we were talking about a company that he was with, and he said, "I cut out all my QA. " And three months later, he hired three-fourths of that QA team back to the company because it just wasn't working.

He couldn't attribute that work to the right place, and everything was just sort of running away from him. And so, there's a ton of learning that's going to take place. But again, I go back, and you have to have the right data context in front of you against the business context, right?

So having all of that usage, all that spend, all that cost attributed to the right thing against the business context is the most important thing so that you can make the right decision versus just, "I'm going to cut this staff because I think it's the right thing to do based off of just our spend is overwhelming," is probably the wrong thing to do unless you have the context. On the other side of that, I can't help but wonder if more software engineers are available, that other companies will hire them, and these companies previously might not have hired them because, well, they couldn't find them and retain them and afford them. So, is the marketplace going to change a little bit where I might argue that software engineering, at least at this level, has been limited to maybe the Global 2000.

Does it become more of a mainstream motion now? What exactly do you mean by that? Well, I mean that if I look at DevOps adoption, it's driven mainly up into that Global 2000, but if there's more software engineers available because we have smaller teams in the Global 2000, they'll be working arguably in the mid-market.

So there'll be more companies doing software engineering, theoretically. Oh, I see where you're going with that. Yeah.

And actually, yes. The answer here is yes. Because even within You know, I go back to writing the code has become easier.

And so, it's changed our SDLC process, and we're not a global 2000 company, right? But the different departments and the different things that you can build coming out of-- I can have a product manager take it almost all the way to the end and hand it off to an engineer. Everything is changing today, right?

Because with AI, writing that code and building has become very, very simple. And so everyone's building, everyone is building, everyone's hiring these builders, and so every department has the ability to do way more things than they could before. And it's funny, I spent a ton of time at a big IT service management provider, one of the biggest.

And the one thing that we always hated was ghost IT, and it was different departments going off and spending and building. And then as a PMO inside of IT, you really don't like that because you've lost control of a lot of things. You get application creep, you get scope creep, you get all these things that start happening within the company.

This has accelerated all that, to your point. " Fine, I'll just put a couple people and we'll start building it. And that's happening very rapidly.

Right. And is the nature of the teams, to your point, changing, where not everybody on that team is a professional, quote-unquote, application developer? There's going to be a lot more of the citizen developers that are a part of those teams, AKA business users who are tech-savvy.

And so will that expand our understanding of what we think of as the quote-unquote software engineering team? Yeah, I do think it starts to redefine some of these roles, these traditional roles that we've had. I actually saw a head of recruiting who was tech-savvy start to build all these applications for managing the recruiting process, for example.

What does that do to the applicant tracking software market? What does that do as you start to see all these pop-up applications? But they're very centralized, they're very specific to the company.

It's not like they're building enterprise applications that are being delivered. I wouldn't expect me to go into an enterprise company and, as Tempo, we're having this continuous planning conversation. We're having this workforce intelligence conversation, managing AI and human spend together.

" And that's enterprise ready, it's auditable. And so it'll work at certain companies, but at the enterprise level and at companies that need to go back to their board and have proven use cases of what they're spending and why, that's not going to work. So what do you see customers struggling with most these days?

As you look at all of this, we seem to be piling up more code than ever at the front end of the workflow, but I'm not quite clear what's happening to the actual pipelines. No, you're right. And there's two big things that I think we're seeing the most of.

The first one is what you and I have touched on, and that's attributing the AI spend to the actual work with business context. And I think we're starting to feel that almost with every conversation we get into. It's like, oh, well, I can measure my AI spend, but I can't tie it to the work that's actually being done.

How do I do that? And then how do I take that business governance and how do I control the agentic work that's taking place, right? And so Tempo's given them that governance, it's given them that business context.

I think the second biggest thing that we're seeing is, I'll use the word drift, plant work, scope creep, whatever it is that you want to use. But companies are doing so much work, to your point, so much work up front. Is it aligned to our company objectives?

Is it the work that we're supposed to be doing, or has AI gotten to the point where you can do so many things that it's starting to mask its inaccuracies to the point that we're doing all this work and it's drifting away from our objectives. And that's happening very fast, and companies are having trouble getting control of that because you've got every department can build, every person can go build and go do different things. Are they doing the right things?

Are they working on the things that matter most to the company, to the objectives that were set out? " Now that's happening in a week or two. And if you don't catch it right off the bat, that drift is happening at an incredible rate.

And once it gets to that point, it's so expensive to get back. You've already spent it, it's gone. So that's probably one of the biggest problems we're seeing out there.

" I think the thing that I see is, and you hit on it earlier, I see a lot of people out there just building and building and build because you can. It's cheap, and you can go build. Well, it's not cheap if you do it at the rate that folks are doing it.

But I shake my head because everyone shouldn't necessarily be a builder. Every department shouldn't have a group of builders out there. I was talking to a PMO, and she had a team of people that were working on things, and they were overwhelmingly busy.

And then someone quit the company. " I said, "Oh, are you in the market? Can I help you hire?

" I was like, okay. These people were overwhelmed with work. And yeah, there's probably a case where agents could attribute to the work that they were doing, so they were not overwhelmed.

But making that knee-jerk reaction to say, "I lost these two people, I'm just going to build agents to replace them," when the whole team was overwhelmed like that, I kind of shook my head. I'm like, I don't know if that's going to work. Well, let me ask you about that, because I have been having this conversation with folks, and among the folks who have adopted AI, almost to a person, they all say they're working harder than ever.

And so it doesn't seem like AI has made the task, or per se, it may have automated specific functions, but it doesn't seem like it's eliminating the job as much as it is, in some regards, making things a little more complex from a cognitive perspective because we're all doing more. Does that make sense? No, it does.

I actually wrote something about this. I remember sitting at a conference, and we were going through all the sessions. We were listening, we were taking all the feedback from these sessions, and I was in this interview, and I had people sitting in all these sessions.

" Everyone was using AI, summarizing that feedback. The amount of data that I got within an hour is completely overwhelming, right? And so I think what we're feeling with the amount of data, the amount of cognitive load that you can now just go get and share, it's incredible.

I haven't seen so many people build so many HTML update files in my life than I have this year. It's like, "Oh, hey, we want to do this. " Wow, it is so much data coming at you that you have to then ingest that into an LLM just to make sense and summarize things.

So it is a constant back and forth of massive amount of data that's easy to go get. And then, the amount of work that we have to do as humans to not let it just be complete AI slop across the board. You have to rein this in.

So to your point about that, we're all moving now towards these AI agents, and they are operating at machine speed and doing things that maybe are faster than we can wrap our heads around. And there will soon be hundreds, thousands of these things. So are we on the cusp of maybe reaching some point where it's just beyond our cognitive capability to manage because there's too many things doing far too many things simultaneously?

That feels like something that could possibly be there. I'm sure we will come up with something and a way to not let that happen. But Mike, if you look at the way things are going, we're kind of already there.

There's so much data and so many things that people can do. If I could read 3,000 pages of data a day, I could keep up with everything. But that's just not possible, right?

And so you have to, I keep going back to this, but you have to work on the things that matter, and you have to have systems and tools in place to be able to ingest this, give you the insights around the data that's coming at you or the work that's being done in your organization. And what are the recommendations against that? What should you put down?

What should you keep working on? There has to be a system out there that allows you to do that. That's the thing that we're working on here at Tempo.

All right. Folks, I think you get the point because at the end of the day, everybody who's a developer or software engineer is now a supervisor of a bunch of AI agents. And the challenge of being the boss is you actually have to know what your employees are doing.

And right now, most of us don't. Hey, Kevin, thanks for being on the show. Thanks, Mike.

I appreciate it. All right, and back to you guys in the studio.