A post about core values might seem like an unusual place to start as Sol’s Chief Architect. But this is something I care deeply about, and I can’t tell that story without mentioning Dave Duffield.
Across PeopleSoft, Workday, and Ridgeline, I’ve had roughly 30 years of learning from someone who I think is among the best at building companies around a strong set of values. I’ve seen those values carried forward, helped put them into practice, and experienced what happens when they become deeply ingrained in a company’s culture.
The first time I heard Dave speak, someone asked what it took to build a great company. His answer was simple: start with the best people. Treat them well, and they’ll build great products and take care of your customers. I’ve had the privilege of seeing that belief play out over much of my career.
There’s a familiar saying that culture eats strategy for breakfast. Our strategy at Sol will evolve as we learn and as technology opens up new possibilities. Culture is the foundation that carries a company through that change, and core values are the bedrock underneath it. As an architect, that’s a foundation I care a lot about getting right.
When we started talking about values at Sol, I wanted to pay forward what I’d learned from Dave. I wanted our values to be simple enough to remember and meaningful enough to guide how we build the company. We landed on three words: People. Imagination. Durability.
Those words apply to the whole company. Here’s how I think about them in the team we’re building.
With the best people, we amplify human potential
The people we want to build Sol with are driven, motivated, and humble. That last word matters a lot to me.
I’m competitive. I like solving hard problems, and I like working with people who want to accomplish something ambitious. But engineering requires being comfortable with the possibility that someone else has a better answer. Sometimes that person has less experience than you. Sometimes they’re asking a question you stopped asking years ago.
Those of us who have spent decades building enterprise software bring useful experience. We also bring habits. I want people to feel comfortable questioning each other’s thinking, including mine, and saying, “I think there is a better way to do this.”
One of the engineers who recently joined us helped me question some of my own assumptions about how we should build Sol. It’s easy to carry familiar architectural choices into a new company without fully reconsidering them. Together, we explored a simpler approach: a unified system with clear internal boundaries, reducing the complexity of coordinating many separate services.
There’s a future engineering post in that decision. But the result has been a dramatically simpler architecture that’s allowed us to move faster than I thought possible. It also gives us a foundation that can scale and support the dynamic experiences we’ll need as agentic applications evolve. Getting there started with someone new to the team helping me see another way.
That same belief in people’s potential shapes how we build for our customers. We’re building for the manager helping someone grow, the employee navigating a change in their life, and the People team trying to give both of them the support they need. What we build should give those people more room to exercise their own judgment, creativity, and ambition.
Integrity is essential to that relationship. We need to do what we say we’re going to do and be honest when we fall short. I’ve seen how much it matters to tell a customer that a deadline will slip or that something went wrong. It also means being clear about what we aren’t building and why. Those can be difficult conversations, but handling them honestly builds lasting trust.
We dare to reimagine, then we move
One of the things that pulled me to Sol was the opportunity to rethink an HR system from its foundations. We get to imagine how people will interact with a system built with AI at its core, and then build it.
That means putting conversation first in the interaction model and designing for automation and integration with other agents from the beginning. What should someone be able to accomplish just by describing what they need? What should the system already understand? When should it act, and when should it bring a person into the conversation?
One example is what I’ve lovingly called the Almanac, our approach to reporting. There’s no report designer and no form to fill out. You describe what you want in natural language, and the system builds the report. That gives our engineering and design teams a different set of problems to solve: how to understand what someone means, help them refine it, and present the information in a useful way.
We’re also imagining how a manager could run an entire annual merit cycle this way. They could describe how they want to see their team’s data, work through compensation decisions, and have that experience surface in the system. Throughout, the system would respect their permissions: what they can see and what they’re authorized to change. The experience would also need to make clear where human judgment and approvals are required.
We don’t have an established set of patterns that answers all of those questions. There’s a lot for our engineering and design teams to work out together, and that takes creativity and imagination.
But we aren’t daydreamers. We could spend a very long time debating what the perfect agentic application should look like. We need to drive toward a decision, build something, and learn from what happens when people use it.
We’re going to try things. We’re going to get some of them wrong, and we need to be comfortable with that. Our design partners help us see where an idea works in practice and where we’ve missed something about how their teams work. We need to listen and be honest when an idea we were excited about doesn’t work, or when a decision I helped make needs to change. The point is to learn, apply what we’ve learned, and keep moving.
We build things that last
At our recent offsite, a few of us were discussing whether the craft of software development still matters when AI can produce so much of the code.
I absolutely believe it does.
We’re building a system of record that we want customers to depend on for decades. We need to understand the software we’re building and be confident that we can maintain and extend it over that time. That responsibility remains ours as the tools become more capable.
Will it scale as our customers grow? Are we using patterns we understand and know how to operate? Do we have the right abstractions? Can we extend the system as requirements evolve without making every change harder than the last?
As Jim described in The Hard Things About HR Systems, this domain comes with difficult engineering problems. And as Josh explained in Trust Is a Design Decision, security has to be built into the architecture from the beginning. We’ve invested deeply in our data model and access controls because the experiences we’re imagining depend on accurate data and consistently enforced permissions. Those are foundations we have to get right, and they become much harder to change once customers depend on them.
Much of Sol is being built by agents, and one of the areas I’m most excited about is how we guide that work. We’ve thought carefully about our type system and the patterns and abstractions we want in the software. We need the agents building it to follow those decisions consistently as the codebase grows.
That’s why we’ve invested in the harnesses our engineering agents work within: the instructions, tools, and checks that guide them from authoring code through review. Nearly all of that process is automated at this point, with deliberate checkpoints where our engineers inspect the agents’ work, verify the result, and make sure they understand what’s being built. We’re finding the right balance of speed and correctness, and learning where human judgment matters most.
I see that as part of durability. We’re building a platform we intend to maintain and extend for years, and we’re investing in the engineering process that will help us do that. As we learn and improve our approach, we can carry those improvements into how the agents work.
Durability applies to the company itself, too. It requires judgment about where to invest now and what can wait. The details matter because we stand behind our work, and we’re designing Sol so its value to customers compounds over time.
Putting our values to work
We kept these values simple because we want everyone at Sol to remember them and develop their own understanding of what they mean in practice.
For me, they show up in who we hire, how we challenge an idea, and the care we put into the foundation. They also show up in how we listen to our customers, how we earn their trust, and whether what we build makes their work easier. As the company grows, I want those values to remain useful in decisions none of us can anticipate today.
I’ve been fortunate to spend my career with people who showed me what that can look like. Helping build it at Sol is one of the parts of this next chapter I care about most.
People. Imagination. Durability.
That’s what I want us to build on.
