The HR Function Nobody Built.
Every HR function currently in operation was built the same way. By HR people, using HR frameworks, optimized for HR outcomes. This is a manifesto for the function that almost nobody built instead, one that starts with the business, governs itself against complexity, and designs every program from the last mile backwards.
If you could start over with no legacy systems, no inherited processes, no accumulated complexity, and no programs that exist because they have always existed, what would a business-outcomes-first HR function actually look like?
That question is not hypothetical. Organizations launch new business units, scale startups into enterprises, spin off divisions, and rebuild HR functions after major transformations every year. Each one faces the same choice whether to replicate the conventional HR model that most organizations have assembled over decades, or build something deliberately different.
Almost all of them replicate the conventional model. Not because it is necessarily the right choice, but because it is the available one. The conventional model has a playbook. It has a talent market of practitioners who know how to build it. It has vendor ecosystems, benchmarking data, and professional associations that reinforce its logic. And it has the significant advantage of being familiar, which in organizational design almost always beats being right.
The conventional model also has a well-documented failure mode. It produces HR functions that are internally coherent and externally insufficient. Functions that optimize for HR outcomes while the business absorbs the cost of programs that are adjacent to what it actually needed, processes that are over-designed for the decisions they govern, technology that was acquired before the problem was defined, and a growing HR Complexity Tax that nobody is formally tracking because nobody treats complexity as a budget line.
This article is about the function that most organizations have not built. The one that starts before the first hire, before the first program, before the first technology solution. All with a clear-eyed view of the decisions that the business needs to make well, the system those decisions require, and the governance architecture that prevents complexity from accumulating before the function is two years old.
It is built on ten counter-intuitive design principles, organized into four phases: design, governance, technology, and execution. Each principle inverts a standard assumption of conventional HR design. Together they form the architecture of an HR function that does not need to be simplified, realigned, or transformed five years after its built. All because it was designed correctly the first time.
What the Conventional Model Gets Wrong
The conventional HR function is built in a sequence that almost guarantees the problems it later tries to fix. It begins with people: HR generalists, then specialists, then centers of excellence, who are each hired to manage some domain. Talent acquisition, learning development, total rewards, HR operations and technology, each with domain building and its own programs, and each program building its own processes. Then each process accumulates its own complexity, and somewhere in the third or fourth year of the function’s existence, the CHRO begins talking about simplification.
The simplification effort addresses the symptoms. It reduces process steps, consolidates vendors, rationalizes programs. But what it almost never addresses is the design sequence that produced that complexity in the first place. Because by the time the simplification effort is underway, the sequence has become invisible. The function is what it is. The question is how to make it better, not whether it was built correctly to being with.
The design sequence is the problem. When HR builds by domain rather than by system, fragmentation is baked into the architecture before the first employee is hired. When programs are named before outcomes are defined, misalignment is baked in before the first initiative is launched. When technology is selected before processes are designed, the complexity tax begins accumulating before the first go-live. And when governance is treated as an afterthought, like something to be addresses once the function is operational, then the removal discipline that prevents over-design never develops, and the function grows in only one direction.
The four structural drivers of the HR Complexity Tax, fragmentation, over-design, system misalignment, and unclear decision ownership, are not the inevitable consequences of organizational growth. They are the predictable consequences of a design sequence that was never examined. The ten principles that follow replace that sequence with one that prevents the drivers from developing in the first place.
PHASE ONE - DESIGN DECISIONS
Build the System Before the Programs.
Ideas 1-4 address the foundational design decisions that determine whether the function is aligned, integrated, and built for the business before a single program is launched.
Idea 1: Define the Business Decisions HR Needs to Enable Before You Hire Anyone.
This is the most load-bearing idea in the set, because every other design decision flows from it. The conventional starting point for building an HR function is the org chart. Who do we need to hire, and what will they own? The business-outcomes-first starting point is the decision map instead. What are the significant people decisions that the business makes; hiring, development, performance, rewards, exits, and what does the HR function need to be able to do for those decisions to be made well?
Those are not the same starting point, and they do not produce the same function. An HR function built from the org chart is designed around what HR knows how to do. An HR function built from the decision map is designed around what the business actually needs. The org chart follows the decision map. It doesn’t precede it.
In practice, this means that the first document produced in a function build is not a headcount plan or a program roadmap. It is a decision inventory. This is a structured mapping of every people decision that the business makes, organized by frequency, stakes, and the quality gap between current decision-making and what the strategy requires. That inventory is the design brief for everything that follows. It determines which HR capabilities are genuinely required, which are broadly useful but not critical, and which exist primarily because they are standard HR practice rather than because the business needs them.
The Decision Map Exercise
Before a single HR role is defined or a single program is scoped, answer these three questions for every significant people decision the business makes: 1. Who is currently making this decision, and how well? 2. What would better look like, in terms of speed, quality, and consistency? 3. What does HR need to be able to do for that improvement to happen? The answers to these three questions are the design brief for the HR function. Everything else is implementation.
The decision map also determines the function’s organizational structure. Centers of excellence organized around HR domains like talent acquisition, learning, or total rewards, each make sense when HR is designed as an HR function. A function organized around the decisions the business needs to make well looks different. It may consolidate domains that serve the same decision, separate capabilities that appear similar but serve different decisions, or entirely eliminate the capabilities that serve neither current business decisions nor foreseeable future ones.
Idea 2: Design the System Before the Programs.
Fragmentation, the most visible form of the HR Complexity Tax, is almost universally described as a consequence of organizational growth. Programs accumulate, functions specialize, and integration becomes an afterthought. The diagnosis is accurate, but the cause is wrong.
Fragmentation is a design choice. Usually an accidental one that happens when programs are designed before the system that connects them has been defined. If talent acquisition builds its process without explicit reference to the onboarding experience that follows it, or when development designs its curriculum without explicit reference to the performance architecture that should reinforce it, or when total rewards designs its philosophy without explicit reference to the retention outcomes the business strategy depends on, these are all fragmentation.
Designing the system first means making integration logic a design requirement rather than a retrospective integration project. Before any program is scoped, map the connected system of people practices that the business needs. Show how each practice connects to the others, where the handoffs are, and what each practice needs from its predecessors and then provides to its successors. Programs are then designed as components of that system, constrained by the integration requirements that the system has defined, rather than as independent entities that will be integrated later.
This is a harder design sequence than the conventional one. It requires much more upfront work and more cross-functional alignment before any visible output is produced. It is also the only sequence that prevents fragmentation from being baked into the architecture before the first employees experience the function, which is the only time at which fragmentation is truly preventable rather than merely manageable.
Ideas 3 & 4: The Programs Design Standard and the Manager-First Principle.
With the decision map (Idea 1) and the system architecture (Idea 2) established, the remaining two design decisions determine whether individual programs are aligned and deliverable.
Idea 3, writing the business outcome before naming the program, prevents the identity-before-accountability problem that most HR programs develop. Program names create advocates, budget lines, and narratives that are independent of outcomes. Starting with the outcome and naming the program last ensures accountability is established before identity forms. A program named “Leadership Development Initiative” is an HR program. A program designed to accelerate decision velocity in the top 40 leaders driving market expansion, measurable at 90 days, is a business intervention that HR happens to be running. The distinction determines what gets funded when the budget tightens.
Idea 4, designing for managers first rather than employees, addresses the delivery gap that most employee-facing programs encounter. Employees experience HR almost entirely through their manager. A performance framework is experienced as the conversation the manager has with their employee. A development approach is experienced as the investment a manager makes in their employee. A culture program is experienced as the behavior the manager models for their employee. Designing directly for employees while leaving managers under-equipped produces programs that work in design and fail in delivery. The manager is the last mile of every people practice. Design accordingly.
PHASE TWO - GOVERNANCE DECISIONS
Build the Constraint Before the Capability.
Ideas 5-7 address the governance architecture that prevents over-design, misalignment, and complexity accumulation, the three drivers that develop fastest in the absence of a standing governance mechanism.
Idea 5: Start With What You Will Never Do.
Most HR function designs begin with a capability list that includes everything the function should be able to do, organized by domain and maturity level. The constraint list is instead the document that almost never gets written. Which programs, processes, and initiatives will HR not run because they do not connect to a measurable business outcome.
The constraint list is harder to write than the capability list. It requires saying no to things HR knows how to do and that would be broadly useful even if they are not specifically necessary. It requires distinguishing between programs that produce HR outcomes and programs that produce business outcomes, a distinction most HR design conversations do not make because the conventional model treats both as legitimate HR work.
Without a constraint list, every HR function gradually adds programs that are well-intentioned and strategically tangential. The HR Complexity Tax begins accumulating with the first program that cannot connect itself to a business outcome. This is not because the program itself is bad or poorly designed, but because it consumes budget, bandwidth, and organizational attention that the business would have allocated differently if the choice had been made visible.
Idea 6: Build the Complexity Budget Before the First Program
This is the most structural idea in the governance phase, and the most load-bearing after Idea 1. The HR Complexity Tax accumulates because complexity is never treated as a finite resource. Financial budgets are constrained and reviewed quarterly. Headcount budgets are constrained and viewed in every planning cycle. Complexity has no budget, which means it grows without limit, compounds without detection, and is only addressed when it has become severe enough to justify a transformation program.
A complexity budget is an explicit ceiling on the total process steps, approval layers, and technology touchpoints that the function is permitted to run at any given time. Every new addition requires something to be displaced. The budget is reviewed quarterly, and the CHRO is accountable for it the same way the CFO is accountable for the financial budget. Complexity that exceeds the budget is a governance failure, not a program design problem. And it is addressed as a governance failure, with the same accountability and the same urgency.
The Removal Discipline
The complexity budget requires a corresponding removal discipline. It must be a constant standard that governs what comes out when something new goes in. It is not a committee that meets when complexity becomes visible. It is a mechanism that runs continuously from the first day the function operates, and applies the same three-question test to every process step at every review interval. 1. What specific failure does this step prevent? 2. Is that failure still occurring at a rate that justifies the cost of this control? and 3. If this step were removed, who absorbs the work it was doing, and at what cost? Steps that cannot answer all three clearly are candidates for removal, not candidates for retention.
The complexity budget is load-bearing because without it, every other governance decision is reversible. The constraint list (Idea 5) can be written and then quietly abandoned as organizational pressure to add programs builds. The measurement framework (Idea 7) can be designed in business language and then gradually supplemented with HR language metrics as the function seeks additional ways to demonstrate value. The complexity budget is the mechanism that makes all other governance decisions stick, because it treats their violation as a budget breach rather than a design preference.
Idea 7: Business Accountability as the Measurement Design Constraint.
Before a single HR metric is defined, apply one test. Can this metric be expressed in terms that the CFO would use to evaluate any other business investment? Revenue per employee, capability gap closure rate, strategic initiative execution velocity, or retention specifically in the talent segments the strategy depends on. If the metric cannot pass that test, it does not go into the framework.
This is not a communication strategy. It is a design constraint. HR metrics that survive only in HR language are not accountability mechanisms. They are reporting conversations rather than business conversations, and reporting conversations are where HR credibility erodes most reliably. Not because the metrics are wrong, but because they are expressed in a language that does not connect to the outcomes the business is being held accountable for.
Building the CFO language test into the measurement framework from day one ensures the function is always speaking the language that determines its relevance, and never has to retrofit a translation layer onto metrics that were designed for a different audience.
PHASE THREE - TECHNOLOGY DECISIONS
Wait. Then Apply the Standard.
Ideas 8-9 address the technology adoption sequence that determines whether the function’s tech stack simplifies operations or generates the HR Complexity Tax that most HR technology investments produce.
Idea 8: No Technology for the First Twelve Months.
This is the most counter-intuitive recommendation in the set, and the most defensible. Technology acquired before processes are designed and the real workflows are understood will shape the function around its own capabilities rather than the business’s needs. Twelve months of deliberately low-tech HR produces a function that knows precisely what it needs from technology. The implementation that follows is faster, cheaper, and significantly less likely to generate the complexity tax that most HR tech investments produce.
The backwards technology adoption sequence where you first identify the pain points, then select the vendor, and next redesign the process around system capabilities, is the single most reliable generator of HR Complexity. It produces systems configured for the path of least organizational resistance rather than the operational need they were purchased to address. Waiting twelve months before technology decisions are made forces the function to understand its own operational reality before committing to a configuration that is very difficult, and very expensive, to change later.
Idea 9: Apply the Technology with Intent Standard Before Any Selection Decision
Idea 8 established the restraint. Idea 9 establishes the standard that replaces the backwards adoption sequence once the restraint period ends. Without the standard, the twelve-month wait simply delays the conventional sequence rather than replacing it. The function emerges from the restraint period with good operational knowledge and then proceeds to make technology decisions the same way every other organization does. They start from the vendor conversation rather than the problem definition.
Technology with Intent requires four conditions to be met before any selection decision is made.
The business capability must be defined with precision. Not “hiring is slow”, but the specific gap, measurable and named.
The process the technology will support must be designed before configuration begins. Not adapted to the system’s capabilities after implementation.
The business outcomes that the technology needs to produce must be defined before go-live. Not discovered at the 90-day review.
Every new technology decision must include an explicit statement of what it displaces in the current workflow. Not deferred to a future rationalization exercise.
Applied from the first technology decision, these four conditions prevent the accumulation pattern that most HR tech stacks develop within three years of the first implementation. They also change what gets selected, because a technology evaluated against a precisely defined problem and a designed process looks different from a technology evaluated against a feature list and a demo. The selection is slower. The implementation is faster. The complexity generated is significantly lower. And the business outcome, measured at the point it was defined rather than the point that was convenient, is visible.
PHASE FOUR - EXECUTION DECISION
Design the Last Mile First.
Idea 10 addresses the single execution decision that determines whether every other design decision produces durable behavioral change or well-designed programs that quietly revert to the status quo.
Idea 10: Design the Last Mile Before You Design the Program.
Every HR program has a last mile, or the point at which the program reaches the manager or employee who is supposed to behave differently because of it. This is not the go-live date or the completion rate. This is the moment when a manager sits down to make a real decision with real stakes and either uses the new framework the program was designed to give them, or defaults to the judgement patterns they have always used.
That moment is the program. Everything before it is preparation. And in most HR function designs, conventional and business-outcomes-first alike, the preparation receives the majority of the investment while the moment itself receives almost none.
Designing the last mile first means defining that moment before designing the preparation for it. Specifically, what does a manager who has successfully adopted this practice look like in behavioral terms, in the situations that matter most, and in the conditions that will actually exist when the practice is needed? That behavioral definition is the design brief for every element that follows: the program structure, the training design, the practice infrastructure, the feedback mechanisms, and the governance that monitors whether the behavior is holding.
The Last Mile Design Brief
Before any program is scoped, answer three questions. 1, What specific decision or behavior is this program designed to change? 2. In which situation, with what information available, what time pressure present, and what competing priorities in play, will that decision or behavior be tested? 3. And what does success look like at that moment, specifically and observably? A program designed against those three questions is a program designed for the last mile. A program designed without them is a bet that the last mile will take care of itself.
Designing the last mile first is the most load-bearing execution decision because it changes the design brief for every other element of the function. A performance framework designed from the last mile backward looks different from one designed from the competency model forward. A development program designed from the behavioral outcome backwards looks different from one designed from the curriculum framework forward. The last mile is not an adoption challenge to be managed after the program is designed. It is the design constraint that determines whether the program is worth building.
The Function Nobody Built Is the One Worth Building
The conventional HR function is the product of accumulated decisions each individually defensible. It collectively produces a function that is harder to navigate than it needs to be, less aligned to business strategy than it was designed to be, and more expensive to run than the outcomes it produces justify.
The function this article describes has almost never been built from scratch because the design sequence it requires is harder than the conventional one. It requires decisions to be made in an order that feels premature where we first define the systems before the programs, write outcomes before names, and build governance before capability, while waiting twelve months before technology. It requires saying no to things that would be broadly useful in favor of things that are specifically necessary. And it requires designing the last mile before designing the program. This means that before anything is built, you must make the moment at which the function’s entire investment will either be justified or quietly lost fully visible.
That is a much harder design process. It is also the only one that produces a function that does not need to be redesigned.
The HR Complexity Tax Assessment in the diagnostic tool for organizations that have already built the conventional function and are ready to understand what it is costing them. The Five Pillars of HR Transformation is the framework for addressing what the assessment surfaces. And the ten ideas in this article are the design system for the organizations fortunate enough to be building from scratch, or courageous enough to treat their next transformation as the opportunity to finally build the function they should have built the first time.
The HR Complexity Tax is not an inevitable feature of mature HR functions. It is the predictable consequence of a design sequence that was never examined. For a full mapping of how each of the ten principles addresses a specific structural driver, the reference guide is here.