The Approach

Most of what you see on this site is the work itself. The offerings, the sample Insight, the story of how this practice came to be. This page is different. It’s for readers who want to understand the foundation underneath all of that.

What discipline does Waypoint Thinking operate within? How do I think about HR systems work? What’s the framework that makes the methodology possible?

For 25 years I was doing this work without naming it. The pattern recognition happened, the framings worked, the methodology developed. But I didn’t have language for what kind of thinking it was. Recently I’ve started to name it. This page is where I start putting that into words.

HR systems work is usually seen as a collection of components. Core HR, payroll, talent, comp, learning, performance, time tracking, recruiting. At some organizations these all live in one platform like Workday. At others they’re spread across separate systems connected by integrations. Some live partially in Finance or IT systems. The structure varies and the lines between systems aren’t always clean.

What stays consistent is that people specialize in their pieces. Someone owns Payroll. Someone owns Talent. Someone owns the integration between HR and Finance. The work is real and the people doing it are skilled.

What rarely happens is anyone stepping back to see all of it as a connected whole, regardless of how the stack is configured.

That’s what I do. I see how a decision someone makes in Comp today shows up two years from now when Finance pulls headcount data for budget planning. How a workaround built in Talent during go-live becomes the way new hires get processed forever. How an integration choice between HR and IT determines whose data wins when they disagree. How a dashboard built to answer one question quietly becomes the org’s official answer to a different question.

This kind of thinking has a name. It’s called systems thinking, and it’s been around for decades. Donella Meadows and Peter Senge wrote the foundational books on it. Plenty of business school and design programs teach it. The basic idea is that complex systems behave as integrated wholes, and you can’t really understand one part without seeing how it interacts with the others.

It just rarely gets applied to HR systems work specifically. The field is good at modules. It’s good at implementations. It’s good at integrations. The landscape view is the gap.

I got the intellectual foundation for this from a few different places. My MBA at Case Western Reserve University was unusual. The Weatherhead program in those years was built around design and identifying design opportunities. The Peter B. Lewis Building was the physical sign of it. The intellectual influence ran deeper. The most influential class for me was a year-long course on identifying design opportunities. It was rigorous about the distinction between solving the problem you’ve been handed and figuring out which problem actually needs solving. Other coursework in organizational behavior taught me how to observe groups and patterns. And most of the foundation came from 25 years of being inside this work. Watching the same patterns repeat. Being on small teams where you do everything. Being in big organizations where ownership gets fuzzy, especially the closer you get to the integrated view.

The pattern recognition came from seeing it happen so many times. I can tell you what’s going to break in an implementation six weeks before it breaks because I’ve watched the same pattern play out before. I can tell you what a dashboard is really doing because I’ve seen what dashboards do over time. That’s not a methodology I invented. It’s pattern recognition built up over years of practice.

That perspective has stayed consistent across the systems I’ve worked in. Workday. SAP. SuccessFactors. PeopleSoft. JD Edwards. The systems are different. The patterns underneath are largely the same. People often get identified by the system they work in. They’re a Workday person, an SAP person, a UKG person. The platform becomes part of the identity. What I focus on instead is what the business is trying to accomplish, and how the system can support those goals. The system is the tool. The work is understanding what the work actually is.

I call what I do HR systems thinking. It’s not a new discipline. It’s an established way of thinking that gets applied to a specific kind of work, by someone who’s spent a long time doing that work and noticing the patterns.

Most of what HR systems thinking sees is just what you’d see if you had time to step back. The full arc of HR data from applicant to retiree. The dozen systems that touch one person’s data over their employment. The decisions in one system that ripple through others over years. The data flowing across modules and vendors, into Finance and IT and Procurement and Security, each adjacent system with its own logic and its own assumptions.

Decisions in HR systems happen at multiple altitudes at once. Day-to-day operational stuff. Configuration choices. Architectural decisions. Strategic moves about what systems to add or retire. Most people work at one altitude. The landscape view sees across them.

This kind of thinking is rare in HR systems work. Not because it’s hard or obscure. It just doesn’t fit the conditions most people are working in. There isn’t time. Reward structures push you toward specialization. The cross-cutting view requires stepping out of the immediate work, and most teams don’t have that step-out time built in.

That’s the gap WT fills. Whole-system thinking applied to HR systems work, in the middle of stuck moments, by someone who’s been there.

Within HR systems work, there are different altitudes of effort. Each one matters. Each requires its own kind of expertise. Most practitioners spend most of their time at one altitude.

Data. Field definitions, master data, employee records, data integrity. The foundation. The things that have to be right or nothing else works. Get this wrong and every downstream process breaks. People who do this work well are detail-oriented, careful, and disciplined about consistency. It’s not glamorous, but the system depends on it.

Process. Workflows, business rules, module configurations, integration logic. The field-by-field mechanics of how data moves and how the system performs its functions. The benefits enrollment workflow that has to calculate the right options based on someone’s role and tenure. The payroll integration that maps fields from HCM into the payroll system. The talent module configuration that determines what shows up in performance review cycles. This is where a lot of HR systems work actually happens. At larger organizations the work involves analysts, architects, developers, functional leads, and managers all collaborating. At smaller organizations one person is often doing all of these roles at once. Even directors and senior leaders end up spending real time here, more than most of them planned to. The work requires technical skill, attention to edge cases, and patience with the way real organizations actually use systems.

Experience. Where a real human meets the system. Self-service portals where employees update their information or enroll in benefits. Manager dashboards where someone draws conclusions about their team. New hire onboarding flows. Anywhere a person has to look at the system, understand what it’s telling them, and make a decision. This is the level where what the system says and what the person hears can drift apart. A workflow that’s technically correct can still be miserable to use. A dashboard that’s accurate can still mislead. There’s a famous design observation about watching people fill out forms. Some would sit there sweating, trying to figure out what to do, and never ask for help. That’s the kind of thing this level is about. The data and the configuration are both fine. The human in the middle is the one struggling.

Landscape. What the other three look like together. How a decision at the Data level affects what people experience years later. How a Process configuration interacts with the next module that gets implemented. How an integration choice between HR and Finance changes who owns which piece of data going forward. How a report built for one question quietly becomes the answer to a different one. This is the view that’s hardest to maintain in the middle of the work itself.

Most stuck moments look like problems at one of the first three levels. A data issue. A process question. A user complaint. But the actual decision underneath usually involves more than one level at once. A data definition that became a reporting standard that’s now driving leadership conversations. A configuration choice that shaped how users experience the system that’s now affecting what leadership thinks the workforce looks like. Naming the decision usually means seeing how the levels are interacting, not pointing to one level as the source. That’s the full landscape of HR systems work, and the perspective WT brings to whatever level a stuck moment lives in.

That’s the view WT brings to whatever level the stuck moment lives in.

This page is the starting point. 25 years of observations and experiences that I’ve finally started to write down.

I’ll be writing about specific patterns I’ve seen across the years. The ways the levels interact in real stuck moments. The decisions practitioners face that don’t fit cleanly into job descriptions. The shape of the work as it actually happens, not as the org chart says it should.

Some of the essays will go deeper into specific frames the methodology uses. Frames like Decision Level Confusion and Workaround Wearing a Badge name patterns that show up again and again in HR systems work. Each frame is a way of recognizing what’s actually happening when something feels stuck. New frames get added as the work develops and new patterns get clearly named.

Other essays will be about the current moment. AI showing up in HR tech. Fragmentation of the stack. The proliferation of decisions practitioners are absorbing. The conditions of the work and what they’re doing to the people doing it.

These will appear in the Observations section as they’re ready. Each piece will be substantive. These aren’t quick takes. They’re attempts to say things clearly that take real space to get right.

If the starting point here resonates, the essays are where it gets developed.