How this started.

Most of what’s broken inside HR systems isn’t a technology problem.

After 25 years in this work, the pattern that kept showing up wasn’t bad software or bad people. It was decisions getting made on autopilot. A leader would say “we need a dashboard,” and the team would build one. Six months later, nobody could say what decision it actually supported. A workaround would quietly become the real process while the documented one stayed decorative. Lots of activity. Lots of documentation, so we could show we were busy. Almost no time spent on the upstream question of whether the thing being executed was the right thing in the first place.

The people closest to the work could see it. They almost always could. But they didn’t have the language for what they were seeing, or didn’t have the standing to say it without sounding like they were slowing things down. So the patterns kept repeating. The decision underneath kept going unnamed. And the post-go-live cleanup, six months later, kept proving it.

I noticed this from a lot of seats. Workday, SAP, SuccessFactors, PeopleSoft, JD Edwards. The HRIS systems were never really the hard part. The hard part was always at the seams, where HR data had to cross into Finance, payroll, time tracking, IT, and a dozen other systems with their own logic and their own owners. The technical integrations were challenging enough. Getting HR, IT, and Finance to agree on what they actually wanted, and how the people involved would experience it, was the real work.

I led a team on the internal global side at PwC, making sure 150-plus PwC firms around the world were getting the most out of a shared global Workday tenant. Earlier in my career I was the one person responsible for the entire HRIS environment at a mid-sized manufacturer. No consultants. Just me. I’ve sat in just about every seat in this work. The developer running database SQL updates at midnight so payroll could finish on time. The analyst configuring the system on a Tuesday afternoon. The senior manager presenting strategy to the CHRO on a Thursday morning. Different altitudes, same work.

What I came to believe, over years of this, is that the practitioners who do this work well aren’t the ones with the cleanest roadmaps. They’re the ones who can identify the actual opportunity in front of them and pivot the team toward it. They’re often on small HR teams, wearing many hats, being generous with their time, carrying responsibilities that wouldn’t fit in a job description. They see the seams clearly because they live in them. They notice when the question being asked isn’t the question that matters. But the conditions they’re working inside, pace, pressure, organizational politics, make it hard to stop and name what they’re seeing.

That’s the gap WT is for.

Some of the underlying methodology comes from training I got during my MBA at Case Western Reserve University. The Weatherhead program in those years was built around design and identifying design opportunities. The most influential class for me was a year-long course on identifying design opportunities, taught by someone who was rigorous about the distinction between solving the problem you’ve been handed and correctly identifying which problem is actually worth solving in the first place. That distinction has stayed with me for almost two decades. It turns out to apply to organizational dysfunction at least as much as it applies in the design world.

The thing modern enterprise systems were sold on, the promise that drew so many companies in, was efficiency through standardization. They delivered on that. But the unintended consequence is that the upstream thinking got hollowed out. We became excellent at executing configurations and worse at deciding what to configure. KPIs got built around throughput, because throughput is measurable. Thinking time isn’t, so it falls out of the workday. Configuration debates feel productive in a way governance debates don’t. Best practices substitute for original judgment, and “best practice” usually just means a generic way of doing things that nobody got fired for choosing. It’s rarely the best for any specific company.

This isn’t a knock on the systems or the people. The systems do what they’re built to do. The people are doing their jobs. The structural condition we’re all inside is what creates the problem. Nobody chose to stop thinking. The thinking just got displaced, quietly, by the pressure to keep things moving.

There’s also something worth saying about where this is heading. For most of the last fifteen years, the case for standardization rested on cost. Custom was expensive. Custom was risky. Generic was safe. That math is starting to shift, but not uniformly. Some processes still benefit from standardization, especially where regulation, compliance, or critical operational consistency are at stake. Where AI changes the equation is in the spaces in between, the impressions, the interactions, the experiences people have with their systems and data. The cost of designing those moments deliberately, around how a specific organization actually works, is dropping fast. Companies that figure out where standardization serves them and where it doesn’t, and then design the experience accordingly, are going to have an advantage over the ones still pasting in best practices and hoping. The thinking question gets more important, not less, because the question itself is more nuanced now.

WT is a small thinking practice for the people who do this work. The ones who can already see what’s tangled. Who recognize that the dashboard ask isn’t really about a dashboard. Who notice when the system is taking the blame for something upstream. Who don’t have the language or the standing to name it cleanly without sounding political or slow.

The methodology is the asset. A set of frames refined over decades of seeing the same patterns repeat, encoded into an operating manual that gets applied to every situation a client brings. The work happens in writing, async by design, because writing is itself part of the framing. There’s no procurement, no SOWs, no scheduled calls, no advisory engagement. Different ways to engage exist for different shapes of stuck. A free Problem Finder for when you want to see what the methodology does. A Single Insight when there’s one specific stuck moment. A Thinking Partner engagement for one complex situation that needs deeper exploration over up to 30 days. A Founding Member subscription, capped at 15 practitioners, for ongoing async conversation threads.

The offerings are doors into the practice, not the practice itself. The practice is the methodology applied carefully, in writing, by someone who’s lived inside this work for 25 years and knows what the patterns look like before they’re named.

The work isn’t meant to be a one-time fix. The frames in each Insight are named for a reason. They’re meant to become language clients can carry forward into the next stuck moment, the next meeting, the next decision. A client who reads “this is a Decision Level Confusion problem” and recognizes the pattern starts spotting it in other situations. A client who works through a Workaround Wearing a Badge gets sharper at noticing when other workarounds in their organization are quietly being institutionalized. The methodology compounds. Over time, clients need WT less for the problems they used to need it for, and more for the genuinely new ones. That’s the design. The practice makes practitioners more capable, not more dependent.

I’ll say plainly: I’m a nerd about this stuff. I have a tech background and a brain that’s wired to spot patterns across messy inputs. The frameworks behind the work are mine, refined over decades. The voice is mine. The editorial discipline is mine. The AI does the typing. The thinking is the practice.

If your team always names the decision before they pick the tool, you don’t need this. If they don’t, you already know what happens next.

Every intake is read personally. No identifying details needed. I don’t sell your data, and client inputs are not used to train public AI models.

Reach me at shawn@waypointthinking.com. I reply within one business day.