From AdTech to Hiring: The Missing Data Layer in Workforce Systems

I didn’t set out to work in workforce technology.

I spent the first 13 years of my career in digital advertising, and a decade of that was at OpenX. We were part of the early wave of companies building real-time bidding—where every ad impression gets auctioned off in milliseconds based on data about the person viewing it. At the time, it felt incredibly complex and incredibly powerful. A publisher would send a signal into the exchange, and attached to that signal was all kinds of information—what page the user was on, where they were, what device they were using, and an identifier that allowed other systems to layer in even more data. That request would get fanned out to demand-side platforms, who would evaluate it based on everything they knew about that user and decide whether to bid.

It changed everything. Advertisers no longer had to buy broad chunks of media and hope for the best. They could make decisions at the level of the individual. Data wasn’t just helpful—it was the system. And for a while, I loved it. I loved the complexity, the scale, the partnerships. I loved being in the middle of a marketplace where all of these systems were talking to each other and making decisions in real time.

But after about a decade, I burned out on it. It started to feel like we were extracting value more than creating it. The system worked best when it could get someone to buy something—and sometimes that meant convincing them to buy something they didn’t need. So I left. Not because I stopped believing in the power of data and marketplaces, but because I wanted to apply those ideas somewhere that felt more constructive. That’s what led me to ZipRecruiter.

What struck me almost immediately was how different the data layer was. On the surface, it looked familiar. It was still a marketplace—job seekers on one side, employers on the other. Still about matching supply and demand. But the underlying data was thin. Really thin. Instead of rich, structured signals, we were working with resumes, job descriptions, and location. And resumes were doing a lot of heavy lifting despite being unstructured, inconsistent, and often incomplete. People listed jobs and degrees, but the actual signal—what they could do, what they had learned, how they had been evaluated—was mostly implied. Coming from advertising, it felt like stepping backward in time.

My first job there was to figure out new ways to bring job seekers into the marketplace, which led me to partnerships with online learning platforms like Coursera and others that were helping people build new skills. Originally, the idea was straightforward: bring ZipRecruiter jobs into those platforms. But one partner suggested flipping it. What if we brought their learners into ZipRecruiter—with the data they had earned?

That’s when I first really understood digital badges. At first, I thought of them as credentials. But the more I dug in, the more I realized they were something else entirely. They carried data—structured data about what someone had learned, how they had been assessed, what skills were involved, and who issued it. And that data could move. That was the moment things clicked for me, because I had already seen what happens when rich, structured data enters a marketplace.

We ended up building an early integration to bring that data into ZipRecruiter, and even though we only used a small portion of what was available, the impact showed up quickly. Matching got better. Engagement improved. Employers responded more positively to candidates who had this data attached. You could see it in the metrics—higher open rates, better click-through, more employer interest. None of that surprised me. It was exactly what I would have expected. What surprised me was that it didn’t go further, and the reason was simple: there wasn’t enough of the data. Not enough people had it. Not enough systems were producing it. The ecosystem wasn’t ready for it to scale. So the idea worked, but it stalled.

That experience stuck with me because the contrast was so clear. In advertising, we had built systems where decisions were driven by structured data, evaluated in real time, and constantly improving. In hiring, we were still relying on resumes and human interpretation to fill in the gaps. It wasn’t just a difference in tools. It was a difference in how the system functioned.

That’s what led me into what we now call Learning and Employment Records. Not from the perspective of issuing credentials, but from the perspective of what hiring systems actually need. I wasn’t asking how to create better badges. I was asking what data was missing from hiring systems that would allow them to work better. LERs were the first answer that made sense. They represent a path toward something hiring has never really had—structured, portable, comparable signals about what people know and can do.

And that matters even more now. AI has made it easier than ever to generate a resume, and at the same time, harder than ever to trust one. The signal problem in hiring is getting worse, not better. At the same time, more organizations are producing LER data and the ecosystem is starting to take shape. But the core issue hasn’t changed. This data doesn’t create value until it shows up inside the systems where hiring decisions are actually made.

But that also clarified something for me that I hadn’t fully articulated at the time.

The challenge wasn’t that employers didn’t understand this data, or even that they didn’t value it. It was that it wasn’t showing up in the places where they were actually making decisions. It lived outside the system—adjacent to it, but not integrated into it—and that meant it required extra effort, extra context, and in most cases, a reason to go looking for it.

And that’s not how adoption happens.

We don’t need employers to “engage with LERs.” We need LER data to become part of how hiring systems work, because employers don’t adopt credentials—they adopt tools that help them make better decisions. When better data flows into those systems, behavior changes naturally. I’ve seen that happen before, and that’s why I believe this matters.

That’s where this stopped being interesting and started feeling unfinished.

Because I had already seen what happens when a real data layer shows up at scale. I had seen systems evolve around it, I had seen entirely new behaviors emerge, and none of that happened because someone convinced advertisers to care more—it happened because the system itself became better at making decisions.

And in hiring, we were right at the edge of that. The data existed, the early signals were there, and even in a limited test you could see the impact when it showed up. But it wasn’t connected, it wasn’t flowing across systems, and it wasn’t reaching the places where decisions were actually being made. The idea worked, but it stalled before it could reshape the system.

That’s what made it hard to leave alone.

I didn’t walk away from it because it failed. I walked away from it because it worked, and I couldn’t see a path for it to scale from inside the constraints of a single platform. I wanted to stay close to the part of the ecosystem where that gap actually exists—where data moves (or doesn’t) between systems, where standards either connect or fragment, and where small improvements in structure and interoperability can have an outsized impact on how decisions get made.

That’s what led me to SmartResume, and eventually to starting Signol Labs. Not because I wanted to build another product, but because the problem I was chasing wasn’t a product problem. It was a system problem.

The opportunity isn’t just to create better records of what people have done. It’s to make that information usable, trusted, and connected across the systems that actually shape opportunity. And if that happens—if this data starts to flow into the environments where hiring decisions are made—then employer engagement won’t be something we have to ask for.

It will just be a byproduct of a system that finally has the data it’s been missing all along.