# Rippling CTO: The Human Data Layer for AI Agents

**Podcast:** Dev Interrupted
**Published:** 2026-07-21

## Transcript

Welcome back to Dev Interrupted, brought to you by Linear B.
Quick note before we start, my guest today is Albert Strasheim, the CTO of Rippling.
And the idea that stuck with me most from our conversation was this, that once you understand the real shape of your org, who reports to whom, who has access to what, you can build almost everything on top of it better.
Albert calls that the hook into the organization, and it's what makes agents useful.
And that's a big part of why Linear B sponsors the show, because the same thing is true of your engineering team.
The honest picture of how your team works lives downstream and how code gets reviewed, tested, and shipped across your developers and AI agents alike.
If you can see it, you can improve it.
So measuring AI's real impact, governing it as it writes more of your code, and finding where delivery slows down are all things that Albert and I brush upon in this conversation.
All right, here's my conversation with Albert.
You know, on this show, we've spent a lot of time talking about how fragmented the tech stack is becoming in an increasingly agentic world, how companies are struggling to understand the power of the data that they're already sitting on top of.
And more increasingly than not, we keep dividing into newer and newer silos, reinventing the same processes over and over again, and ultimately spinning our wheels, unaware of all of the efforts others are doing.
Right now in the market, at the same time, there's a lot of people building for workers that don't exist.
You know, we're building tools for AI agents and ephemeral automation, the non-human seat in the org chart, so to speak.
But Rippling is leaning the other direction.
They're doubling down on the human layer, the idea of unifying the technology that makes HR, IT, and finance possible into something that's closer to like...
an employee graph.
And that bet is what powers all of their agentic work and the work of their consumers.
And an agent that knows who reports to whom and who has access to what and can more accurately understand the shape of your organization comes in with so much more context and a better ability to deliver the work that you need every day.
So today we're talking about building that human-centric foundation that'll become the jet fuel for the agents of tomorrow and what it means to lead an engineering org through that kind of challenge.
So Albert, it's great to have you here today.
Thank you for having me.
That was honestly a great sales pitch for what we're trying to assemble here.
Amazing.
Well, I'm glad I set it up well.
kind of curious to learn more because, you know, there's a lot of big words about breaking down these silos and unifying these parts of operating a company that traditionally had very different tool stacks.
So, you know, you've been leading the engineering org at Rippling through a time of massive scale.
Like, what are some of the things that you're seeing right now, the biggest insights you've gained about building in this environment, and what has ultimately led you to innovate on this new kind of AI platform?
I mean, I think First Insights has, and some of this for us is also pre-AI, but I almost feel like AI is making it easier now.
is you really need a maximally ambitious vision.
I give Parker a lot of credit, our CEO a lot of credit for this.
I think he was maybe the first vision maximalist as he conceived of this compound startup idea, trying to build so much business software across the entire company stack.
But I think you really have to start from that.
And then I think once the vision is there, you can ask yourself, how do you do this?
And then a lot of the pieces begin to fall in place.
I think the, you know, how do you do this, you know, is going to lead you more often than not to some kind of platform play or, you know, the answer is going to be start with, you know, a fundamental set of platform building blocks.
And I think something the early Rippling team did and, you know, something we're obviously trying to carry forward now is significant investment in those platform building blocks.
And I think that's really...
been important to our success up to this point, but I think it's also really important for any company trying to build in the AI era now is You need a big vision and then you need a big platform to do all of the things, and probably not just in one product area, but in a number of adjacent products areas.
And it is then really incredible just the kind of use cases that fall out of that, the solutions that fall out of that, and the happy customers that come from building in this wide-ranging way.
And I think it...
challenges some of the conventional wisdom around, you know, focus, just do one thing.
I think we're seeing the end of that era, at least for a while.
And the kind of like go broad, go fast, go big era is here right now.
Yeah.
And I'm curious too about the bets that y'all are making in that world.
at first blush, when people would look at Rippling and understand the data shape that it has and the world in which it lives, maybe there's a lack of thought or innovation or modularity in interacting with that layer.
So traditionally, it's something that I think maybe a lot of developers, a lot of worlds have felt more locked out of.
But what are the opportunities you see for new innovations in that kind of data space, but also to keeping in mind the things that are so critical for it?
like making sure it's secure and that the data is used sensitively.
Yeah, absolutely.
Yeah, I think really the big opportunity here is that you can just build significantly better business applications, whether it's for humans or humans working with agents or for agents operating autonomously, when you understand the organization you're servicing or supporting in much more detail.
And so I think the interesting thing about our approach way back when starting with HCM and payroll is that it gives you a handle and to some extent a very up-to-date view on what is happening in an organization.
As you can imagine, everybody in a company is incentivized to keep the payroll system up to date.
Every time somebody starts, they need to get paid, so they go into the payroll system.
time somebody leaves, you need to stop paying them.
So you update the payroll system.
And so it's this hook into the organization that is up to the minute accurate.
And from there, you can build many other solutions much better.
You can do a better job of IT and access management because as people come and go, you can revote.
their access, you know their role in the organization, you know who they report to, you know their department, you know the states or subsets of data they should have access to depending on their level or a bunch of other criteria.
And so to some extent, you know, HCM and payroll was just the stepping stone to get a good hook or like a good trigger into this like dynamic part of the organization.
And then you can build.
I think almost every other business application just a little bit better, like once you have that hook.
So, you know, that's kind of how I bridge from, hey, you know, like HCM and Peril, you know, that's kind of like the boring, you know, old school human software to, hey, it's actually just the entry point that allows you to build a lot of innovative business software in other domains.
You know, it's almost like the Trojan horse that gets you access to, you know, all of this foundational organizational data.
Right.
I love that you call it a hook.
That's exactly what it makes me think of.
It's a big human hook on the organization that deterministically runs and it keeps in that it becomes then like a really great source of.
And in our old world that we lived in, you know, you were still keeper and custodian of this data.
You built the infrastructure that makes knowing and having that data up to date and all the relations of it accurate and trustworthy.
All of that was already built in and there because it needed to be because it's something as important as payroll.
But now it's almost as if you built a highway that ended at a gate.
And you just didn't know that it was a gate and not the end of the road.
And then now the gate's open.
You're like, oh, I'm already going a thousand miles an hour and I'm just going to fly through this gate.
My highway I've already built.
And now there's so much more downstream opportunities that can consume and use this very trustworthy, very well sourced, but then also very rich and interconnected.
information and for enterprises and people who are provisioning and deprovisioning all sorts of access and roles and permissions and applications at scale within like a large org, like having that minute to minute updated information is critical for building workflows right now that are going to be durable.
I think the trustworthiness and the reliability of that kind of data is a huge blocking point for most enterprise orgs that want to try to go down that route.
So how do you all then identify and partner with those kinds of builders?
And what kinds of opportunities have you seen now that the gate is open?
I mean, I think the big opportunity has really just been helping companies do more with their data, right?
As we've launched our Rippling AI product, it's been remarkable to see.
You'll take an HR business partner or some kind of HR admin at the company.
They are asking some questions about their employee base.
Suddenly, they're able to easily inspect the activity logs.
They can find out where certain members of the company are working.
There might be some kind of security issue.
Sometimes there's fraud at a company you have to investigate.
It gives a lot of the folks managing this business a lot more power.
uh to to navigate you know all of the company data and it is remarkable what you can like get done when that happens and so i think to some extent a lot of the building we've done has kind of like gone from hey you just want to organize the organizational data to uh you know get people paid on time to you can actually glean a lot more insight for how you run your business you know whether it's delivering better services to customers by knowing when people are on PTO or when they need to take some other kind of leave so you can rejigger your schedules or detecting some kind of security issue or fraud issue as you run your company.
That access to data, it wasn't just about organizing the data for payroll.
It's now like you can access data for a bunch of other reasons.
And so I think that's been super gratifying to see.
And to your point too, It's been remarkable to see how primitives that we've built, like permissions and workflows and reports, you know, have...
come alive in this agentic era as well.
Because you now have agents that can act on behalf of the humans, but they don't see more than the humans can.
You can trigger workflows and have them take more kind of like agentic, non-deterministic actions in some cases.
You can build reports more easily, again, leading you to insights more quickly.
And so the whole kind of like agentic engineering on top of the company data really allows many more people at the company to get stuff built and run their part of the business picture.
So I'm just seeing that theme reoccur over and over.
This episode is brought to you by Linear B, the engineering productivity platform.
There's a widening gap between engineering teams that have turned AI adoption into delivered work and the teams that haven't.
It's real, it's measurable, and it's growing every quarter.
On July 30th, Linear B's CTO Yishai Beery with Ben Lloyd Pearson and Andrew Ziegler walk through new engineering benchmarks built on 2.7 million pull requests from 250 plus engineering organizations.
You'll see why high AI usage correlates with a 2x increase to PR merge rate, And why more AI code doesn't automatically mean more shipped code.
We'll also cover the lowest effort win that's available right now, turning on AI code reviews.
Register to join live and get first access to the full report.
Save your seat at LinearB.io.
And that's a really big problem space to solve for too.
When we've talked with...
guests on the show who have built really ambitious, almost like chat and assistant services inside of their very wide surface area applications.
We had Andrew McAmarra here from Shopify talking about Shopify.
They have their assistant, their buddy assistant.
It'll run your whole store for you.
You can do literally everything in Shopify.
It's like, how do you deliver?
And anyone can sell any kind of thing on Shopify.
So how do you deliver an agent that can meet all this kinds of stuff?
We talked about, obviously, this falls into a world of of evals and testing and building trust and how you engineer those systems in general.
And I think there's hints of that in what you're saying, because we're talking about unifying now into a platform and the platform becoming the opportunity.
This is kind of where I want to shift gears and understand more about how you lead an engineering org through that kind of challenge.
That's a lot of what we like to get to the heart of on Dev Interrupted.
I think that's a really powerful takeaway for folks right now to understand, like, how did you create?
identify and create those opportunities within your engineering org that became these things that are like the AI assistant and this AI-ready highway and stuff like that.
Yeah, it's definitely been an interesting journey over the last few years.
And I think a key to getting us to where we are is, I think, a healthy balance between investment in more like foundational platform primitives.
Here I think about...
a bunch of engineering work we've done on our data layer, both the transactional and analytical data, the ability to store that, query that, defined custom objects and custom functions and custom apps on top of that.
These are all like platform building blocks to some extent, but then also creating a lot of space.
for the engineering teams to experiment with and compose those platform building blocks in a wide array of solutions.
Some of those became products.
Some of those we sometimes parked, but then would come back to later.
And the reason to build them was to expand the capabilities of the platform, a stress-based new platform capabilities.
And so it's a bit of a, not like let a thousand flowers bloom, but maybe late.
many dozens of flowers bloom and then periodically you kind of want to reap some of them into a bouquet.
And so when I look now at a lot of the AI products we've released or things coming soon, a lot of them came down to bringing together a few product engineers, a few platform engineers, taking a couple of these building blocks and assembling them into these products.
And so just making sure the team had the freedom to do that.
And I think the other thing that's been interesting is, you know, thinking about my own role and also a lot of the other engineering leaders, we've jumped in and, you know, kind of like line managed a bunch of these efforts over the last two years or so, where, you know, inevitably...
To build almost anything interesting right now, you need to pull a few people or a few components built across three, four, five teams.
There's never going to be one team that has all of the puzzle pieces or all of the building blocks under their control.
You can't always reorg to get to a team that has all of the pieces under their control.
Or you realize, hey, we would need to...
make a team called the software team or the AI team that does everything at the company that doesn't really work.
And so you have to be a lot more agile when it comes to assembling these teams, getting them to build stuff, seeing what works, fine-tuning it, sometimes combining forces with other teams.
And so just the willingness to break down some of the organizational silos and kind of like, I call it a big smoothie, make a bit of a technology smoothie.
and a bit of a team smoothie and then stuff comes out.
Make a smoothie, just like break down all the barriers, put things back together.
Everyone's learning again.
Everyone's building from the beginning again.
And we're also all too along this journey going to be reinventing how we even ship our software because under the hood of all of this innovation we're trying to deliver to our customers, we're also making our...
engineering pipeline or SDLC as agentic as possible so we can support all of the needs that were, you know, it's like an inverse pyramid, right?
It's like everything is balancing on the one point.
That one point is that ADLC.
And so it's like you have to think about that from the beginning.
And I think mixing up the teams is really smart.
It lets you find new ways for teams to operate.
I'm sure that also too naturally complemented the reality of engineers having to build new skills.
in order to be successful at your job?
Like, what have you seen as being like the emerging new skills of like these new kind of pods or teams?
Like, you're probably seeing a lot of like very broad generalists.
What kinds of specialization distributions do you tend to see once you create that kind of environment?
Interesting question.
Yeah, I think the pattern I've seen a number of times now is, you know, you will have...
one or two AI-pilled engineers in an area that have really figured out, like harness engineering or agentic engineering.
And it really helps to combine them with some folks that are still figuring it out onto the same project.
So I think like having a bit of a smoothie of people that get it and people that are still figuring it out.
I think another key thing has just been, to the point earlier about maximally ambitious goals, just setting a very big near-term goal for that team.
And to some extent, it's almost a hack to force them to think out of the box and think about how they might solve the problem using AI, agents, LMs, whatever the case might be, in a completely new way.
I think that has spurred a lot of innovation.
For example, we did a project recently to expand the set of data connectors for ingesting data into Rippling.
And as we kicked off that project, the message to the team was clear.
Like, hey, it used to take, I don't know, in weeks to build a data connector.
You guys now have to build 10 of these in two weeks.
So let's go figure out how to do that.
Basically, the team got together, they spent a bunch of time thinking about the harness that would help them write the spec, the harness that would help them generate the code from that, and then also the harness that would generate the output.
And so it took a couple of weeks of experimentation to wire that all up.
But once you're through that, everybody that was involved in that effort thinks very differently about how to build software.
And so you want to do that over and over in every area.
You'll find this one project where you force the team to think differently and build with AI.
Also, not everything is going to work.
You learn some lessons about, hey, if you approach it like this, you're going to get slop out or you're not going to get functioning code out.
You can design compensating controls and feedback loops and eventually people make it click and then they take that with them to the next project and the next project.
But you kind of have to engineer those enforcing functions to some extent.
You heard how Rippling's teams set near impossible goals.
10 data connectors in two weeks when a single connector used to be its own multi-week project.
Teams are hitting goals like that now that AI is in the loop.
And the moment they do, leadership wants to know whether that speed is paying off.
LinearB is the engineering productivity platform that measures AI impact at the pull request level so you can see how AI is shaping speed, quality, and efficiency across every team and then put those gains back to work in your organization.
Stop guessing at your AI ROI and start proving it.
See how at LinearB.io.
Right, you kind of have to force the Tiger team to have to exist.
That's actually something we...
We heard from James Everingham when he was here on the show.
He used to be a VP of engineering at Meta, and he talked about when they created their internal platform for how folks will build and innovate with agents and experiment internally about what does and doesn't work.
The thing that consistently worked was setting impossible goals.
of being like, we're going to set this metric, this North Star, this goal that we're all looking at it.
And even I setting the goal, it's like, this is an impossible goal, but we're in a world where things that used to be impossible no longer are.
And we have to at least check to see which of those are true and still false.
And so it becomes like this really interesting investigatory time where people are thrown up against really impossible challenges.
And from that, you just get, new ways of working people someone comes up with an ingenious new way of flipping the whole process or inverting it and now suddenly you're cutting out baggage and those are the kind of situations you kind of have to orchestrate as like a leader in order to get that share of information uh to kind of start building to start building those practices right exactly yeah i think the other thing that's also come up is you know You can build so much more in a two-day, three-day, five-day period.
I think about 168 hours.
What can you do in 168 hours?
You frequently see one or two engineers able to go very, very far in 168 hours.
And so also unleashing them.
letting them fight their way through the jungle and then letting them show the rest of the team what's possible.
Because, again, it's another way to help people imagine more is possible, more can be done faster, and so you just have to create a bit of space to do that kind of thing with the team.
Yeah.
So I have a question about where you might think that the future is going.
For a lot of companies like yours that are in the market and SaaS companies in general, I think are facing in a lot of different environments and industries like this build versus buy dilemma where things that yesterday would be something that you would, of course, buy from a vendor, become a quick...
build decision.
And while I think of the world of Rippling and what you'll do is far beyond a build versus buy debate and the obvious arguments are there for why you would buy Rippling as opposed to, you know, Vive code your own.
But all of that aside, the reality is that there's a whole apocalypse happening for SaaS over here.
And so you're going to get a lot of losers in this space where their data in the world that they lived in no longer has a home.
It doesn't have a place.
Does Rippling become this kind of data layer where maybe you see types of information living from the entire organization beyond just like some of the initial points you've been talking about?
Like, you know, obviously HR and finance and such.
Where do you see the future being for Rippling and the kind of data it's sitting on?
Yeah, I think the data layer is, of course, very important.
The big push for us right now is to ingest process, compute over, apply intelligence to much wider sets of business data.
And so you're going to see quite a few products from us landing in the next couple of months in this realm.
And so I do think...
to survive as a platform here in the long term, you need, you know, access to pretty expansive states of data.
You know, you're going to see this across the industry.
Everyone is going to be fighting to import, you know, everyone else's data.
We expect some bilateral data treaties to emerge.
I'll give you my data if you give me mine.
It's going to be interesting, of course, if you ask some customers, they'll say, hey, it's not the platform's data, it's my data.
I think there's a lot to be reconciled there.
But generally, platforms are going to work hard, I think, to amass data.
That said, though, I don't think just being a data store or even being a system of record for some sets of the data is enough.
I think there's a lot of other systems of X that you need to become to be a durable platform in the long term.
For example, I think you have to be a system where you see events in the world.
We're tentatively calling it a system of triggers.
So you see things changing about your organization or you see real-world events and you are notified of them and you're frequently the first system to be notified.
You need to do that.
You need to be a system of record.
You need to be a system of work.
i.e.
humans and or agents come into your platform to do their work.
That generates more data that you can store in the system of record.
It generates more events that you can trigger on.
So there's a bit of a flywheel there.
But people have to do work in your system.
I think you need to be a system of compute.
The agents should run inside of your system or inside of your platform, close to all of the data that you're a record for.
And I think finally, you also need to be a system of action.
So in many cases, if some data changes or some compute has run, there is still some real world side effect to be achieved.
You need to make a payment.
In the digital world, maybe you need to send a web book or send an email.
But in the physical world, you need to make a payment.
You need to file a tax form.
You need to send a physical piece of mail.
You need to ship a laptop.
I think it's important for durable platforms to also have one foot in that realm.
So if you can string all of that together, all the way from triggers to data and compute to action with some work happening on top, then I think you stick around.
If you're merely a database with some forms on top and you're not a key part of those workflows, I think you could struggle in the long term.
It's a really fascinating new kind of product, I think.
doesn't exist yet.
The idea of it's almost like a harness on your business or on your organization.
And it's aware of what's happening underneath and can give you advice, but you can also interact with it in a natural language way.
And that's a level of insight and operability that you don't typically see from the kinds of data sources that platforms and providers are able to put together.
So it's really high leverage to be able to provide that kind of assistantship, you know?
Absolutely.
Yeah, I think the natural language element, as you mentioned, that is new and that is very exciting.
The other dynamic we see unfolding is also natural language as another way to write code or configuration that makes the system do what you need it to do.
You don't always want to compute in natural language terms.
It is probably sometimes a good idea to turn some of that.
back into code as well.
And I think the other thing that's going to be very interesting is, kind of as you mentioned, I think we are steering towards a bit of a observability and maintenance apocalypse here.
I think as an industry, we haven't fully figured out after you build all of these complex workflows and complex systems of triggers and actions and compute and...
and all of that.
How do you keep it all working, especially if there's non-deterministic AI in the mix as well?
And so I think evals are just the beginning.
We have so much to learn about how you taste these systems, keep them reliable, keep them working, when there's basically so much entropy trying to tear them down again.
And so I think we're in for an exciting ride and trying to build platforms that deliver.
reliable solutions in the face of all of this, like non-determinism and uncertainty, like that's going to be the big challenge.
Yeah.
Well, you call it in a, in a apocalypse for the observability tools, but really it's an explosion of opportunity for them because the eval, the eval layer is so critical.
And it is so important.
Something I want to understand from your perspective is what do you think matters to you and your engineering team?
And where do evals fall in the process?
Do you start with evals?
Do you think evals are, how important are they to the contract of delivering the software that you deliver now, since it's such a baseline part of measuring that?
Absolutely.
Yeah, I really think, you know, to some extent, the eval is the new unit taste and also frequently the integration taste.
And so, you know, in the same ways you couldn't build traditional software without tastes or you certainly would struggle to build good ones.
I think evals, you know, in this new agentic era are incredibly important.
At the same time, we're finding that you...
still have to carefully inspect all of the subsystems that make up one of these AI machines.
And you can't just rely on end-to-end evals.
Things we've seen, for example, is that the models are actually remarkably resilient these days.
And even when subsystems are malfunctioning, they'll still kind of sort of solve your problem for you.
but sometimes quite inefficiently, right?
They'll take a very long path to get to an answer or they might do it right, you know, once, but like fail the next time.
So there's, you know, some unreliability that can come from it.
And so I don't think evals is the whole story.
You still need to carefully observe, inspect, trace through the underlying systems as well.
And so, you know, a healthy balance of, you know, like both approaches, I think is key.
And then...
figuring out how you also express assertions about the underlying system behavior, making sure all of the tools that get called by the models or the retrieval systems that fetch data, they still have to work, right?
You can't forget about them.
So the balancing and evaluation process is really important.
And to those that have been listening and have interrupted, that is...
All of our guests really in sequence, everybody is agreeing about the importance of evals.
We continue to stress that here with our leaders who build these incredible products that have huge delivery spaces.
the eval is such a critical part of that build loop.
So just another reminder for our listeners as well.
And we talked about it a little bit earlier about the new problem space and or rather the new data offerings coming from Rippling to serve customers on this kind of data front.
We talked about in the beginning as well.
Can you tell us a little bit more about the Rippling data cloud and what that is going to look like and what people can expect?
Yeah.
So, yeah, as I mentioned earlier, you know, so we have a number of like data capabilities coming to the platform.
Some of this has been released already.
An example of this is a product we called AppStudio that came out, I think, almost a year ago at this point, which allowed customers to define custom objects and custom functions in the system and then build canvases on top of that.
Some of that is, think of it as like pre-AI application building.
Since then, we've added a significant number of data connectors to the platform so you can ingest third-party data into these custom objects or into what we're calling lake objects.
So, for instance, hitting a large-scale data lake store directly.
We've built a data catalog where all of your native rippling data and all of these custom objects live together.
As you can imagine, when you have an AI agent trying to write queries across all of your business systems, having access to a catalog is critically important.
We are releasing a transformations product that allows you to express in SQL transformations of your data from some source table to a destination table.
So you can pre-materialize additional views on your business data.
We have a ton of exciting new capabilities coming in the reports and dashboards space as well.
So we've significantly expanded the dashboarding, our reporting product, and also built a set of capabilities to allow customers to use AI to build dashboards and get new insights.
It's something I'm incredibly excited about.
It's been remarkable to see the agents on the platform be able to take the data catalog.
run some queries to grab sample data and then like build insightful dashboards.
So I think a lot of the point and click to learn about your business is gone.
You're going to wake up every morning with a dashboard tailored to your needs.
Dashboards, dashboards, dashboards.
Yeah, exactly.
And so really, I just think the...
The way the average person in a business is going to engage with their data is about to transform.
And I think you're going to find a lot more insights served up to you and actually useful insights.
And so all of that is coming from us in the next couple of months.
So we're excited to get it out there.
Great.
Well, we'll include links to that so folks can go learn more about all of these new surface areas that you can interact with within Rippling.
And to those listening, you know, if you're not already following Dev Interrupted, be sure to find us on LinkedIn or Substack where we publish our weekly newsletter that comes along with this interview with Albert, where you can find also included a weekly news roundup about what's happening in the agentic engineering space.
While you're there, be sure to follow Albert and myself as well on LinkedIn and stay.
up to date with all of the developments coming from us.
And Albert, thanks again for coming on the show.
It was such a pleasure to have you here today.
Thank you for having me.
Really enjoyed the chat.