I’m a mechanical and aerospace engineer by education and training, and I had the incredible fortune to spend the first half of that career building spacecraft for very challenging science missions. That experience taught me the value of rigorous engineering discipline. I carried that mindset with me to enterprise software when I joined Workday, where I spent the last thirteen years, including six as CTO.
I made the leap into enterprise software for one primary reason: I knew the problems being solved were hard. Really hard. It took a long time to fully appreciate why it’s so difficult to build and serve HR software well, but it was clear from the outset that these were world-class engineers working on world-class engineering problems. I have deep respect for what it takes to build and maintain these systems and also a clear view of the challenges existing systems haven’t solved, and how AI finally gives us an opening to tackle them head-on.
Configurability is a double-edged sword
Every HR system has to solve the same tension. Customers need to configure the system to match how they work, but in multi-tenant SaaS, that configurability compounds across all of your customers. The more successful you are as a software company, the more that configuration becomes bloated, difficult to understand, and even more difficult to maintain. It becomes an anchor that prevents change within an organization. Built the legacy way, the argument that configuration is the antidote to customization, a position I championed for many years, erodes linearly with the success of the company.
That’s why we made configuration a first-class part of Sol from the very beginning. Take a company’s leave policy. To the person administering it, updating that policy should feel like editing a Google Doc. You write it in plain language, publish a new version, and the software updates with it. You’re not filing a request and waiting for someone else to translate your intent into system configuration. Treating configuration as a true product feature also lets us ship default, out-of-the-box configuration that makes it easier to adopt new features, processes, and setup.
The same design thinking extends directly to the implementation problem. Anyone who owns a modern HR system knows how time-consuming and expensive implementation is. There are three primary drivers: understanding the legacy configuration and processes, mapping data structures from the old system to the new, and actually configuring the new system. AI has finally lowered the friction on the first two, and pointing that at a system built for ease of configuration means the whole pipeline can be orders of magnitude easier.
Taken together, the software is no longer the bottleneck for change. The system adapts at the speed your business adapts.
Security is never simple
The data in an HR system is about as sensitive as it gets. It’s the company’s data and the personal data of every individual who works there. The security model has to be exactly right, and “right” is more complicated than people expect.
A peer can’t see their peer’s compensation, but their manager can. That rule has to hold on every interaction, for every person, all the time. And it’s not just one rule. What you’re allowed to see, and what actions you’re allowed to take, depends on your role, your reporting relationships, where you are in the world — sometimes even what device or channel you’re using to interact with the system. Then there’s the whole complex world of delegated authority: what one user or group of users is allowed to do on your behalf.
Every interaction also has to be auditable. You need to know who saw what, what actions they took, and whether they were authorized to take them. That’s not something you bolt on later. It has to be part of the foundation.
Agents make this more important, not less. An agent acting on someone’s behalf has to operate within the same permission model as the person it’s working for. It can see only what they can see, do only what they’re allowed to do, and every action has to be governed and audited the same way. That’s true whether the agent is one of ours or one a customer connects from somewhere else. The security model can’t just cover people anymore. It has to cover anything (human or not) that touches the system.
Effective dating is a time machine
One of the hardest things to reason about in an HR system is effective dating. You have to be able to ask a question or run a transaction as of any point in time, past or future, and get the right answer. A raise takes effect next month. A reorganization is approved today but doesn’t happen until next quarter. A correction has to be applied retroactively to a date three months back. Ask what someone made in April, you get April, not today. Run payroll as of a date, it’s correct as of that date.
The hard part isn’t any one dated change. It’s how they interact. Say an employee is scheduled to relocate in three months, and before that happens they get promoted. Do those events conflict? Can they both exist in the system? What does payroll look like in the period between? A real HR system has to hold all of that at once and keep it consistent.
And just like security and auditing, this has to be built into the core from day one.
The system has to stay up
When you’re running payroll or closing open enrollment, the system has to be up. Full stop. And much of the time we’re the source of truth for whether someone even works at a company which means the systems that control physical access are reading from us. If we’re down, that’s not an inconvenience in an HR tool. That’s someone standing outside a building they can’t get into.
Being the source of truth changes how you think about availability. It changes how you think about disaster recovery, and how fast you can bring a customer’s service back if an entire region goes down. And you have to hold that bar as customers grow. Running payroll for fifty employees is a fundamentally different problem from running it for tens of thousands while open enrollment closes. The system has to stay fast, stay correct, and stay available as that load climbs because the days it’s under the most load are exactly the days it matters most.
The rules never hold still
There’s one more challenge, and it never goes away: the rules themselves keep changing.
A workforce isn’t uniform. Full-time employees, contingent workers, part-time staff, people spread across countries, and now agents in the mix. Every category comes with its own rules, and those rules never stop moving. Tax law shifts. Labor regulations evolve. A compliance posture that was correct last quarter can be wrong this quarter, and “wrong” in this domain means someone’s paycheck, someone’s benefits, someone’s legal standing.
The system has to stay correct across all of it, for every worker type in every location. That’s not a problem you solve once during implementation. It’s an ongoing engineering commitment, and the architecture has to be designed for it.
Rethinking the way we build for HR
None of these problems are new. What’s changed is what’s possible.
Previous generations of HR systems were built around transactions. They’re very good at capturing what happened. What they weren’t built for is asking what if. What if we reorganized this team? What if we hired fifty more people? What combination of employees, contractors, and now agents, gets us to the outcome we want? Organizations change constantly, and their systems should help them reason about change, not just record it after the fact.
That’s why we’re building these planning components into Sol alongside the transactional system itself. You model those scenarios against live data before making them real, instead of planning in spreadsheets and then manually translating the results back into your HR system.
None of this is a knock on the systems companies run today. Most of them work, and they’ve worked for a long time. I have a great deal of respect for the people who built them, because I was one of them.
What building those systems taught me is that the hardest engineering problems are rarely the ones users see. They’re in the architecture: keeping a system flexible without becoming brittle, secure without getting in the way, historically accurate across time, and available when companies depend on it most.
Those problems haven’t gone away. But for the first time in two decades, we have tools that let us rethink the assumptions HR software was built on. I didn’t join Sol because building an HR system has gotten easy. I joined because it’s finally possible to build one differently, and better.
