# AI Automation, Hybrid Pricing, and Engineering Productivity Shifts

**Podcast:** alphalist.CTO Podcast - For CTOs and Technical Leaders
**Published:** 2026-07-02

## Transcript

Hello friends, this is the Alphalist podcast.
I am your host, Tobi.
The goal of the Alphalist podcast is to empower CTOs with the info and insight they need to make the best decisions for their company.
We do this by hosting top thought leaders and picking their brains for insights into technical leadership and tech trends.
If you believe in the power of accumulated knowledge to accelerate growth, make sure to subscribe to this podcast.
Plus, if you're an experienced CTO, you will love the discussion happening in our Slack space where over 600 CTOs are sharing insights or visit one of our events.
Just go to alphalist.com to apply.
Welcome to the Alphalist podcast.
I am your host, Tobi, and my guest today runs engineering at one of the biggest enterprise software companies on the planet.
Something like 85% of Fortune 500 are your customers.
$13 billion in revenue.
And he is the CDO of a company called ServiceNow.
And he is basically there from the very, very beginning, which is rare.
Like I think if you see like publicly listed companies, then very often the founder gets replaced by some more like, let's say, enterprise and stock ready CTO.
Welcome, Pat Casey.
Thank you.
It's a pleasure to be here.
So maybe we start very early.
even before your career, let's say.
Pat, what is your nerd path?
What was the earliest moment you thought, okay, computers are kind of magic?
Oh, it's a good question.
I actually got into it.
So I'm naturally an incredibly strong introvert.
I can fake it well at this point in my career, but I have been all my life.
And one of the awesome things about computers is you can play with them by yourself or do something by yourself.
So I actually got an Atari 400, which I think I got, remember that, right?
It had the little checklet keyboard, and storage was, you plugged a tape player into it, and it was such a low bandwidth record for storing bits there, but you could listen to it.
You could hear it.
It was kind of like birds chirping.
It's all analog, and it really couldn't do much.
But it was a computer, and I taught myself.
I think I had Atari BASIC at the time, and it wasn't super useful, but it got me interested.
And then I owned a PC Junior, and I used that almost exclusively to play computer games.
I was a huge player of a very, very early computer game called Wizardry, which I'm going to date myself.
The name continues, but the proving ground is the mad overlord.
That was me at age 12 or 13 banging away.
But in terms of how I felt like using it for something functional, I mean, I'm a relatively smart guy, but in school, I would get channeled into you know, the smart guy things.
But I never liked, call it abstract math.
I was an engineer tracked.
I wanted to be an engineer.
I always felt to myself, like, why am I solving this massive Fourier transform?
Like, why am I triple integrating this?
I can just model it.
So for me, that's actually, to me, it was easier to algorithmically model something and just solve it that way than it was to do the FFT or whatever.
And that got me conceptually into it.
But my first real job that someone paid me to do something with computers, I'm a failed graduate student, but during grad school, I just wanted a job too.
So I was working for a company called Aldis, who made Pagemaker back in the day, and they got bought by Adobe.
And I worked in the IT department at Aldis.
And I was a CD jockey or excuse me, like a floppy disk jockey, I would go to your desk and I would install software off floppy disks.
But I remember going to my boss and I said, you know what, like, we got like this huge company now, we just merged with Adobe, we don't even know who works here.
Like we need like a system to keep track of all the employees.
And she's like, yeah, that seems like a really useful thing.
I'm like, I think I can write that for us.
So I fired up Microsoft Access and I had no idea what I was doing, but I built.
the first, I don't know if it was the first, but the first I knew of employee tracking system at Adobe.
And then it's like, oh, we can do more with this.
We can track bills of stale with the lighting doc and we can track when things come in and we can put little labels on all the computers and keep track of that.
So I just got into it basically just because the job had needs that I felt like I could do.
Probably...
Not that dissimilar from a lot of, I guess you call it fairly bright, but young people.
When you're young, you don't realize the current state.
So you're just like, I can do this myself.
I just build it, right?
Yeah, yeah.
And in some ways, you're right.
So in this case, I was right.
So you basically introduced ITIL at Adobe in a very early stage.
It wasn't called ITIL at the time.
But yeah, inventory management and the tracking of stuff.
We take that for granted now because But it wasn't, you know, in the middle 90s, like keeping track of stuff.
You would lease computers from, you know, your like Dell or somebody and you'd lease a thousand.
I mean, the lease would come up and you have to give them back and you'd be missing 200.
It wasn't that unexpected.
And then you just, you paid the penalty clause.
But that was just the state of the art in some very high functioning companies at the time.
It just, it was an unsolved problem.
And then you basically, with Service Cloud from the start?
Was it your friend, the founder, Fred Laudy?
Yeah.
So I actually knew Fred in between my graduate school days and my ServiceNow days.
I worked at another company called Peregrine Systems, and Fred was the CTO there.
I lasted maybe two years, and then I left.
But Fred stayed a little bit longer.
But he lived in the same town I lived in.
So I remember I was actually, I had a convertible at the time and I was driving down the street.
Somebody walked in front of me.
I guess they were on a crosswalk, but anyway, I thought they were abrupt.
So I honked at them and I flipped them off.
And I'm like, wait a minute, that's Fred Letty.
I just flipped off Fred Letty.
So I'm like, Fred, Pat, you know, we're stopping traffic and we're chatting.
And he's like, I just started a company.
You should come by and see what I'm doing.
So it took like 30 days, but I eventually went by.
And he had a little office, I think it was like upstairs from a restaurant because like one of his buddies owned the restaurant.
And I remember he showed me at the time, it was a super, super early version of ServiceNow.
At the time it was called Glide.
And I sort of didn't get it because at the time, like the state-of-the-art enterprise software, there was this push toward, I'll call it sort of bite-perfect, full-fat configuration.
Like you would have a tool with like a forms designer and you'd like, you could do anything with it.
You could put the, you know, the button on the ceiling if you really wanted to.
And Fred's insight was, well, he had a couple, but one of them was that none of that mattered.
What you want to do is make it really easy to do the common stuff.
And the early version of Glided did make it really easy to do forms and lists and navigation, which is the common stuff in enterprise software.
And the other key thing, of course, Fred had was it was internet deployable.
It was all browser-based.
It was a SaaS product back when SaaS was new.
But I liked Fred, and I sort of was not living my best life sitting at home.
So I'm like, well, Fred, yeah, I'd be happy to work with you on this.
I love the opportunity.
And so I was the first person other than Fred to work on the code base.
And that was, I think, early 2005.
I'd have to double-check my dates, but north of 20 years ago.
Crazy.
And now you're basically as...
a super strong introvert, as you described yourself, leading a company with how many engineers?
Like 10,000?
Well, be careful.
I mean, Bill McDermott leads the company.
He's a CEO.
CTOs, different roles.
But actually, up until about a month ago, yeah, I ran all of engineering, which is about...
It's about 10,000 human beings, about 7,000 of whom wrote code or plausibly wrote code.
So if I looked at how many licenses of windsurfed did I buy, I bought about 7,000.
And obviously it's very different.
And I won't speak for all introverts of the world, but I'll speak for myself.
You put me in a crowd of peers in some weird environment I don't know, I feel very uncomfortable.
makes sense.
I don't know these people.
I don't know where I am.
It just feels alien.
Give me a role in that context and I feel totally at home.
I can be the photographer at the wedding.
I can be working the sidelines at an NFL game.
In the work context, when you're the CTO, you have a role everywhere you are.
So oddly enough, I think it's, for my personality, it's a lot psychologically easier to be a CTO.
than it is to be one of the people, just rank and file, for lack of a better word.
Just because in any environment I'm at, I'm there as the CTO.
If I'm meeting customers, I'm there to talk to the customers.
If I'm meeting employees and talk to the employees, hopefully keep morale up, listen to their concerns, you got a role.
And for me, that's super important.
And I guess that role also changed, like...
10 to 15 times dramatically throughout your time at ServiceNow?
Is that roughly?
Yeah, I mean, yes and no.
So I think at a high level, yeah.
When a company is really small, there are two job titles.
There's Engineer and there's Fred Lottie.
I mean, those are the two job titles.
And I was not Fred Lottie.
And you can kind of make it work about 20 20 engineers, we started having to divide the code base up a little bit.
It's like, all right, we can't all work on everything because the commits collide all the time and we're breaking each other's code.
And so that was a bit of a change in role from I'm doing everything to, okay, I got to have a little bit of a plan.
I'm working on the database right now.
Before that, we actually had an incredibly sophisticated system.
There was a stuffed fish someone had gotten at the carnival.
And if you were working on some of the, the guts of the code base, you put the fish on your monitor and people know, it's like, Jay's working on that.
So like he's got the fish.
And it just, it worked.
We, at some point, I think we thought we were going to get different totem animals for different parts of the code base, but we just, we didn't.
How often was that fish on your monitor?
Pretty frequently.
I was, I don't know, I can write UI, but it's not my passion.
So I tended to work more on the backend code and then the database layer processing.
I was the guy who would figure out the profiler and I rewrote the...
We have our own date parser.
The JVM has a very good, very robust date parser, but dates in our system have like...
only three possible formats, and the JVM's date parser threw off a lot of garbage, which mattered to us.
So I wrote in Java, but I wrote our own date parser, which produced less Java.
I was that low-level guy.
Not exclusively, but if there's something like that needed to get done, it was usually me.
So as other inflection point, you get to about 100 people, you get it broken down into teams.
But the ability to just kind of know what everyone's working on and see who's got the fish breaks down.
And then you start needing to put some process in place.
And perversely, my experience is you get less efficient.
So you get this sort of peak of productivity at like 100 engineers and like, all right, we're going to put some process in here.
And it slows you down.
And you get less efficient, probably until you get maybe 120, 130 engineers.
And then you kind of come up the other side of a trough and you're throwing.
volume of engineers at the problem, which offsets the overhead.
And then at some level that you can ramp that for a while.
There's various changes we had to make to our release process along the way, but the underlying structure of like, hey, you got teams of engineers, they're more or less seven, plus or minus, they work on a backlog, they check in.
That paradigm has largely been unchanged for 15 years, although it's definitely starting to change with the rise of AI coding.
The whole paradigm is breaking down.
Or evolving.
I'll use a different word.
Yeah, evolving.
Well, changing dramatically, I'd say from my perspective, but it really depends on the company and the problem.
But maybe, let's step back.
So you already told us that you...
you use Java.
So I guess you, do you have a Java monolith or is it all like microservices now?
Like did that dramatically change or?
Yeah, so the core ServiceNow product, I mean, the one that Fred Luddy wrote all those years ago and is sort of the core thing that we've been selling.
It's at some level, it's a metadata processing engine.
Like it doesn't do anything until you give it a ball of metadata.
And the metadata defines everything from what the screens look like to the navigation paradigm to the workflows to everybody's password and user ID.
It's all metadata.
The processing engine is all written in Java, just like you'd expect.
The metadata itself is usually stored in a database in rows and columns, but there's a lot of scripted metadata.
And the scripted metadata, like a workflow, you might have a business rule.
It's server-side JavaScript.
And we ran it and still do run it in a somewhat hacked version of the Apache Rhino engine.
I say somewhat hacked because we changed some behaviors of it and tightened up some of the security.
But if you look today, I mean, nobody writes apps like that.
It's very, I don't know, 2004.
So if you look at the newer stuff we're doing, it's all K8s-based.
In a lot of cases, it's daughtered to the main Java code.
At some point, the Java code wants to call some other service, and it just goes over to the K8s cluster, and the service over there does the job and comes back.
And there's an effort we're rolling to get more and more of the stuff out of the Java ball.
and into the world of KHD.
I can iterate it faster.
I can scale it better in some cases.
It's a very, I'm going to sound like an engineer, but I am.
It's a very cross-linked code base with a lot of subtle implied dependencies.
So it's a much harder job to tear it apart than you might think, like on paper, like anybody who's...
Anybody of any seniority is like, I know what to do.
We'll break this thing apart.
It's like, all right, if it was that easy, none of the world's big monolithic code bases would still exist.
A lot of cases, it's a process.
But we're making good progress.
And frankly, anything new we've written for the last probably four years, it's all Kubernetes.
And its languages, they're very, a lot of the AI stuff was Python, a lot of it's Node.
or big uses of Ruby.
I don't know why, but we just use it a lot.
As far as I know, we don't have any Rust lurking anywhere, even though it's the cool language right now.
Not yet.
Let's see, right?
And architecture-wise, you described Kubernetes and you have some database sitting there where we also dig down a bit later.
But you guys made this contrarian bet, let's say, that like...
for a very long time at least, you were mostly single tenant and every customer got their own dedicated instance.
Is that still the case or did that change?
It's still mostly correct.
So if you look at a ServiceNow instance, it's a cluster of JVMs talking to a database with a load balancer in front of it.
That's the stack.
It's not a one-to-one relationship between those software entities and hardware entities.
I share the willies out of the underlying hardware or virtual machines, depending on where we're running you.
But if you're AT&T or pick a big customer, you can go and I can point to the JVMs in the cluster which are servicing those requests, and I can point to the database, and there's a bunch of security so that those JVMs can only talk to that database, etc.
From an operational standpoint, some of the parts of this are wonderful because as long as you've got the database, you've got the customer.
I've got one thing to back up, I've got one thing to failover, I've got one thing to deploy, that is the universe.
It's also a scaling pinch point because no matter how big your database is, at some point you cap the ability of your ability to do work.
So that's the core architecture.
If you look at some of the newer services we're doing, like the AI services, that's a shared tenancy model.
So that's like I've got a cluster of, depending on where you're running, sometimes I use frontier models, sometimes I use internal models.
But if you're using internal models, I got a cluster of servers with running Triton, hooked up to GPUs, and I've got a little proxy service in front of it.
You make a call over to that, and we route your prompt over to the right model.
It returns.
but it's not a one-to-one relationship.
Similarly for things like the UI refactor I mentioned we were doing to get that out of the monolith.
Because there's nothing that needs to be persisted, right?
In most cases, yeah.
There will be...
Let's put it this way.
I've got enterprise customers who've got something between contractual expectations and just expectations that if they're running in a particular environment, that's where their data is.
It doesn't leak out somewhere else.
So the places where we have a good opportunity to change the tenancy model are usually where we stay in the same data center and it's not persisting any data.
When I want to bust up the data at rest, a lot of times I need to get people to sign a new piece of paper, which it can happen.
We do do it.
But that's one of the cases where I think enterprise, you have a constraint that probably isn't there in the consumer space.
In the consumer space, you just kind of...
You know, do what you think is right.
Hopefully what you think is right.
And that like leads to a crazy number of databases, right?
Like I heard that it's like roughly 90k databases, like 90,000 database or 85,000 or something like that.
It sounds about right.
And it's, you know, no human being ever looks at them.
They're all managed by automation.
I assume so.
Yeah, I mean, every now and then something goes wrong, a human being probably swoops in to try to figure out what went wrong.
But it's pretty rare.
And 25 billion queries an hour?
We probably gave you that number.
I would expect it to be a little higher than that.
I mean, the way ServiceNow works, any request you do, I mentioned it's a metadata processing engine, the metadata itself is in the database.
So if it wants to know Like you make a request to order a new laptop and it's got a workflow around like, what laptop do you get?
And are you authorized to do that?
And what vendor do I buy it from?
That's all metadata in service now.
And we like try to cache it, but you know, caches don't always hit.
So if I get a cache miss on stuff like that, it goes to the database to lead the metadata.
So even though you as a user may have thought like, hey, I saw a picture of a laptop and a button that said order and I clicked order.
Behind the scenes, we may issue 400 queries to try to figure out how to do that for you on your behalf.
So there's a big amplification between the number of screens we render and the number of database operations we do.
And most of them are incredibly highly optimized, selects by primary key, but it's a lot.
I mean, the numbers go up and to the right.
It's also why we...
I mean, we bought a database company.
So we used to be a MySQL company with Big InnoDB.
We transitioned to MariaDB because we had a relationship with them.
And then ultimately, there were challenges scaling it for our workload.
And you sat on the board of MariaDB as far as I saw it, right?
I did.
You worked with Monty.
I was there.
Yeah?
Okay.
It was Monty, and I'm actually blanking on the CEO at the time.
It was not Monty.
But Monty was CTO there.
And he was still, he knows that code base better than anybody.
Yeah, he wrote a lot of it.
But he was also, I don't know this way to put it.
His heart of heart was in like, hey, he wants to have everyone in the world succeed and love the MySQL code base, the MariaDB code base.
And MariaDB, the corporate entity.
was trying to build itself into a more full-featured, hey, we're a data repository company.
We've got a variety of engines, and we've got a bunch of tools.
You come to us with your data problems, we'll give you a solution.
So they wanted to be like a MongoDB or something, but obviously SQL-based.
Whereas Monty, I think in his heart of heart, he's like, that's interesting, and it may be great for the company, but I want to work on the MySQL code base, because this is where my love is.
And I think these days, what he's working on there, it's more supporting the traditional MySQL InnoDB code base there.
And I think I talked to him maybe nine months ago.
He seems actually pretty happy with the role he's in right now.
Okay, cool.
And then you built your own system or you acquired a company that was like the inception of RaptorDB, which is your database?
Yeah, so we bought a company called Swarm64.
It was actually a German company.
And what they had built was a column store on top of Postgres.
But the problem they had solved, which I thought was a hard problem, was that their column store was always in sync with the underlying Btree-based database.
And so they would transparently in the query optimizer be like, oh.
That query can be efficiently handled via the columnar indexes.
I'm just going to delegate there.
Whereas this other query, columnar can't solve it.
We're going to go to the regular B-tree indexes.
But it was all transparent, like just below the SQL layer.
So you as an application developer just fired SQL at it, and you're just like, man, these reports got a lot faster.
This is amazing.
But it was, I don't know, it's like a...
15 person German team and nothing with the Germans, but like 15 human beings can't usually take a database all the way to enterprise scale.
And it was optimized for like whatever they thought the workload was.
So when we bought them, we're like, hey, we love you guys.
We're gonna give you some more resources.
But your workload target is now the ServiceNow workload.
I want you to make this the best possible database for the workload that's shaped like our workload.
And so my knowledge, like every one of those core engineers is still with us.
They're an excellent team.
But the team got bigger and the workload shifted.
But about two years later, we started rolling out to our customers under the brand name of RaptorDB.
And that was actually named by Bill McDermott, which is, he didn't actually, if you look, there's like a picture of an eagle we use, like it's a Raptor.
But to this day, I'm not sure if when Bill named it, he was thinking of that kind of raptor or like the Velociraptors from like one of those movies where the dinosaurs kill everyone.
But we went with the eagle.
It felt better for marketing than a Velociraptor.
And so a database became like a marketing thing?
Was that because your system was too slow?
And is it ultimately then something that you upsell to customers?
Or like, how does it work?
So there's two flavors of raptor.
There's Raptor Standard and Raptor Pro.
They're both quite a bit faster than MariaDB was, largely because they use modern high-core count computers better.
There are just some...
InnoDB was written back when most computers had one core.
So if you look at its core memory structures and architectures, it just doesn't work well when you get, I don't know, maybe 20 cores north of that.
It just spends all its time spin-locking.
It may be like some smart guy like Monty is going to figure out how to work around that.
But like in the time I was on the board, we couldn't solve it.
But very few workloads need that.
However, ServiceNow is one of those workloads, which needs that.
So what Raptor Standard does is it gets you, it's based on Postgres, that architecture just handles high core counts better.
And it just, it does save you some storage, but that doesn't matter to the customers.
And then that's, everybody gets it.
I think I'm like 97% of the way through converting my 90,000 databases over to Raptor standard.
It's got some small number of MySQL still on there, ReaDBs.
Raptor Pro, you do pay for.
That adds the column store.
And that adds a few other features which are relevant if you're like really big and care a lot about your reporting performance.
And I think Bill has a...
because he did something similar to SAP, right?
You could pay for HANA.
So I think in his mind, that was, of course you should pay for it.
Let's say SAP playbook.
Yeah.
But like I said, like everybody gets standard and their standard is you don't pay for it.
You just get upgraded and you run better.
Okay.
Okay.
And did you ever, I mean, you're in a way.
running than Postgres?
How big is the difference between your own proprietary set or your own proprietary technology and core Postgres?
Is that huge?
Or is it feature level then where you need something different?
I mean, some level we're a downstream fork of Postgres, so we can still pull the upstream patches.
There's a lot of additive code because we've got the whole column store, which is all our code.
And then I could get the database architect to walk me through it.
There are parts of the Postgres code base, like the optimizer, where we had to come in pretty aggressively and make changes.
But we generally are pretty good at keeping up with the downstream pulls.
And we do contribute some stuff upstream too.
So if you look, I mean, we're not like a top five contributor to Postgres, but we do.
And the other place actually where you might surprise you were decent sized contributors to OpenJDK because we run OpenJDK internally and we optimize it and fix it and tweak it.
And, you know, I've got a team of very smart engineers who worry about stuff like, you know, the use of permjet or shared space or all that fun stuff.
Okay.
Okay.
Yeah, cool.
And did you ever think about like, also releasing that, like your fork basically as open source or?
Releasing, excuse me, the Raptor.
The Raptor add-on basically.
I actually don't know.
Like it's been tossed around internally.
I don't know anyone got too serious about it.
But like I don't have, like we're pushing some of the code upstream.
So it's not like we're hiding the code.
The stuff that we might be concerned about open source, frankly, is the column store, because we do feel like that's our IP.
But the OpenJDK stuff is literally OpenJDK.
So we push everything upstream.
Usually these days, the committers take our stuff, but every now and then we're getting the usual open source.
Like, hey, it's a good patch.
No, it's not.
It's just the way the world works.
Can you imagine?
Then slowly coming to the AI topic, which I think, keeps us busy and productive and hyped these days, right?
Everyone has a different opinion and that's kind of always interesting to hear, to sync up on those.
So I think in an interview that I saw in 2024, you basically made a big investment into Windsurf licenses for all your engineers.
And you said that this brought you like 10 to 20% productivity.
back in the days, not absolutely game-changing from where you were before Copilot.
How did that evolve from there?
How hyped are you yourself?
Do you run any cloud on your own computer right now?
How does it look like for you yourself?
How did that evolve?
I feel like we're on the third generation of coding tools.
You know, first generation was, I call it like the early GitHub copilot.
It's like slash slash, give me a function that tells me numbers prime and it'll spit out a function for you.
And I think they were a little labor saving, but it was like just a better version of like auto commit or auto complete.
Second generation, yeah, we like big investors in Winsurf.
I don't mean that like we did not buy any stock, but like we bought a lot of their product.
I bought about 7,000 licenses.
We trained 7,000 engineers on how to use it.
And we could demonstrate we got about 15% of a productivity bump out of that.
Just measured as stories per engineer per sprint.
It varies a little by sprint, but round number is 15.
And that's consistent, frankly, with what I see when I talk to other at-scale companies.
So they're big tech companies, big consumer products companies who've got a lot of engineers.
What you see, though, is it's not that everybody got 15% faster.
You got a lot of people who, frankly, didn't change very much, and then you've got a small subset of people who really just clicked with them, and their code productivity goes up 5x or 6x.
And there's also another tool we added to the toolbox.
About nine months ago, we also added a quad code to people's toolbox and said, hey, look, if Windsurf makes sense, use Windsurf.clawedcode.
And what we see is for the people who are still doing sort of, I'll call it code-centric, IDE-based development, like where you're looking at the code and you're thinking in the code, it's going to be Windsurf 90% of the time.
But if you shift to sort of that new, I hate to use the word vibe coding because it's so overused, but I'll call it output-centric.
model where you're prompting and then looking at the output and then prompting again, that is usually done right now with cloud code inside of ServiceNow.
Although we're actually looking at other options just because I like Anthropic.
It's a good tool, but we should look at other stuff too.
And it's usually CLI based.
And there's a super strong Pareto chart on engineers in that some of them seem to click with the AI.
coding paradigm and you get this, you know, some people see 10x.
I haven't necessarily seen 10x, but you can see 5x lines of code written.
Maybe someone is at 10.
I haven't pulled the data, but they click and they're just off to the races.
And a lot of people just don't click.
Um, and there's a point of view in the industry, which says like, it's just resistance.
Like people, everybody could click if they just got past their fear of changing paradigms.
Um, I'm less sure of that, to be honest, because at least for me, it's a different way of thinking.
And the best analogy I have, it's an imperfect analogy, is if you're good at chess, you usually learn to play person to person.
You've got to hold one chess board in your head.
You figure out what your opponent is.
You're playing the person.
But there's a subset of chess players who are really good at playing five boards at once.
And it's not always the people who are best at, you know, across the board, although probably there's a lot of overlap, but it's not always.
AI coding, if you get to that next level, is like playing five boards of chess.
Because you got multiple prompts spinning at the same time, they're interrupting you when they finish, and then you've got to react to them.
It's very different from the traditional coding paradigm where you're in the code.
I mean...
Traditional coding, it's almost like an autist paradise because it's incredibly focused.
You're holding the whole code base in your head while you need to put a tiny little bit.
That's why the traditional, to a non-engineer, you don't ever understand why an engineer gets so upset when you interrupt them.
Hey, I got a quick one for you.
Do you want a cup of coffee?
Oh, you just blew up an hour's worth of my work because the whole lattice of logic collapsed in your head.
So I do think fear, expect, I don't think everyone who was good at the old paradigm will be good at the new paradigm.
And I think there will be some people who were just not successful at the old paradigm or who hated it or who didn't click with them who do click with the new paradigm.
So I think it's going to reshuffle the deck of who is a top productive product person.
And it's not always going to be me.
It could be someone else.
Yeah, it's potentially more product-driven people, right?
Like if you have to turn from someone who receives instructions or requests to someone who is actually formulating them, then it's like a natural pivot to becoming more product-driven potentially, right?
And really thinking about a customer problem.
And I think that's not what every engineer loved back in the days, right?
I think that's true.
I think like we have still found, because I'm, like I said, I got 7,000 engineers and a lot of them are transitioning to these new, the most efficient model is if you get an engineer who clicks with the new coding paradigm and has good product taste.
They are just off to the races.
A lot of times you get someone who's a good engineer and clicks with the new product coding model, but does not have good product taste.
In that case, I've got to kind of marry you up with a designer or a product manager and you work in like a little group.
But the old model where you'd have like, where engineering was the scarce resource, so you needed like seven engineers to keep a designer busy or seven engineers to keep a product manager busy is more like one-to-one.
And like I said, in a lot of cases, if you've got the right engineer who's got that product taste, you don't need the other two.
Or frankly, if you've got a really good product manager who clicks with the Vibe coding, like, why do you need an engineer?
Like, just cloud code and knock your socks off.
A perverse example of that I'll give, which is imperfect, but it's personal for me, is my daughter.
Very smart lady.
Mechanical engineer.
Does not like coding.
It irritates her.
Loves products, though.
And that's why she probably mechanical engineering as opposed to double E.
But she had some summer project last summer where she was supposed to build the UI for some trading software with some bank that I was interning at.
And she called me up and she's like, I don't know.
She's complaining.
I'm like, what should I do?
I'm like, well, you've got to be taking their money.
You've got to give them what they're paying you for.
She's like, I get that, but what should I do?
I'm like, well.
here's Codex, here's Cloud Code, here's some YouTube videos on how to do it.
You're a smart lady, you'll figure it out.
And a week later, she's like, this is the best thing since sliced bread.
All I do is I tell her what I want, and it builds it.
It took the annoying part of the process away from her, but left her with the part that was validating for her.
She always liked building products.
So I do think there's going to be...
I think we're shifting as to who's going to be successful and it's not always going to be the same cast of characters we had five years ago.
Back to your company and Agentic, what's your take on agents?
And agents not in terms of engineering agents like Cloud Code, but agents for the rest of us.
I mean, you're basically dealing with IT service management, right?
And many large organizations.
So is there like, how many agent, like real agentic use cases are there for you?
And how much of this is, like in the real world out there, how much of this is true?
What other companies are telling us and how much of this is still like happening down the road and how do you see it will be?
Yeah, I think, Similar to the coding agents, I feel like we're, that's generations of how people are applying AI in the enterprise software space.
In the first generation, I don't want to say it's uninspiring, but it's a little uninspiring.
Like, I'm going to summarize an email for you, or like you're working a case and Bob just handed it off to you.
Like, I will quickly summarize all the work Bob did so you don't have to scan through the case history.
Yeah, it'll save you five minutes there, 10 minutes there.
It's real.
It's real savings.
It'll make you more productive, but it's not going to change your life.
And then you saw maybe 18 months ago, there was a push towards like agentic frameworks.
And it was a little field of dreamy in my experience because we would go to the customer and like, hey, we've got this great agentic framework.
It's got an identity.
You give it some tools.
You give it a goal.
It'll try to apply, it's given its identity and its goal and these tools will try and work a problem for you.
But the customers are always like, well, what specific problem will it solve for me?
And we're like, well, let's sit down together, let's have a cup of coffee, let's brainstorm on this.
And you sort of get into like, by default, you're almost in an FTE model, not almost, you are an FTE model where every customer is bespoke.
And the thing you're selling, for lack of a better word, is the ability to write agentic workflows.
Again, valuable.
It helps people, customers go live with production, get value out of it.
Where we're at least in terms of the last generation, the third generation is I don't want to sell you a toolkit anymore.
I don't think you want to buy one.
I want to sell you an outcome.
So the current ServiceNow paradigm, and again, it's more of an IT case management, but I will go to a customer and I'll say, hey, you know, Acme Incorporated, you did 2 million cases last year.
I think I can have automation do 10% of those.
And it'll follow the same rules.
It'll use the exact same tools.
It's an anthropomorphic paradigm.
You literally go to the user table, create a user called AI Pat.
And if you want AI Pat to work a case, you assign it to AI Pat.
And like it follows everything you've already done.
And there is last mile work on that paradigm.
It's nowhere, no one has solved it where you literally just go in and flip a switch and 10% automation or 15% automation works.
But it's way easier than going in with an agentic toolkit and trying to do that same thing.
Because we've done all the plumbing, there's a bunch of tools already there, it knows how to look into your knowledge.
And that's sort of where we think the puck is at on enterprise software.
It's like, hey, I want to take a whole task, which is burning a human being.
I made the whole task.
And I want to follow the same rules that humans follow when they do it.
Because frankly, you should not trust an LLM more than you trust a human being.
And modern business processes were designed on the assumption that human beings are a little bit untrustworthy.
Just follow the same rules that humans do.
Like have an approver.
Like have a manager who looks over the work.
Have a spending limit on an agent which is supposed to spend money.
So if you do all those things, I do feel like that's a much, much faster path to value for customers.
And that's also a server of the puck is going more generally.
It's out of a toolkit era and into the sort of outcome era.
Like we wanted to solve problems for our customers.
Understood.
And to what degree is that rolled out?
I mean, I guess you come from a SaaS, like traditional SaaS model, right?
Where you basically charge per seat or?
Oh, so specifically for that one, we do charge for seats.
We're a hybrid pricing model.
You charge for seats.
But if you roll out the AI stuff, most of the AI stuff we charge per consumption.
So from my point of view, let's say I've sold you 1,000 seats in your working cases, and you roll out the AI, and you're like, this is awesome.
I only need 900 people to do that.
I'm going to have the extra people, I don't know, do something else for me.
The consumption side for the AI should at least offset the seats that you're not buying.
Like that's the way the pricing model is constructed.
And from your point of view, you should get better value out of it as well.
But that's sort of the calculus.
Well, I'd say that there's two schools of thought in the enterprise software space.
There's one school of thought which says, I'm going to dig in and try to defend my traditional seat-based licensing model by hook or by crook.
make it really hard to orchestrate my stuff.
Some people are there.
That's not where we're at.
We sort of feel like this is an automation revolution.
Like the whole point of AI is to automate work and we're a work automation platform.
So whether it gets automated with human mediated or not human mediated, we want to make it easy for our customers, which is why you've got the hybrid pricing.
When people are involved, I got proceeds.
When AI is involved, it's consumption.
And that balance is going to be up to every customer.
It's going to be customer-specific, and they're going to determine for themselves what the right model is for them.
Does that make sense?
Yeah, it absolutely makes sense.
Just reflecting about it, in a few years from now, maybe a to-do list tool that I will have on my Mac will contain a Kanban board where I can assign stuff to either my wife privately or...
An agent, right?
And then an agent will review it.
Or how do you see the future there?
I think your marriage must be different from mine.
I think my experience is my wife can assign stuff for me.
Right, right, right.
I do think that's sort of where the puck is going.
I think the consumer space, there is some attempts to bring this anthropomorphic model in pretty strongly.
I think the consumer space is sort of also dominated right now by I'll call them interactive paradigms.
It's like, I'm going to chat with you, which makes sense.
Like, that's the obvious way to interact with AI.
The enterprise space, there are a lot of non-interactive workflows, or the interaction's super limited.
Like, hey, I'm working in a car factory and we're low on steel.
I need new steel.
There's a huge purchasing system, which...
creaks into life behind the scenes and it finds the right vendor and the right steal and the delivery time and works with the railroad to get it in there.
You're just that person at the factory center running low on steal.
That purchasing system on the back end, it's not chat-based.
It might have some chats in there.
That's the sort of orchestration stuff that enterprises are like, maybe I can orchestrate that whole process.
I can have an AI purchasing agent and it'll...
buy from the best vendor and some human being will approve it and then it'll just show up.
So that's a place where I think the fulfillment side is a more relevant piece in enterprise, whereas the consumer side is more focused on the initiation and the feedback loop.
Like I asked for a new car, when's my car going to show up?
Can I track it through the, maybe it's interesting to me to track it through the production chain and see where it is along the way.
And then back to your business model, or I mean that was about your business model, but what do you think about valuations then changing and the market being quite scared off by companies like Antrofic?
I think this year you lost 40% of your value roughly.
And I think you're long in the game, right?
like have similar, have had similar moments in your career already.
And then, I don't know, on February 3rd and traffic ships at $20 clawed plug-in and Salesforce and you both dropped by 7% in a single day.
Is that just nonsense or are you seriously?
Are you like how, I don't know, afraid is the wrong word, but how do you see that?
How do you see that evolving also when you look at the real value that comes back from that?
And also you described the value, right?
You have like agents that really physically do things.
How does that relate to that, to your model?
And how do you see the future of SaaS?
Also me being like super deep in SaaS, like how does our future look like?
Yeah.
Well, I think in addition to my other good deeds, I'm obviously a pretty major shareholder in service now.
So personally, the stock goes up and to the right.
So you personally feel it when it goes down.
But I mean, the underlying market, I'll be honest, the market doesn't know what to make of it right now.
There's a hypothesis, and you articulated it pretty well, which says, hey, you know, the fundamental seat-based SaaS model, it's being rendered obsolete by AI.
There's a strong version of Apothesis which says the underlying data repository and the workflows, it's all irrelevant.
You're just going to vibe code SAP in a weekend and it'll track your GL and your purchase orders and do all that fun stuff.
And there's a soft version which says, hey, that still has value, but the front-end abstraction, that interaction with the end users, will take away from people.
or orchestrate it externally.
So we'll have little barnacles on the battleship of the code base steering the ship for you.
I think they're both extremely overblown.
And I also think that the piece people miss is if you accept the premise, and I actually do, and we're just talking about it, that the future of enterprise software is less and less human-mediated and more and more technology-mediated.
It's more and more about automation doing the jobs.
Who do you think has the best inside pole position track to provide that automation?
It's the people who currently own the systems.
That's the people like the Service Nows.
It's the Workdays.
It's the SAPs.
Will we all succeed?
No.
I guarantee you some of us will turf it.
But from my point of view, if you look at things like our anthropomorphic, our autonomous worker paradigm, We can do that because we are the system that orchestrates the workers.
That is very hard or in some cases impossible for a third party to do.
And so that is the fundamental advantage that the current owners of these systems have that I feel like the market is somewhere between undervaluing and misunderstanding.
But what I always, I told this to couple people at our financial analyst day and it's not secret everything financial analyst day is public um but it's like hey i can say this to you and you can nod along or you can not but say you agree with me oh yeah it makes perfect sense like the proof point is when it shows up in our numbers um and fundamentally like that's the currency of trust when you're going through one of these paradigm shifts is like it's it's nice to be able to have a coherent narrative and to believe something But to want to convince a third party, you've got to have the revenue.
You've got to have the customers.
And at least for service now, I mean, I would point to our numbers.
This is the thing that frustrates Bill.
We've been having great quarters.
See what the next one looks like, but we've published them all.
And so I think if you look at our investor relations people or Bill, they're like, man, this is overblown.
But like the way to get out of that bucket is partly by...
talking like this, but it's also partly going to come down to we can have a couple of blowout corners and point to them and be like, hey, you should pay more attention to us now.
So that's one of our goals.
We want to have awesome technology, but we got to bring it to customers too.
So like an uber positive, you could basically say that AI is a huge chance for you because you own the system of record to basically offer service as an add-on to many, many customers really used to your software and your orchestration already, right?
Like it is in a way like a massive upsell that where like, like I would say like it's maybe worth more than the database that you've built, right?
Is the immediate way to offer this as a service to so many customers.
I think that's absolutely right.
I think at a high enough level of abstraction, I mean, we're a workflow automation company.
We help you automate work.
And traditionally, we did that with the assumption being we would make it more efficient for human beings to work a process through an enterprise.
We would track things for them.
We do the handoffs.
We do the assignments.
AI gives us a new tool.
We are able to automate some stuff we couldn't beforehand, or we can automate stuff much more efficiently.
And that means that we can give our customers, we are even more valuable to our customers.
And that does, I think, give us the inside track on this.
And there's a soft piece too, which is subtle.
We know this space, we understand enterprise workflows.
And we just fundamentally know what purchasing workflow works like or an IT workflow or a customer service workflow, which I think does give us some domain expertise, which is not always present in some others.
Okay.
Okay.
Then let's pivot a bit back to nerdier stuff, even though everything is AI these days, right?
If you think about the core value of software and maybe some things pivoting more towards services that you offer in addition, the software development lifecycle is also fundamentally changing.
And how do you see this?
I mean, we basically move from the bottleneck on the engineers to like a bottleneck on product to like potentially even a bottleneck on your customers, right?
Like, I mean, product life cycles or product work is a lot like also validation work with the customers and product discovery, right?
Like, hey, client XYZ, I want to show you something.
I made this great tool.
And I myself, I observe on my own behavior that I'm slightly tired by new software hitting me every day.
Like there's so much new software popping out of the blue right now.
How do you see that changing?
Like is there a natural slowdown or a natural bottleneck in this process, which now like moved from engineering to not only product, which many people say, but the customer?
And are we slowed down by the pace of our customers?
So is that maybe like a natural break for the whole market?
It's a really good question.
And I'll actually throw a third one that we didn't even mention, but it's real too, at least in the enterprise space.
Like I can iterate super fast and the customers have got their own rate of willingness to change.
In the middle, you've got like the go-to-market and the field and the services organization who are talking to the customer's interface they got to get.
the maximum rate at which I can push chains through there as well.
My instinct is that, yeah, over time, we will slow down.
Because you saw this in early SaaS as well.
Like early days of service now, I literally did nightly pushes to the customer base.
And then we went to weekly, and then we went to monthly, and then we went to seasonal.
And it's...
It's a combination of two things.
It's like, one, the customers are like, hey, I've got more and more mission-critical workloads on you.
I can't afford to have it just change behaviors.
Even if nine out of 10 times it got better, the one out of 10 times that I as a customer thought it was worse, that's a problem.
And the second thing is the products just got a better fit.
There was less of a need to chase the feature set and the design.
So those two things kind of converge at some point and you get a slowing down of the iteration rate.
What we in ServiceNow are trying to do is I want to be able to iterate the underlying engines as rapidly as I possibly can.
Because I feel like, hey, look, if you're assigning cases to AI Pat and he's supposed to work them, and right now he can do 12% of the cases, if he just does 15% of the cases, that's just better.
You don't have to change anything.
It just makes you happy.
If AI Pat's behavior changes, though, periodically he's going to, I don't know.
start asking AI Mary to assist and the cases flow back and forth and that changes your process, I feel like you need to have some amount of control as to when AI Mary joins your team.
So when it's a service improvement without changing the flow, that is a case where I think the modern paradigm is just you want to go as fast as you possibly can.
When we're forcing change on the users in the enterprise space, Everybody's a little afraid of being like Snapchat and you roll out the new UI and everybody's like, I don't like it.
So in the enterprise space, there's more of a, customers need to have control of functionality changes that impact their end users.
But even with that control in place, I used to release code twice a year.
Now it's like...
customers are getting pinged probably weekly or certainly monthly.
It's like, hey, there's a new version.
Would you like to turn it on?
Yeah, and customers will start ignoring that, like always, on green light.
I got some of them are like, hey, stop nagging me, 100%.
I've got others too, even some really big corporate entities.
So you think, man, you're going to be really conservative, who are like, no, no, no.
All the things that I was hoping for are now here, right?
Yeah.
It's like, hey, that new thing, that thing I was really waiting for is here.
Let's go.
Cool.
So it's, yeah, the, what we're looking for here.
I won't say software was ever a boring industry, but it was predictable for maybe 10 years here.
It is less predictable now.
We are living through a technology, a generational shift on technology, and it's reshuffling the deck on like what companies are going to succeed, what paradigms succeed.
And it's re-softening deck on the customer side too.
Like they're not sure how they're supposed to behave as a consumer.
And so they're feeling their way, same as the rest of us.
And some of them want to go faster.
Some of them want to go slower.
Some of them are afraid.
Some of them are super enthusiastic.
And it'll probably stake out, you know, give it.
few more years, but right now it's a transitional era for sure.
Let's give it until we add robots, right?
Let's see how that changes things.
That's a whole other space.
There are 100% people, as you know this, who are doing physical AI.
Slightly different LLMs to physical world tasks.
That's going to be crazy.
So I only have two questions left for you as time is short.
One, and that's like beginning of the outro.
So for the CTOs listening, most of them are running like slightly smaller shops than yours.
What would you tell them about wiring agents into their real systems this year?
what to do and what to stop wasting time on.
Yeah.
So I guess I give two different pieces of advice.
You know, one, there's an aphorism.
I think that like everyone is conservative about the thing they know best.
And like the thing I know best is engineering.
Like if you're a CTO, the thing you probably know best is also engineering.
This is really not a time to be overly conservative.
The new tools are out there.
They will absolutely help your team be more productive.
You can get more product out to your customers faster by leaning into it.
And the flip side of that is, unless you're an incredibly rare nook of the software industry, the best way you can make your customers more productive and give them more value is in making your product smarter.
And there's a whole raft of things that you can do now that you couldn't do three years ago.
So if you're not using AI to make your own internal teams more productive, you're behind the curve.
And my advice would be, it's not too late.
Now's the time.
Lean in, catch up.
Talk to your peers, because some people are there, some people aren't.
And the second thing is, if you're not applying that AI to the products you sell and doing so in an intelligent way, you're going to get lapped by some other company that is doing so.
So that AI imperative is 100% real.
It's on the internal and the customer-facing side of it.
And I guarantee some of us will turf it.
We'll put some bad AI in our product, which is annoying or terrible.
But the flip side of that is not making that investment.
It's just turfing it in a different way.
Because two years from now, somebody else will have figured it out.
So this is not a time for excessive caution.
It's not a time to completely go bonkers and do crazy stuff, but this is a time really to lean into the new technology.
The FOMO is real, yeah.
So thanks a lot, Pat.
I still have a list of prizes for you.
So someone on your team told me about a hidden Easter egg in the Now platform, your workflow engine.
If you open an incident that doesn't exist and hit...
say three times, then there's a little feature that makes you scroll back in the timeline and you can stop it in the year you want to stop in and assign a name, which we now assign your name.
And we travel back to the Fred Ladi days and you said like 2005, right?
Roughly.
Before ServiceNow was really ServiceNow.
And yeah, you got to watch your younger self now for a bit, like coding, like building your own, like date functions in Java, right?
Like the good old days.
And you now have the chance to whisper something into young Pat's ears.
What would it be?
Oh man, I'll give, on the technology front, I think we actually made a lot of really good decisions on the tech stack we did.
But I would whisper in my old ears, like, hey, that UI rendering layer you're using, like that jelly XML templating language that's on the top of Apache, it's not going to stay there very long.
Like, you should maybe look at a different UI templating language.
We're like on the third generation since then, but it's still there, like buried in the guts of the system.
But no longer XML-based, or I hope?
Well, there is actually still...
We're on a third generation of UI rendering.
The first generation is still rendering some of your stuff, and it is absolutely, it's tag-based XML transformation.
It's not JSON.
I think on the, I would also say, the second piece I'd say would be enjoy it.
It was incredibly hard work.
And I remember being incredibly stressed because I had this huge pride of ownership and like I wanted every customer to succeed and everything I checked in to be perfect and every customer to run well.
But I think I never really came up for error and said like the positives of that environment, like the closeness I felt with the team, the validation I got for like customer has a question and I...
go back to my hotel room and I work all night and I check it in and it shows up in the build the next morning.
I show up the next morning and I show it to them and they're like, that's amazing.
That's what I wanted.
Like those are rare in life.
And I think just the advice would be to enjoy that.
And the third one, a little more personally, I would probably tell myself, Hey, you're getting all this amazing validation out of work and that's great.
But don't forget to spend some time with your family.
like you're when the rare times you're not working the temptation maybe to retreat to your room and go to introvert cave and you know veg out but like your family wants you or needs you whatever the right word is but like and you need them um so factor that into the way you're spending your time as well and spend more time there and make it more valuable time when you spend it thanks a lot pat really great having you on the podcast uh really like a lot of like helpful advice and yeah, like also I have way better understanding of service now and what it is and how it functions internally.
Thanks a lot.
Hope to see you soon, maybe in real life at a certain point.
You're in Santa Clara, right?
I'm San Diego, but reciprocally it's a pleasure.
I appreciate the interview and yeah, happy to chat in every time if it comes up.
Thanks a lot.
Have a great day.
Bye.
Thank you.
You as well.
Thank you for listening to the Alphalist podcast.
If you liked this episode, share it with friends.
I'm sure they love it too.
Make sure to subscribe so you can hear deep insights into technical leadership and technology trends as they become available.
Also, please tell us if there is a topic you would like to hear more about or a technical leader whose brain you would like us to pick.
Alphalist is all about helping CTOs getting access to the insights they need to make the best decisions for their company.
Please send us suggestions to cto at alphalist.com.
Send me a message on LinkedIn or Twitter.
After all, the more knowledge we bring to CTOs, the more growth we see in tech.
Or, as we say on Alphalist, accumulated knowledge to accelerate growth.
See you in the next episode.