The 5% Problem

By Courtney Cherry Ellis, Founding Product Architect, Sol

For much of my career in People, I took pride in not being a typical “people person.” I came into HR through consulting, and I was always looking outside the People team for better ways to operate.

Eventually, I started running People like a product organization. We gathered feedback, worked in sprints, built roadmaps and made tradeoffs. We designed programs for the 95% rather than letting every custom request derail the roadmap.

I believed that was what good product thinking looked like.

Then I noticed something harder to reconcile: my teams were still spending an enormous amount of time on the other 5%. The complex offer. The immigration case in limbo. The promotion outside the merit cycle. The employee dealing with a devastating house fire. At first, these felt like outliers keeping us from the real work.

Over time, I started to see those exceptions differently. They were telling us something.

We would build programs around what the technology could support, then design our processes around its constraints. Compensation was a good example: changes outside formal cycles were difficult, so employees learned that one of the most reliable ways to get a meaningful raise or promotion was to get a competitive offer and threaten to leave. A rigid system was shaping how organizations worked.

In one role, we saw a spike in what we called “battlefield promotions,” largely in response to counteroffers. We could have treated each one as an exception. Instead, we looked at the pattern. Had getting another offer become the most reliable way to earn a meaningful raise? What did that tell us about internal mobility and how we were managing careers?

These exceptions weren’t noise, they were showing us where the system was failing.

I saw the same thing in a more personal way when someone on my team lost their partner, far too young, to an aggressive cancer just before open enrollment. That experience tested everything we had designed: benefits, leave, manager guidance, capacity planning. We changed things after that. A benefits gap was closed, policies and manager guidance changed. 

But the reasoning behind those decisions didn’t survive in the system. Where did the policy need to bend? Why did we make that exception? What would we want to do differently next time? That knowledge still lived in people.

For years, I thought my job was to make the system good enough that we needed fewer exceptions. Now I think those exceptions are one of the best ways to understand whether the system is good at all.

That realization is part of what pulled me from People into Product. In software, there’s a name for the route you designed for: “the happy path”. The happy path proves you can execute what you already understood.

There’s also a name for testing the cases most likely to break your assumptions: an eval. 

I had been running evals for the last 20 years. I just called them fire drills.

That may be the biggest thing I brought with me from People into Product: an instinct to pay attention to the cases the system wasn’t designed for. They’re where you learn what to build next.